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:
3.managing your environment (client and team)
So if you find yourself in this kind of situation, here’s the checklist I promised a while ago.
1.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
2.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
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
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!
*****************-----------------Above article was copied from net---------------***************************
1 post • Page 1 of 1