When you get near the end of your project, there’s one big milestone: Project Handover. In a sense, this is where your work comes to fruition.
While it’s technically wrong to think of it as a single event, or milestone, handover marks the completion of delivery and the start of the closure stage of your project. So, it’s a big deal.
And precisely because handover is more of a process than a milestone, there is a lot to get right. So, in this ultimate guide to project handover, we’ll tell you everything you need to know.
We’ll start with answering the obvious question about what project handover is. And then we’ll tackle the detail of how to do it in the simplest, most obvious way: before, during, and after. Finally, we’ll end up by signposting you to some useful tools to make it easy for you to get your own Project Handover right.
Let’s get started…
When we talk about project handover, we are usually speaking of the handover of the project’s deliverables from the project to the operational environment. Put another way, the products go from the responsibility of you, the Project manager, to an operational manager – sometimes referred to as an Integration Manager.
Because the term is also sometimes used for the hand-over of a project from one Project Manager to another. While some of the ideas in this article will be relevant, i would refer you to our companion article, ‘One Day You’ll Need Our Ultimate Secrets to Project Takeover’. This looks at it from the perspective of the Project Manager to whom the project is handed over.
When I talk about handover of the project’s deliverables, there’s something critical to remember. At this point, you are also handing over responsibility for the realization of the benefits from these products. Benefits realization is an essential part of your preparation and execution of project handover.
Take a look at this short video…
Usually, project handover is seen as a part of the closure stage. Most methodologies describe it there.
The PMI’s Project Management Body of Knowledge (the PMBOK Guide) 6th edition places it in the Closing Process Group. And PRINCE2, likewise, places it as a part of the Close a Project process.
But the reality of Project Handover is that it is a process that spans the end of Delivery stage and start of the Closure stage. I like to represent it as the boundary between the two stages. And, if there is a ‘moment of handover’ then this is reasonable.
Within the PMBOK Guide’s (6th Edition – things are likely to change in the 7th Edition) 10 Knowledge Areas, Handover sits within Project Integration Management. This is the right place, in my opinion.
And someof the people or roles to think about are:
Because project handover is a process, it’s wise to think about it as a series of stages. We’ll adopt the simplest model:
I would also alert you to the possibility that, although we talk of the Project Handover, this need not be the case. Rather than a single release and handover of deliverables, it’s entirely likely that, on a big project, you may plan for multiple releases.
As with everything, Project Handover will go best, when you prepare for it. And, as you may expect from me, I recommend you start by making a checklist. In fact, if you look below, you’ll find we’ve already started the process for you!
We’ll look at four things to prepare:
Before you hand over any assets, processes, or resoures, the people who will need to use them need to feel ready. And there are two principle ways you can do that:
Remember that the experience and training needs to cover both:
Clearly, in the run-up to any handover, stakeholder need to be aware of what will happen and the timing of it. You’ll need to create a communications plan and allocate team members to aspects of it.
For most stakeholders, handover is likely to be a ‘good-news’ event. But never neglect those stakeholders for whom it is either an inconvenience or, worse, a transition to a more detrimental state. Not every stakeholder will necessarily benefit from the outcomes of your project.
If you fail to properly engage with those stakeholders for whom this is a bad time, they may make your handover problematic. And, worst of all, they may do so in a way that you are unable (or poorly prepared) to predict. At least by engaging them, you have a chance to mitigate any disruptive behavior and, at the very least, anticipate it.
But the ideal outcome i that, by treating them with respect, potentially antagonistic stakeholders will accept the reality of project completion and handover with a measure of equanimity.
Before handover can take place, any assets need to be fully commissioned and any processes or technology fully tested.
I shan’t go into how that works, because it will be particular to the specific technology and industry you are working with. But I would comment that the planning for this needs to be a part of your main project plan
Once testing and commissioning documentation is complete, you should have available all of the documentation you will need for handover. So your task here is to collate and check it all.
I’ll put a list of all of the documentation you need to include in project handover in the next section.
It is during this stage that responsibility transfers from the project to the oprational business or client. If there is a ‘moment’ – or a milestone, it is at the completion of this stage.
And, I would say that there should be a milestone. It is a point of celebration for your team.
However, ahead of that celebration, there is plenty of work to do, and here are my thoughts…
I know we’re in strange times and you may need to interpret this in a Zoom/Teams sort of a way, but…
Always make your handover from your (Project) responsibility to your client’s (operational) responsibility in person. As much as possible, make it a human event with hand-shakes and signatures.
And also aim to involve users and your project team members in the process. It’s the users’ first point of ownership and your team’s last. So this transition can be emotionally important for both parties.
If there’s a moment, then this is it. A signature on a pre-prepared handover or acceptance document that your client or operational owner accepts responsibility for your deliverables.
Typically, any acceptance documentation comes with a scheduleof follow-on actions. This is a note that acknowledges that the project may not have completed every tiny detail, but that the new beneficial owner is happy to take on responsiblity for those few outstanding, ‘snagging’ items.
I’d expect, by the way, that the project team will provide a measure of support for completing these actions during the post-handover period (see below).
Aside from any assets, products, or processes, what you are handing over is largely information. And that transfer needs to be from the brains of the project team to the systems the operational teams will use. That way, the knowledge is secure from fading away. However, it is likely that there will be an amount of know-how that is neither:
The real handover is between:
Therefore it is important that any team members who will not be around for long can transfer their knowledge before they mov e onto the next thing. Here, I am thinking particularly of the need to debrief contractors and consultants.
But, of course, there’s also a lot of documentation that you need to hand over…
Here’s a list of what I can think of…
Finally, before we more to the Post-handover activities, there may be some administrative activities that fall most comfortably in this stage. Here, I am thinking of things like:
‘It’s not over ’til its over’ – they say. There’s always amore to do.
The most evident thing is likely to be [a hopefully small amount of] snagging. These are any small tasks the new operational owners need to carry out to complete the deliverables. This list is likely to have come from he report from your commissioning or final round of user acceptance testing (UAT).
I would expect the project team to be on hand to help and support this. It is the responsibility that has transferred, but you still need to supply some support.
And, flowing naturally from this, is the need for Configuration Management, based on any changes made by the follow-on actions.
Perhaps the most important thing is benefits realization. It is largely the responsibility of the operational owners to realize the benefits of the products, service, processes, or assets that the project team delivered to them.
You will have included the Benefits Realization Plan among the documents that you handed over. Now it’s the time for the operational team to own that document and work the plan.
There are a whole load of things that you need to do to close down your project. And they al start once you have completed your project handover.
But they form a big topic. So I shall refer you to my article, ‘Project Closure: Your Complete Guide to How to Close-down Your Project’. It’s your obvious next step!
To support your Project Handover process, I recommend you develop a set of templates and checklists. These will support you in implementing a compliant and repeatable process. Do take a look at our article, ‘Project Management Simplified: The Power of Checklists and Templates‘.
Our Project Management Templates Kit has six project closure templates:
Project Management Checklists prevent mistakes, omissions, and duplication…
We also have a set of Project Management Checklists. Included among these are:
But this one is on the house:
What have we missed out? If you spot anything substantive, I’ll reward you with a free set of Project Checklists. Do share your own experience in the comments below.
The best reference I have found to supplement your knowledge on project handover will get you thinking about how to hone your own handover process. And, happily, it is freely available online, in PDF format. It is a short report published by the Association for Project Management, called ‘How can we hand over projects better?’ Do take a look.
Dr Mike Clayton is one of the most successful and in-demand project management trainers in the UK. He is author of 14 best-selling books, including four about project management. He is also a prolific blogger and contributor to ProjectManager.com and Project, the journal of the Association for Project Management. Between 1990 and 2002, Mike was a successful project manager, leading large project teams and delivering complex projects. In 2016, Mike launched OnlinePMCourses.
Please log in again. The login page will open in a new tab. After logging in you can close it and return to this page.