“It’s all in the documentation.” The previous project manager says it sincerely, shakes your hand, and from Monday is on another team. Three weeks later the client asks about a report they were apparently due to get by the end of the month. The documentation doesn’t mention it. The promise was made on a phone call and stayed in the head of someone who no longer works here.
Taking over a project mid-flight differs from starting a new one in one respect: you inherit commitments you never saw. The plan, the schedule and the risk register show what somebody wrote down. The rest lives in conversations, emails and habits.
A new PM’s reflex is to open the schedule and start tidying it. That is understandable, because the plan is the only thing visible straight away. It is still better to start with people.
Questions for your predecessor
If your predecessor is still available, an hour of conversation with them is worth more than a week of reading documents. There are five questions worth asking.
What did you promise, and to whom, that isn’t in writing? This is the most important question. Every project has a few arrangements made verbally, and the client remembers them far better than the team does.
Which decision is hanging in the air? There is almost always something that should have been settled a month ago and is still waiting. Better to hear about it from your predecessor than from the sponsor.
Who really decides on the client’s side? The chart says one thing, practice says another. The person who signs the acceptance reports is often not the one who says “yes” or “no”.
Who on the team can I rely on, and who is overloaded? This is in no document, and it determines what can be done in the first month.
What would you do differently if you were staying? People answer this one with surprising honesty once the project stops being theirs.
When the predecessor is already gone
Sometimes there is nobody to ask. Then the same questions go to three people.
To the sponsor: what do you expect over the next month, and what would you take as a good sign. To the person who has been on the team longest: what was agreed outside the meetings. To the client: what are you waiting for from us right now.
The last question takes courage, because it reveals that the new PM doesn’t know something. In my experience the client would rather hear that question in the first week than discover the gap in the fourth.
Why not to touch the plan right away
A project plan is a record of promises. Every date in the schedule tells somebody something: the client, when they get a version to test; the team, when the crunch ends; the sponsor, when they can announce the launch.
Changing the plan before you know those promises breaks some of them without the person making the change knowing it. The new PM moves a task by a week because it is more logical that way, unaware that this is the very date the predecessor confirmed to the client three times.
A good practice is to leave the plan alone for the first week or two and spend that time only listening. It is also the fastest way to learn the unwritten rules, since every project runs a different way depending on who runs it. The exception is anything that is on fire: if something is stopping the work today, it has to be dealt with today.
What is worth saying straight away
There is one thing a new PM can do on day one without risk. They can tell the team, the sponsor and the client what is changing and what stays.
Three sentences are enough. I am taking over the project as of today. For the next two weeks I am changing nothing in the plan and I am talking to each of you. After that I will come back with what I see and a proposal for what comes next.
A message like that calms the people who fear a revolution, and gives the new PM time to understand what they have walked into.
One question for this week
If you had to hand your project over to someone else tomorrow, what would that person need to hear from you because they won’t find it in any document?
All situations described in this article are based on real events, but contain no company names, no individual names, and no data from any specific project.
