How to handover a project on closure
You’ve delivered a great project – or at least made it to the end, exhausted! Now it’s time to handover the work because the project is closing.
But what do you have to do? If you’ve ever ended up on a project where the work never seems to end… and the changes keep coming in… and even though it is technically closed people still come to you for help… then this is for you!
I had one memorable project where I couldn’t get rid of it. There wasn’t anyone really to hand it over to, so a lot of the support questions came to me simply because I knew the work inside out. It was fine, but it did pull me away from other projects.
And it’s not what project management is supposed to be. We’re supposed to deliver the project, hand it over to a willing and welcoming BAU team and then move on to deliver the next cool thing.
Here’s how to make that happen so you can move on to your next project knowing you’ve left this one behind all tidy.
Handover vs project closure
What is the difference between project handover and project closure?
Closure is the phase or stage of the project. It’s part of the project lifecycle. A closure document is a formal sign off that marks the end of the project work. It is a record of the project management process. The closure document talks about what you did and how that compared to what you set out to do.
Handover is part of the work the project manager has to do on the project to complete the closure. It happens when the deliverables are complete but it also includes providing information about the background and context for the project to provide a complete picture of the work that was done.
Handing something over is not a one-and-done activity. It’s a process that you’ll complete over time. We do it as it creates a smooth transition from the project environment to the operational/live/BAU environment.
When to do the handover
I’ve handed over many projects in my time, and my trick (it’s not really a trick) is to do an incremental handover.
Ideally, you should be handing over deliverables as they get completed. Don’t wait until the end of the project and handover a huge bunch of stuff. It’s overwhelming to the operational team and it’s too hard for them to stay on top of what is coming their way.
Choosing to involve the operational team on an ongoing basis only has advantages. The project handover process takes longer, yes, but the results are better because they are onboard with the idea and you aren’t throwing something over the fence to them (that’s how we used to talk about it when I worked in IT) and hoping they’ll catch it.
It’s not only deliverables that get handed over. You are also handing over the content and context, and knowledge.
Incremental knowledge transfer is a better approach. As soon as something is built or delivered, check where it should go and make sure they are ready to learn about it.
Of course, some things need to wait until the end of the project before they can be handed over, but try to spot anything that can be transferred earlier to save everyone additional headaches at project close.
Step 1: Work out who gets the handover
Who are you handing this project over to?
Ideally, you should know this already. It’s probably the project owner and their team. However, it’s possible that some of that group don’t have even a high-level overview of the project, so it’s worth planning in a recap.
You should plan for your handover from the beginning of the project. During project initiation you would have worked out the owners for each of the deliverables or at least the general team who will be receiving the handover.
Check your project RACI matrix as well or ask team leaders, subject matter experts and the project board to identify people – especially if the individuals who were there at the beginning have moved on. The communication plan may also have useful info in as there will be names of stakeholders in there.
If your project involved any changes to technology, make sure the handover includes the IT Help Desk or support desk or whatever you call them. They will be crucial in fielding incoming calls from users to the correct team.
Read next: 5 Tips for working with the IT helpdesk on projects.
Step 2: Work out what to handover
What, exactly, are you handing over?
Again, you should have this information already. During project initiation and planning you would have worked out what deliverables would be required. Check back to the project requirements and success criteria to see the complete list of what the operational team are expecting (remembering that change requests might have been made since that document was last updated).
Think about what the recipient of the handover needs to know. I start a handover document towards the end of a project or phase and use it to make notes of what information to pass on. The document becomes the basis for my knowledge transfer.
Use the project handover templates from your PMO or make your own. Generally, you’re looking for a checklist of things to cover off as you hand work over to your colleagues.
Start your notes with a handover plan template
I have a tried-and-tested Word document that I use as a handover and transition plan. It’s a great starting point for your own plans as it is fully customizable.
Members of Project Management Rebels have access to this for free, along with a detailed handover checklist and lots of other resources.
Here are the main things you should include in the handover.
General project status and background
What happened on the project? Share some information to provide the context for the project. What was the business reason for doing it and is that still valid? How far have you got with addressing the problem this project set out to fix?
Provide links to any project documentation for background. Share a bit of history: what worked well and what didn’t? If you’ve already had a lessons learned session, share the output from that.
If there are any risks that might still be relevant after the project has closed, pass those on too.
Scope items/deliverables
Be clear about what was created and completed and what was not. If there are any further project scope changes that you noted as a good idea but didn’t implement, hand those over too. Then the BAU team can choose whether to act on those changes and implement them in the future.
Scope can include system descriptions, design documents, process maps and other documentation as well as the software or systems themselves.
Schedule of remaining activity
Share the outstanding project-related steps so the team know what is coming up and when they will be expected to run with the deliverables in a business as usual environment.
It’s likely that you’ll only have the project closure document to issue, but if you are doing incremental knowledge transfer or your deliverables are phased, there might be more of the project left to do.
Budget
Share the project budget position. How much was spent and on what? If any ‘spare’ budget is available, make sure the team know whether they can access it or whether it goes back into the main project pot.
Knowledge created during the project
Share any process maps, user guides or manuals, documents, the project wiki if you had one, videos, research papers and other things that might not strictly count as ‘proper’ deliverables but were created during the project.
Project artifacts like these are all very helpful when you want to make sure the handoveree gets a fully rounded picture and all the information they need to continue to carry out their role in the future using the project’s outputs.
Contact details
I know you are moving on, but there are probably other contact details worth sharing. For example:
- Procurement contacts who worked on the deal
- Legal contacts who supported with contract review approval
- Supplier contacts who will maintain the products going forward
- Other subject matter experts who supported the project.
If the project backfilled any roles, let the BAU team know that those individuals will be moving back to their day jobs and the roles will no longer be filled – if that is the case.
Contracts
The number of times we’ve had to look for contracts and it’s taken ages because they aren’t stored anywhere central…
If you have a central contract repository, or a procurement/purchasing team that is responsible for contract management, make sure they have a copy of any final, signed contracts.
If you have version-controlled documents (and contracts should be), make sure the latest versions are what you handover.
Part of the project work will be to close out contracts, but any ongoing contracts, for example, maintenance and support provision, will need to be actively managed by someone.
Systems information
Make a list of any system logins and software that has been set up, installed or improved as part of the project. Check the right people have the logins and permissions they need. In particular, make sure someone who is not you has admin rights to add and remove new users as new employees join the team.
Benefits tracking
Finally, the project was most likely delivered because the organization wants to achieve some kind of business outcome from it. Who is going to be tracking project benefits and how are they going to do it?
On one of my programs, we have projects that are completed and projects that are still in-flight. The project BAU owners for the completed projects track benefits and present those numbers back to the program board.
Identify who is responsible for ongoing tracking, what they have to track, how that is reported back (and who to) and how long they have to track for.
Perhaps they won’t have to report back to anyone and the data is only for their information. But make sure you both know what is expected.
Step 3: Do the handover
The next step is to complete the handover.
Handovers are literally just meetings where you talk to the person about the thing you are handing over to them. They can ask questions. In my experience, they often forget some questions and follow up with you later – that’s fine too.
Schedule any one-to-one or joint meetings for knowledge sharing sessions. You can also provide a written handover in the form of your notes, links to documents or Microsoft Teams channels etc.
You might see people recommending that you complete a handoff document, but in my experience, the kinds of projects I work on end up with multiple documents because there is more to handover than can be written down in one document. For example, we also handover systems access.
Step 4: Ask for feedback and be around to support
Finally, check in with the handoveree and see if there is anything else you can provide them with.
Hopefully they will say no, but offering is good practice. It should reduce the amount of questions you get later when technically you should be working on another project.
You may also want to run a ‘hypercare’ phase where you are jointly responsible for support. Work together to manage incoming queries and manage the deliverables until the BAU team feel comfortable doing it by themselves.
Hypercare is particularly relevant if one of your deliverables is software. Typically we use it when there is a product launch and a team has to use a new software tool. The project team provide on-site support while the users get up to speed with how it works. You can extend this concept into the handover phase too, if it is useful.
Your next steps
If you have read this far, you probably have a project close coming up. Here are some simple action steps to prepare for your project handover phase.
- Collate all documentation that needs to be handed over
- Review the RACI and identify who receives what during the handover
- Start a set of project handover notes so you don’t forget anything
- Schedule some handover meetings with key stakeholders.
And that’s it! Walking away from a project can bring up all kinds of feelings, especially if the project went really well and you worked with an excellent team.
Read my complete guide to project closure for what else to consider during this phase of your work. I also have a specific guide for project closure in PRINCE2 if you use that method. Remember that whatever the outcome of your project, you did your best!
