The project is finished. The files have been sent. The launch happened.
Then, a month later, someone asks why a decision was made. The answer is trapped in two email threads, a task board, a design file and the head of the person who has moved on to the next urgent thing.
That is not an administrative failure. It is where delivery can stop being useful.
A handover is the part of the work that makes the work usable once the people who made it are no longer in the room. It should be treated as a product in its own right: designed for a real user, clear about what it enables, and tested against the moment it will be needed.
A strategy has not survived until the next person can use it
Strategy often appears complete at the approval point: the direction is agreed, the work is delivered and the launch is moving. That is an important moment, but it is not the final test.
The next person still needs to decide what to change, what not to disturb, who can approve an exception and what evidence would justify a different route. If those answers only exist in a presentation, a private conversation or the memory of the original team, the strategy has not yet become operating guidance.
A useful handover carries enough context for the work to continue without turning every later question into a forensic exercise. It does not attempt to predict every future situation. It preserves the decisions, dependencies and responsibilities that allow competent people to make the next decision well.
A folder is not a handover
Most handovers become an export of whatever happens to exist at the end: folders, links, recordings and a long email.
Those things may be necessary. They are not sufficient.
A folder tells someone where files are. It does not tell them which version is current, what was approved, what remains unresolved or what would be dangerous to change. A recording preserves a conversation. It does not make a decision easy to find when the project has moved on.
The missing ingredient is operational context: the information a competent new person needs to continue the work without re-opening every old debate.
Five survival checks
Before treating a strategy, system or delivery as handed over, test whether five things are visible.
1. Decision
Can someone find the important choice, the reason it was made and the condition that would justify reopening it? A handover should not preserve every conversation. It should preserve the decisions that constrain the next move.
2. Dependency
Can someone see what this work relies on and what relies on it? A page may depend on an approved offer. A measurement view may depend on a specific event definition. A change that appears local may alter a linked journey, asset or operating rule.
3. Owner
Is it clear who can make the next decision, maintain the work and approve an exception? Ownership is not a name dropped into a document. It is a visible responsibility with a route for the next question.
4. Acceptance
Is there an observable way to tell whether the work is ready or still incomplete? “Make it better” is not an acceptance criterion. The handover should show the purpose, agreed requirements and unresolved gaps without pretending that taste or activity is proof of completion.
5. Continuity
Can the next owner find the current source, known risks and next useful action? Continuity is the difference between a delivery that can evolve and one that has to be rediscovered each time it changes.
These checks are a practical test, not a fixed delivery method. A small piece of work may need a lighter version; a complex programme may need more. The point is to make the relevant information inspectable before the original context disappears.
The parts of a usable handover
A useful handover answers one question: “What do I need to know to restart this responsibly?”
Context snapshot: project, purpose, current state and last update.
What is complete: delivered or approved work, stated factually.
What is moving: in-progress work separated from blockers, with owners.
Decisions to respect: the choice, the reason and what would justify reopening it.
Dependencies and access: current locations, connected systems and owners; never credentials in the document.
Risks and known traps: fragile integrations, assumptions and recurring errors.
Acceptance and next actions: what ready means, what remains open and the next useful actions in order.
This is not a memory dump. It is a controlled summary of the things that change future decisions.
Test it with someone who was not there
The most useful test is not whether the handover looks comprehensive. It is whether someone who was not present can answer a real operational question without guessing. The person writing the handover knows the project best, which creates a predictable blind spot: they omit the context that feels obvious to them.
Before sending it, ask someone who was not close to the delivery to find three things:
The current source of truth.
The most important unresolved risk or dependency.
The next action, and who can decide if that changes.
If the answers require searching across old threads, private memory or several competing documents, the handover is not yet doing its job. Repair the missing decision, dependency, owner, acceptance condition or continuity route while the original team can still explain it.
This is not bureaucracy for its own sake. It is how a project retains value after the adrenaline has gone.
The final artefact should not be a folder of leftovers. It should be the first useful page for whoever comes next.
No published comments yet.