How to Onboard a New PM Without Losing Project Memory
A capital project changes hands and, on paper, the transition is clean. The outgoing project manager forwards the folder, introduces the new PM in a meeting, and wishes them well. Two weeks later the new PM is staring at a decision they didn't make, can't explain, and can't safely reverse, because nobody recorded why it was made. The title transferred perfectly. The project did not.
Onboarding a new PM well is not about the org chart or the access permissions. It is about transferring the memory of the project, the accumulated reasoning that lets someone steer rather than just hold the wheel. Do it badly and the project loses months while the new PM re-learns what the last one already knew. Do it well and they are making good calls in their first week. The difference is almost entirely about what you write down before they arrive.
Four things every handover forgets
The file list is the easy part, and it is the part most handovers stop at. The harder, more valuable transfer is the context that never made it into a document. In practice, four things go missing:
The why behind decisions. The folder shows what was decided; it rarely shows why one option won and another lost. That reasoning is what stops the new PM from re-opening settled questions.
The live commitments. Promises made to a contractor, a council, or a community, often by email or in a meeting, that bind the project but live in no plan.
The relationships. Who to call when something stalls, who is reliable, who needs a heads-up before bad news. This is real project infrastructure and it usually walks out the door.
The active risks. The things the outgoing PM was quietly watching that haven't gone wrong yet.
A handover that actually transfers the project
A good handover is a short, deliberate process, not a forwarded folder. Run it as a sequence the outgoing PM completes before they go, not a conversation you hope to have on their last afternoon:
Write the decision log. Five lines per major decision: what, why, who approved it, what was rejected, and what would have to change to revisit it.
List the open commitments. Every outstanding promise, where it was made, and what it obligates the project to do, with the source so the new PM can verify it.
Map the relationships. The people the project depends on, what each one cares about, and the history that a stranger would not guess.
Name the live risks. What is being watched, why it matters, and what the trigger is that would turn a watch into an action.
Do a working handover, not a goodbye. Walk the new PM through the record together, so questions surface while the outgoing PM can still answer them.
The chart makes the point that experience already taught you: two people can sit at the same desk with access to the same drive and steer the project completely differently, depending on how much of the why was written down before the change. The folder is the same. The memory is not.
Make the record do the remembering
The deeper lesson is that institutional memory should not depend on whether your best PM happens to still be in the building. A project whose reasoning lives only in one person's head has a single point of failure with a pulse. The fix is to make capturing the why a habit during the project, not a scramble at the end of it, so that a handover is a matter of pointing someone at a record that is already complete.
This week, write the five-line decision log for the most important call your current project has made. If you struggle to reconstruct why, you have just learned what your successor would have faced, and you have the rest of the project to make sure they never do.
Onboarding is really a memory problem, and memory is a records problem - more on building a project memory that outlives the people in it turns this from a personal skill into a system.
