Here's the pattern. A technology project is initiated to solve a real problem. A development team — internal or external — builds it. There's a successful user acceptance test. The system goes live. And then, over the following weeks and months, it slowly deteriorates. Support tickets accumulate. Users find workarounds. Performance degrades. The organisation that built the system loses context, and the organisation that's running it never had it.
This is handover failure. It's endemic, it's predictable, and in most cases it's entirely preventable.
What actually fails at handover
The handover problem is not primarily a technical problem. The code works. The infrastructure is configured. What fails is the transfer of context — the knowledge that lives in the heads of the people who built the system and never makes it into any document that the people who operate the system can find and use.
The operational runbook doesn't exist or is out of date. A runbook is the document that tells an on-call engineer what to do when the system does something unexpected at 2am. When this doesn't exist, every incident becomes an investigation. When it's out of date — which is most of the time — it's actively misleading.
Ownership isn't assigned. Systems need owners — a named person or team who is responsible for its performance, its costs, and its roadmap. When a project ends and the development team disperses, the system exists without an owner. No one is accountable when something goes wrong. No one is responsible for keeping it current.
The "why" is lost. The system was built to solve a specific problem, with specific constraints, making specific trade-offs. When the people who made those decisions are no longer around, the people maintaining the system don't understand why it works the way it does — and they break it by trying to fix it.
The receiving team wasn't involved. The most common structural failure: the operations team is handed a system they had no involvement in specifying or building. They didn't attend a single design review. They didn't know it was coming until go-live. They don't understand the decisions that were made, and they have no relationship with the people who made them.
"Handover fails when it's treated as an event that happens at the end of a project rather than a process that runs through the whole of it."
How to fix it — the structural approach
The fix is not to spend more time writing documentation at the end. It's to design the handover into the project from the start, with the operations team treated as a stakeholder from day one.
In practice, this means four things. First, the operations team lead should be a named stakeholder in the project from initiation. They should attend design reviews, not to approve every decision, but to understand them. When they later have to operate something they've been part of designing, the context is built in.
Second, documentation should be produced incrementally throughout the project, not at the end. An architecture decision record written when a decision is made takes ten minutes. A retrospective explanation of the same decision written six months later takes two hours — and is less accurate. Running documentation is a discipline, not a project end milestone.
Third, the runbook should be tested before go-live. Take a scenario — a specific type of failure, a specific operational procedure — and ask the receiving team to execute it using only the documentation provided. If they can't do it, the handover isn't ready. This is uncomfortable. It's also far cheaper than the same discovery in production.
Fourth, set a named system owner before go-live, not after. The system owner is accountable for performance, cost, and ongoing development prioritisation. They need to exist before the development team disperses, while they can still transfer knowledge directly rather than via documentation.
The organisational pattern that makes this hard
Most technology project governance is structured around the build phase. The steering committee meets regularly during development. Resources are allocated. Risks are tracked. The go-live is celebrated. And then the committee stops meeting, because the project is "done."
This treats the go-live as the destination rather than the starting point. A system's value is not created when it goes live — it's created over the months and years it's in operation. The governance structures that support it need to reflect this. A post-go-live operating model — with defined ownership, performance metrics, a review cadence, and a clear escalation path — is as important as the build-phase project governance. In most organisations it doesn't exist.
Running technology projects or overseeing digital delivery?
Structuring handover effectively is something I help teams get right. Get in touch →
