Project Closure and Team Disband

One of my favorites and often poorly executed part of a project is the project closure.  Project closure is not just a simple wipe our hands together and smile, then proclaim that we are finished with the project. It is not even handing the customer our results and patting everybody on the back – and on to our congratulatory soda.  The roots of the closure of the project happen in the very beginning of the project when we establish the scope of the project.  If we are under contract the seeds we sow in the contract will be the harvest we reap during contract closure.

Project Contract Closure

To effectively close the project out, we need to have identified the project scope in a tangible way.  That requires a way of tracing the top level scope (customer expectation) to the details of the project, which in the product development world, is typically contained in the specifications and detailed requirements documents.  These documents are where we articulate in detail how we intend to meet this expectation.  Ultimately, this documentation will serve our project by making an objective and quantitative assessment of the project results against this target.  However, this is not the only source of data required. The customer will work with the product and validate that their objectives with the product have been met. These activities will be identified in user acceptance testing.  This is contract closure.

Project Closure and Post Mortem

We also conduct a post-project assessment.  If we are smart, we will have co-opted the agile approach to critiquing the project throughout rather than solely at the end.  We will also be smart if we find ways of disseminating this learning to as much of our organization as possible.  Writing the learning into a database or a book only helps so much.  Experience suggests these approaches are far from perfect.

Project Closure Administrative 

This part of the project closure is where we gather up the documentation associated with the project and archive for access should we need to revisit at a later date.  This includes any temporary adaptation of existing processes.  We may need to go back to this evidence at some future date for any number of reasons, a few of which are:

1. customer questions at some future date
2. as a defense in the event of any future legal action against our company as a result of the project 
3. historical record from which we may learn

There are many things that happen during project closure,  many of which start in the early project phases and some that are the results of decisions we make along the way.  We do not know what the future holds regarding the results of this project, as such we will want to ensure we are able to explore and learn yet more from this project should that be necessary.