Knowing how to close a project successfully is one thing that distinguishes good project managers from bad. Good projects finish with purpose, bad projects tend to close with a whimper.
Just because your deliverables are complete does not mean the project is complete. There is still lots to do. The steps you need to take when learning how to close a project are:
Let’s walk through each of these steps in turn so that at the end of this article you know how to close a project successfully.
Your team has delivered all of the deliverables and from their perspective it seems like the project is complete. However, this isn’t usually the case.
For the project to be complete the deliverables not only need to be provided to the customer but they need to be signed off by the customer. This can be much more complex than it at first sounds.
Consider an example project where we’re delivering an automated telephone (IVR) system to a sales team. In this case before the deliverables can be signed off, we would probably as a minimum need to train the sales team on how to use the new system. In all likelihood, we would also need to support the sales team in using the new system for a period of time before they would sign off the deliverables as complete.
During this supporting time issues might be raised which our project team would need to resolve. You can think of this as being like a snagging list, which you might be familiar with if you have ever purchased a new house.
The issues might be something that hasn’t been done right by the project team and simply needs to be fixed, or it could be something that has been implemented perfectly correctly by the project team, but upon trying to use it in the real world, doesn’t work as a solution for the customer. In this case, you’ll need to go through the Change Request process to get the changes to the deliverables approved and then implemented.
If you think about it a little it’s easy to understand why it is important to have formal sign-off of the deliverables. This is because if we didn’t do this, the project team might disband and move onto other things as soon as the deliverables are produced. Then, if the customer isn’t happy with the deliverables and wants changes made, it’s too late, as the team has already disbanded and moved onto other things (some contract staff that were working on the project may have even moved on to a completely different organization).
The process of capturing The Lessons Learned is often overlooked and forgotten in projects, and that’s usually a mistake. The lessons learned, if done right, is very useful as it tells us what went right and what went wrong. That information isn’t valuable in itself, but when concrete actions of improvement come out of it, then it’s easy to see the value of the lessons learned accumulating over time, helping future projects avoid the issues that previous projects fell foul of.
Like any process, the quality of the lessons learned exercise will depend on the quality of the inputs (garbage in, garbage out), but it is equally about the outputs. For it to be successful, the lessons learned is not just about producing a beautiful report, it is about implementing concrete improvement actions, and then ensuring these actions get done. To ensure actions get done they shouldn’t be given to the project manager to carry out (as the project is likely to be shut down imminently), but instead to representatives from the business who can be responsible for ensuring the actions get actioned and implemented even after the project has been shut down and disbanded.
A complete process for running a lessons learned workshop is provided here.
Once all the tasks on the project plan are complete it can be tempting to release your resources. This is often a mistake. You only want to release resources once they are no longer needed on your project.
This isn’t to say that the people on your project can’t do other things, and that they should be sitting there idle just in case you need them. This is unproductive, so of course they can do other things, but it must be understood that you have priority charge over them should you need them in some way.
Once formal project sponsor sign-off has been given, and you are satisfied that you no longer need the resources then you can release them from the project team.
Note that resources doesn’t just mean people, you could also have:
Managing and delivering projects can be challenging. Many project managers and teams fail to deliver successful projects. Even those that do deliver successfully will frequently close their projects meekly.
Why not end your project on a high and celebrate the successful completion of your project.
Consider asking the project sponsor for some money to do this properly. You may also wish to invite your project sponsor and other key stakeholders to your celebration.
The celebration marks that final completion of the project. Everyone has worked hard on the project and they deserve to celebrate.
If you will have to work with the same people again on your next project, then the celebration is a useful tool in building momentum towards your next project.
There are four steps you need to understand when thinking about how to close a project successfully. These are:
You can think of these 4 steps as a closing a project checklist. All of these steps are important to ensure that the project doesn’t close too early, that lessons learned are carried into future projects, and that momentum is built towards the next project.
Image credit: Chris
Communication in Project Management
Change Request Template
Project Management Soft Skills
Project Status Report Template
How to Start a Project
Project Plan Example – How to Plan a Project
The Project Scope Statement
The Project Business Case