This episode we talk about that make-or-break moment in project closing: handing over your project deliverables. If you plan your project right, this can be a moment of victory for your team, your stakeholders, and for yourself. But if you don’t plan for it, handover can become a never ending death march to nowhere. Kate and Kim talk about how to setup this key transition for success, and talk about some pitfalls you are going to want to avoid!

JOIN THE HAPPY HOUR!

Get access to all podcasts, PDU certificates, bonus content, exclusive member Q&A webinars and more from our membership! https://pmhappyhour.com/membership 

STUMP THE PM’S!

We love to hear about your tough PM issues, so please hit us up at podcast@pmhappyhour.com or on Facebook at facebook.com/pmhapyhour and we’ll see if we can help you. If we use your question, we’ll send you a PM Happy Hour coaster you can enjoy at your next happy hour.

Check out this episode!

Show Notes

Success of a Handover [2:40]

Handover can be an extremely rewarding part of the project as you hand over the project to its owners. Sometimes, however, it can be easy to hand over a project to its owners without giving them the information they need to make it a success. In this case, something you’ve worked hard on can become a complete failure, because if your project doesn’t work how it’s supposed to, it’s not a successful.

Who are you handing it over to [5:00]

The first step in a successful handover is knowing who this project is for. This can be a product owner, a department, a customer, a consumer- whatever the case, you and the future owners need to be absolutely clear about ownership. This clear owner can be difficult to define in many cases, but it’s never too early in the project to define it.

Your future owners need to be involved to some degree in the project- they should know what’s coming, and feel included. Even if their degree of involvement is small, their ability to feel like they have a say in the product is important to creating the expected product.

Project Care [8:09]

Do the future owners know how to maintain and use this project in the future?

You need their operational constrains and requirements- that is, the team’s ability to manage and support the tool. The project/product needs to make sense in the context of the skills of the owners. They need to have time to prepare for this project, whether that requires extra time, training, or resources.

Reaching out to them early to invite them to be an active participant in the project can go a long way, and prevent the owners from feeling like they had a project dumped on them they don’t know what to do with. Building good relationship with your operational people will serve you well in project handoff.

The Importance of Roles and Responsibilities [12:54]

Be sure to outline very clearly what you versus the operational team are responsible for. This is especially true in very large projects. Not doing so can lead to operational teams pushing for your team to do the bulk of this work.

Understanding how your organization budgets for this is important as well, as some companies prefer to allocate more budget to operational implementation in the project itself. Therefore, know how your budget is expected to support operational costs, or if it supposed to at all.

Benefit Realization [15:50]

How will the organization measure or track the benefit the project was expected to give?

This can drive additional requirements you didn’t account for; you may need, for example, to build another mechanism to track how successful the project is. It’s important to understand what metrics they’re looking for, and if there’s anything you have to do to make this trackable.

The Handover [17:33]

In your planning, it’s critical to track what this handover looks like, and who is in charge of what. This could include:

• formal change management approvals
• operational acceptance testing
• operational documentation or processes
• creating or developing maintenance processes/tools
• operational staff training
• building a new service

Goodbye [19:40]

You need to identify when and how you should say goodbye. At some point, the project will have to leave, and you need to clearly define this, or you could be in a situation where you are helping maintain a project for far too long. Project close documents can help out with this, as well as your RAID log and scope documents- these are all pieces of documentation that help build the case and expectation for handoff.

Whenever possible, have the operational team take front line customer facing support from the second the project is in customer use. This way, the project team can help the operational team, rather than the end users.

Recap [25:11]

We defined who will own your project baby. Then we made sure that they knew how to care and feed for it, made sure there as some sort of metering of benefits, and created a crisp handover.

Key Probing Questions [25:50]

• Who owns this when we are done?
• Are they equipped to take this on and maintain it in a way that gets the expected value out of it?
• How and when will we make the handover – EXACTLY?
• Are the acceptance criteria of the future owners (operations) accounted for?

You might be in trouble if… [27:13]

• You don’t know who will own the product of your project
• Future product owners are not involved from the beginning of your project
• You don’t know if the future owners of the product understand how to care and feed it
• You aren’t sure if anyone has accounted for the Operational requirements of the product
• You haven’t agreed in advance for how to say goodbye