7

I am about to take over the project manager role for a project being run by another development manager. The project is currently in an early planning phase.

Which topics should I make sure I get covered with the current development manager so that the hand-over process is comprehensive?

6

In terms information you get when taking over a project most of the time the more means the better. Of course if the data you get is structured well it is way more useful than just "memory dump" from your predecessor, but it's still better to have information buried somewhere in email archives than not having it at all.

When talking about specific topics I'd focus on:

  • Every arrangement with the client which was already made. This one is crucial. As you don't want to be surprised on the way you need to know pretty much anything which was agreed with the client so you plan to fulfill your promises. This information is usually the most difficult to get as often arrangements are made through many different channels: email, phone calls, on meetings etc. If we discuss product which is built not for external customer but internally within the company the point is still valid - just exchange "client" with "product manager" or other key stakeholder you have.

  • Contacts. You need a list of contacts to every important person involved in a project both: on client's and on your side.

  • Project scope. Since you're in planning phase you should know what you're going to build pretty well at least on a general level.

  • WBS. Since planning has already started my guess is someone took some effort to prepare some kind of Work Breakdown Structure trying to analyze in more detail what exactly will be done.

  • Architecture. Again, it usually something which is prepared pretty early. Architecture should tell you how the application will be built from the technical perspective. It also has some consequences in terms of hardware and infrastructure needed to deploy the project. I assume you will also learn everything about technologies you're going to use from architecture document.

  • Project plan. It may be ready or, more likely, people are working on this one at the moment. However chances are good at least general schedule is ready. What is most important information here is deadline (if there is any), especially when it was already agreed with the client.

  • Project team status. Who is in the team? What are their skills? Do those skills cover needs of the project? If you were later in planning phase you might have some insight how many people you'd need and which specific skills are/aren't covered. On early stages it still can be pretty vague.

  • Any other project-related stuff which might be available. This includes potential risks, stakeholder analysis, additional preferences (e.g. project should be completed sooner than planned if possible), business background (especially when the project is addressed directly to end-users), budget (if known), etc.

2

Please, please please..... go over the documentation of decisions and issues. As a PM who has taken over projects, I have found my biggest challenges have been searching for answers that already exist.

2

Pawel's list is very good. For what it's worth, the PMBOK also has a good one: the contents page :-).

Go over each Knowledge area and its processes and check what has been done, or not done.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.