20 Questions to Ask When Closing a Project

Rob Kalin, founder of Etsy, is quoted as saying, “The last 10% it takes to launch something takes as much energy as the first 90%.”

I found a similar sentiment in an article by entrepreneur Faisal Hoque, “There’s an old Chinese saying that when you’ve made it 90% down the path, you’re halfway to your destination.” (Hoque, 2013)

Now be honest, Project Managers, how many of you have had similar thoughts as you approached the finish lines of your projects?

I can honestly say that every project I worked on during my four decades seemed to fit this pattern. However, it was never due to a lack of enthusiasm or excitement as the project neared completion. In fact, excitement typically heightened as we approached implementation.

In my opinion, it was that last 10% composed of the not-so-fun tasks to tie up loose ends, check off contract terms and conditions, and validate results against the client’s original project objectives were completed.

Perhaps that is why so few IT projects ever really close well. My observation is that even the most disciplined and experienced IT providers or corporate IT departments do not provide adequate closings to benefit future projects. When the last deliverable is accepted and signed off, the last payment made, and the system turned over to operations, the project is marked complete and the team disbursed to various new projects.

From a pure dollars and cents (and in my opinion, myopic) perspective it is argued that there is no immediate benefit to allocating the effort and resources to do a thorough closeout. For the external IT provider, this would require a higher initial bid amount to price in this task. Such additional cost would risk overpricing the procurement. Unless the client required a closeout task in its Request for Proposal, few IT firms would add the full cost of a thorough closeout.

Even if the client requests a formal closeout, they are typically only interested in a subset of what a project close should entail. The client may request something like an accounting of deliverable acceptances and required updates, a final report assessing project results against the initial business case, a review of how well client objectives were met, and a transfer of knowledge and responsibility to operations. This may satisfy the client, but it should not satisfy IT.

If the IT provider or corporate IT department wishes to keep improving their processes and project success rates, they should go much deeper in the closeout. However, to do so requires time, effort, and resources. Most IT organizations are anxious to move their staff to the next projects, rather than take the “downtime” that this level of post-project analysis would require.

I have been part of such organizations. Project closeouts were paid mere lip service. Oh, we might complete a Post-Implementation Evaluation Report (PIER). I personally produced my fair share of these. However, I never felt that the PIER really got to the heart of how successfully the project was executed. Our conclusions were mostly surface-level, gut-feel observations rather than deep analytical reviews.

The result was that when we then needed objective information from the project for a bid response or a project issue, such information was lacking. Instead, we would have to rely on the Project Manager’s (undoubtedly biased and fading) recollections of the lessons learned, which were often no longer useful. And the same mistakes were repeated on the next project, and the next project, and the next …

But what if it could be shown that extensive project closure of this nature could pay for itself many times over in future project deliveries?

What if:

• potential liability was avoided by a thorough review (and mitigation, if necessary) of all project closure requirements?
• future project risk could be averted?
• client satisfaction improved, which then generated follow-on or new business?
• future profitability improved as less money was left on the table due to poor practices?
• there were fewer and fewer project failures?
• the IT organization’s reputation was enhanced with each successful project completion?
• the IT Project Manager’s reputation was enhanced with each successful project completion?

I believe each of these positive results is possible as the IT organization becomes more adept at analyzing its own performance. Additionally, much time and effort could be saved at the end of the project if similar analyses were performed at each phase-gate review. In my mind, the Closing Process is as important to the overall project management process as are any of the other process groups.

Project closing appears to be straightforward, at least at a high level, and should answer the following questions. Many of these are relevant to the client organization itself, but all are certainly relevant for the IT project delivery organization:

1. have all deliverables been completed, validated, and signed off by the client? have they been indexed and archived?
2. was the system transitioned fully to ongoing maintenance and operations (including transfer of knowledge and associated documentation)?
3. was final client project sign-off obtained?
4. were all project management processes completed? (for one such horror story, refer to my article, “The Lesson of the Quarterly Status Report”);
5. were project governance processes executed per the client organization’s requirements?
6. have all final invoices been submitted for payment?
7. have vendor and sub-contractor products and services invoices been received? Have they been paid?
8. were project objectives met per the project charter, scope delivered according to the project scope statement, and benefits realized per the benefits management plan?
9. was the Lessons Learned repository updated?
10. were stakeholder satisfaction surveys/interviews completed and analyzed?
11. were variance analyses performed to assess actual spending against budget, and actual milestone dates against scheduled dates?
12. were project management practices, team management practices, and client management practices conducted effectively?
13. was an audit of successes and failures conducted and results documented?
14. were assumptions and constraints reviewed in light of project execution?
15. was quality of the deliverables and the final product assessed against standards?
16. were risks and issues reviewed in terms of how each was handled, and how effectively they were managed?
17. was project staff involved in the closeout assessments to get a broader, less biased view of what was done well and what areas require improvement?
18. was a final project closeout report prepared?
19. were excess project material and surplus equipment reallocated for other uses?
20. were team member performance reviews completed and staff reassigned?

As the project is closed out, the Project Manager must also provide a way for her team and the client team to celebrate their accomplishments. Team members who had left the project in earlier phases should be included in the festivities.

No matter how well the process aspects of project delivery were executed, the project was delivered by people. People initiated the project. People executed the project. People should celebrate and be celebrated.

Footnotes

Hoque, Faisal (2013, August 20). Taming the Last 10%: Lessons for Finishing Meaningful Work. Fast Company, Leadership Now. https://www.fastcompany.com/3015925/taming-the-last-10-percent-lessons-for-finishing-meaningful-work

Get Your Free Guidebook

Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.