What are the project handover checklists?

Handing over a project or switching the PM on a project can be tricky and expensive.

First check your project charter or project initiation documentation. If you’re working in a PMI environment and you have a maintained project charter, most of the important stuff should be in there. Making a project less dependent of the PM individual is a part of the reason why a project charter exists.

The checklist can be split in 4 parts:

• essentials
• practical things
• managing your environment (client and team)
• experience

Project Hand-over Essentials

For each project you are about to hand over, make sure you cover the following things for the new PM.

• get the project charter if you have one or collect the project initiation documentation
• gather all business case information
• collect the documents involved in the initial offer, make sure to indicate clearly which one is the signed copy (important in order to understand initial, often commercial expectations)
• gather all change requests (amount, description and timing for each instance), this can be short but the key is to make a complete list
• write down what the roles are at the client’s office (who’s the sponsor, who will check the quality of the deliverables, …) if you have a RACI (responsible, accountable, consulted and informed) chart this can help
• list your contacts and their coordinates, write down how frequently you communicate with them and what topics to cover
• introduce the new PM to the client (very important if you are the single point of contact)
• introduce the new PM to the delivery team(s)
• suggest next steps for the new PM

Practical Things To Handle

Also important to think about, because it might not always be that obvious.

• list of people who are working on the project and who have worked on the project, together with their skills (again a RACI matrix can be of great help here if you have one)
• describe how you make a status, show how you report status
• if you’re responsible for a part of the execution of a project: details of the product environment (location descriptions, passwords, keys, key cards, …)technical or practical dependencies, you probably have those in a risk log somewhere (examples: if system X would ever break down, this will cause project Y to fail; project Z is dependent of service Q, having direct effect on the SLA (Service Level Agreement) of project Z once it’s done; …)
• list and talk about things that are (still) not clear to you, describe what blanks still need to be filled in

Environment Support

Manage the cost of the hand over operation and handle your boss or your client during this time. You need support from your environment.

• explain how much time you’re going to take for the hand over (preparation and meetings), consider carefully how much detail you share with a client here
• allocate time for the hand-over, if you only have a week block 3 to 4 hours a day to properly introduce a new PM
• alert clients and customers who you have frequent contact with that you will be less responsive during a certain period (give yourself room to properly introduce the new PM)
• explain to your boss what you’re giving the new PM, if he or she should mess up, it should not be your fault
• keep track of project handover time on a separate sheet
• make sure to keep your team(s) well informed during the course of the operation, be honest as always

Transferring Experience

You gathered experience on a project that the new PM can’t possibly get from your documentation or advice, this is very important for both of you as well as your boss to understand. But you can help this by talking about the subtle informal things.

• patterns of team members, and subcontractors you noticed (examples: over/under-estimating, action triggers, …)
• patterns you notice from customer (examples: level of indecisiveness, easy/hard to get test users from, provides great subject advice if asked (in)formally, need to call after hours to get in touch, need to see face to face to get things done …)
• subcontractors you know who owe the company something (and I don’t mean financial dept)
• freelancers that you know you can trust for certain tasks
• “power play” or political issues that can/do go on that may impact the project

I mentioned here before that every PM has his own style, make sure to tell your successor that he or she doesn’t need to copy your style to be successful. Some people – mostly juniors – feel obliged to, but it will work against them.

If you’re handing over a project or a set of projects there’s a lot you can do to help out your fellow PM who’s picking up where you left off.

Consider your own responsibility in those last steps with integrity, and remember, “do what is good for the project”.

If you have anything to add, on this list, please do, I’m always interested!

Originally Listed in Quora .