A Checklist for Handing Over a Project

Published on Oct 29th, 2010 by

A Checklist for Handing Over a Project

Handing over a project or switching the PM on a project can be tricky and expensive, but if you’re the PM who has to leave a project behind to someone else I have some advice for you.

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.

I’ve split up the checklist in 4 parts:

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

So if you find yourself in this kind of situation, here’s the checklist I promised a while ago.

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 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 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

Transfering 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, or want to ask me any questions on this list, please do, I’m always interested!

Latest Comments (10)


Hi Bert. An excellent and comprehensive list. A small addition I would make also in the project experience part would be to make the new PM aware of any “power play” or political issues that can/do go on that may impact the project.
Thanks for sharing

November 2, 2010 19:36 Reply


BTW – love the new blog look and feel!

November 2, 2010 19:36 Reply


Hi Barney, thanks, glad you like it! I'm adding your suggestion to the checklist too, great feedback.

November 03 2010 08:35 am


Love this – it is well considered and practical.

July 4, 2011 07:29 Reply


Thanks Tess, I'm glad you like the list. Let me know if you have a specific question. The flow of articles on the site has been subzero lately because of my high operational workload but I'm still here.

July 08 2011 23:00 pm

Journeyman PM

[…] A Checklist for Handing Over a Project […]

February 1, 2012 13:31 Reply

PPM Community – Programme and Project Management Community Blogs

[…] A Checklist for Handing Over a Project […]

April 17, 2012 10:24 Reply

Von Kee

Good one! Like it.

February 27, 2013 05:59 Reply


Great list. Does this also work for developers who are leaving? Or that needs to be centered around a more technical document?

August 12, 2013 03:35 Reply


Hi Angie,

Yes, it will work too with developers, but you'll probably spend more time on practical things and transferring experience. I recommend you make sure to go over all the projects the developer worked on and listing where the code is he or she wrote, check to see if the projects are still live and if there are any special credentials required to take of the project (like administration passwords, 3rd party account credentials or API keys, etc.)

- Bert

August 12 2013 10:34 am

Post a Comment

Posting your comment...

Subscribe to these comment via email


Social Widgets powered by AB-WebLog.com.