Closing a project is, in itself, a project. Everything has to be ‘finalized’ in some way – every deliverable, every expectation. A recent client of mine was not really understanding the closure idea. This person was sure (s)he could just hand the product over to the client, and that was the end. But, you should use a formal process every time!
The end requires a process; a set of procedures that close out all the elements of the project. If there is software for example, there must be some way for the client to acknowledge that the product meets the requirements. So, an acceptance test plan needs to be created.
The closure process also requires a formal meeting that specifies the end is near and establishes a processes to finalize the handover or ‘go live’ of the software. At this point, you also obtain the final authorization signatures that signify the project is closed.
There is still more work to be done, however. In software, you or your team may have to hand over the source code, decouple your team members from the client office systems, hand off the documentation and maybe clean out your desks in some cases. Closure is when some of us get paid…or have to wait if there is some surprise ending.
If the product is not quite right, the testing is not acceptable, the development requires more tear down or there are support or service level agreements to maintain, follow-up must be defined, clarified and finalized with the client signatures. Done is when everyone thinks it is done. Clearly establish all stakeholder expectations for ‘done.’
What comes next depends on long term commitments, if any, and/or new projects waiting to be started. Do not let an old project keep rearing an ugly head because someone does not think it is ‘done;’ get it all finalized and approved, and disconnect as needed. Moving on requires focus on new projects, so don’t let old projects drag you back in. Closure is very important.