Project transition checklist
Why transitions fail
A project transition fails when the new owner spends the first two weeks reconstructing what the last owner already knew. The information exists, but it is scattered across decks, spreadsheets, Slack threads, and one person's head. The new owner asks basic questions, waits for answers, and slowly assembles a picture that the old owner could have provided in an afternoon.
The goal of a transition Brief is to make the first week unnecessary. The new owner should be able to answer the obvious questions without asking anyone, and to ask the non-obvious questions with precision. When they do ask, it should be because the answer genuinely requires judgment, not because the information was never written down.
Transitions are especially fragile at the end of a project, when the outgoing owner is tired and the incoming owner is optimistic. The outgoing owner forgets what was hard; the incoming owner does not yet know what to fear. A Brief bridges that gap by forcing the important context onto the page before the handoff happens.
The eight artifacts
These eight artifacts cover the surface area of almost any project. If one is missing, the new owner will discover the gap at the worst possible time — usually in a meeting where they are expected to know the answer.
- Scope as it stands today, including the diff from the original scope. Note what was formally changed and what was informally assumed.
- Budget: approved, spent, committed, and remaining — with the date of each figure. Include burn assumptions and who authorized each number.
- Schedule: current milestones and every date that has already moved, with reasons. Include dependencies that are not on the critical path but could become critical.
- Stakeholder map: who signs off, who must be consulted, who only wants updates, and who has been hard to reach. Include working styles and escalation paths.
- Dependency list: teams and vendors you cannot ship without, and the contact for each. Note which dependencies are healthy and which are at risk.
- Risk register with owners, not just descriptions. Include risks that have already materialized and how they were handled.
- Decision log: what was decided, by whom, and what was rejected. Rejected options matter because they resurface when pressure increases.
- Access inventory: systems, repos, dashboards, shared drives, and who holds the credentials. Include pending access requests.
Each artifact answers a different question. Scope answers 'what are we building?' Budget answers 'what can we spend?' Schedule answers 'when?' Stakeholders answer 'who decides?' Dependencies answer 'what could stop us?' Risks answer 'what should we worry about?' Decisions answer 'why did we choose this?' Access answers 'how do I get in?'
Capture in one pass
Set a ninety-minute block. Dump the last month of status updates, the budget export, and the two most recent steering-committee decks into a single Brief. Then read the generated summary and correct only what is wrong. Editing is faster than authoring because the raw material already exists.
Resist the urge to reorganize everything into a perfect narrative. The Brief's structure will surface the relationships between artifacts. Your job is to make sure each artifact is represented accurately, not to write a novel.
If a source is missing, note it explicitly. 'Budget export for Q2 not yet available' is better than silence. The new owner will know what to chase down instead of assuming the information does not exist.
Test before you hand over
Ask the Brief the questions your successor will ask. If an answer is thin, you know exactly which source is missing. Repeat until the eight artifacts each answer cleanly. This test is the best way to discover gaps while the outgoing owner is still available to fill them.
Useful test questions include: What is the next milestone and who owns it? What is the single biggest risk this month? Where is the budget most likely to overrun? Who has decision authority if the sponsor is unavailable? What would happen if our largest vendor delayed by two weeks?
The first thirty days
A transition is not complete when the Brief is sent. Keep the Brief alive for the first thirty days by updating it as decisions are made and assumptions change. The new owner should treat it as the single source of truth until the project stabilizes and they have built their own mental model.
At the end of thirty days, review what was missing from the original Brief. Use that feedback to improve the next transition. The best teams treat handoffs as a process to be refined, not a ceremony to be endured.
Red flags to watch
Some signals indicate that a transition Brief is incomplete even if it looks thorough. Watch for these patterns.
- Every source is more than thirty days old. Recent context matters more than comprehensive history.
- No rejected options in the decision log. A project without rejected options is either very simple or missing its history.
- The risk register has no owners. Risks without owners are not managed; they are merely observed.
- The access inventory is blank. If the new owner cannot log in, nothing else matters.
Scaling transitions across a team
Once one transition Brief works, turn it into a template. Standardize the eight artifacts and the test questions, but leave room for project-specific sources. Templates accelerate the process without forcing every project into the same shape.
Review the templates quarterly. Projects change, tools change, and the questions new owners ask change. A template that was perfect six months ago may now be missing the most important artifact. Keep the template alive the same way you keep the Brief alive.
When a template is shared across a team, assign an owner to it. Otherwise, everyone assumes someone else will maintain it, and the template slowly drifts out of date. A stale template is more dangerous than no template because it creates a false sense of completeness.
Measure template adoption by tracking how many transitions use it and how complete the resulting Briefs are. Low adoption usually means the template is too rigid or too long. Incomplete Briefs mean the template is missing a prompt or artifact that the team actually needs.
Put it into practice
Open an example Brief and ask it the questions from this guide, or create your own Brief in a few minutes.