We tend to spend lots of time talking about project set up, having a fully-thought through business case, or all the stuff you have to do while the project work is being done. But there’s another area that is arguably as important, if not more so than those: how to close a project.
The risk of poor project closure
If you don’t finalize and hand over the project to the operational teams effectively, you risk:
- Support and operational teams not knowing what they are supposed to be doing with what your project has delivered
- Ineffective benefits tracking
- Poor levels of training and support for users or customers
- High learning curves for users, which affects their ability to work in the new environment.
There is a big prize at stake: the project’s benefits. Wasn’t that why you did the project in the first place? If your project customers can’t understand or work with what you have given them, they won’t use it. If they don’t use it, the organization doesn’t receive the planned benefits.
And if the planned benefits aren’t delivered, the whole project was kind of pointless, right?
The importance of project closure
At the end of your project you should be thinking about wrapping up your work and handing it on to someone else. Otherwise you’ll never get rid of it, and you’ll be the Go To person for ever and a day.
A good project closure document helps that immensely. First, it points out exactly what your project objectives were. Then it describes the success criteria you specified in order to meet those objectives and what you did to meet them.
Not sure about success criteria? Check out my definitive guide to project success criteria .
What goes in a project closure document
The easiest way to create the document you need is to use a project closure template.
Do you need one? There’s one in my Essential Project Documents bundle .
In the document, explain what you set out to do. Record what you did met those success criteria. Stay factual. This is not the place to explain why you are three months late or massively over budget.
To make it clear to everyone concerned, I add a column that shows the variance from the target i.e. how far off you were from meeting the success criteria. That, of course, assumes that you exceeded them or didn’t hit them.
If your project management skills are simply awesome, you can write “n/a” in that box to show that you came in exactly on target.
Handover information to document
You also use the project closure document as a way to record relevant information for the operational team by form of a handover.
You’ll find that every project is slightly different and what you need to record changes from project to project. So this section is deliberately vague but it might include:
- Info on the suppliers you are using for support and maintenance going forward.
- Contact details of relevant internal subject matter experts.
- Any outstanding tasks that the operational team are going to have to pick up.
Remember to sign and date the project closure document, and get all the other important stakeholders to do the same. That gives you a physical record (even if the signatures are electronic) of acceptance into the business by the sponsor and team, so you can move on with a clear conscience.
Project closure meetings
The project closure meeting is the place to formally discuss anything you need to — in my experience you have it before creating the document, so you can record the relevant feedback in there, but you could also do a draft of the document and then present it at the closure meeting.
At the end of your project closure template you can record anything else that came out of the project closure meeting.
Here’s an infographic on how to close down a project effectively so you don’t leave anyone hanging.