Score the handover by what the next team can do.
The zip arrived, the README is from mid-sprint, and the message says you should be good. Six weeks later nobody can deploy cleanly. A handover is finished when the next team can deploy, diagnose, recover and change the system on their own.
A useful software handover is an operating test: can the next team deploy, diagnose, recover, and change without tribal memory? Score those dimensions 0–2 with evidence, apply a pass rule, and refuse “complete” when Deploy or Support is zero. Source delivery alone is not ownership.
Handover is a test, not a file drop
A vendor sends a zip, a README last touched mid-sprint, and a message that says you should be good. Six weeks later the next team cannot deploy cleanly, cannot tell a healthy failure from a broken one, and cannot change a feature without calling someone who has left.
A useful handover is not whether the code arrived. It is whether the next team can deploy, diagnose, recover, and change the system without tribal memory.
Score what the next team can do
Score each line 0, 1, or 2. Write the evidence under the score: a runbook section, a successful deploy by someone who did not build it, a log they could read, a restore they practiced.
Deploy. Can a named person put a known version into the target environment without a private script? 0 means they cannot. 2 means they did it, and the steps are written down.
Diagnose. When something looks wrong, can they tell what is happening from logs, queues, and state, without guessing? 0 means the only diagnostic is a person.
Recover. Is there a practiced way back from a bad deploy, a bad write, or an outage? 0 means recovery is "we'll figure it out."
Change. Can the receiving team make a small, real change and ship it? 0 means every change still routes through the people who left.
Support. Is there a named path for the first weeks: who answers, in which hours, and what they will not own? 0 means support is a vibe.
Pass only if deploy and support are not zero, and no line you marked essential is zero. Source delivery alone is not a pass.
How the work moves
Score handover on operating capability
- Deploy
Ship a known-good build without the original authors on a call.
- Diagnose
Tell healthy, degraded, waiting, and failed apart in the record.
- Recover
Find incomplete state and take the next safe action.
- Change
Edit a bounded feature with a known review and test path.
- Support boundary
Know who answers, for how long, and what is out of scope.
Source delivered is not the same as a team that can operate.
How to run it
Do it in two sittings. First, the people handing over walk the receiving team through deploy and a failure. Second, the receiving team tries a small change without the original authors in the room.
Score during the sittings, not from memory a week later. Attach the evidence to the package. A screenshot of a chat is weaker than a link to the runbook they actually used.
If a line is conditional, name the person and the date that will make it a 2. "Complete" with an open zero is how handovers get signed and then quietly fail.
What this catches
It catches the zip-file handover. It catches a runbook that only the author can follow. It catches support that was promised in a proposal and never staffed.
It does not invent a score for the industry. You are scoring this package, against this team's ability to run it.
Decision guide
Source delivery vs operating handover
| Consideration | Looks like delivery | Passes the scorecard |
|---|---|---|
| Artifacts | Source zip and a README. | Reproducible deploy path with evidence. |
| Status | “Should be good” in chat. | Observable signals operators can use alone. |
| Incidents | Call the builders. | Documented recovery for top failure classes. |
| Roadmap edits | Only original authors know the safe path. | Change map with review boundaries. |
| After go-live | Informal goodwill support. | Named window, escalation, and exit. |
Put this into practice
Copy the five lines onto one page before the next handover meeting. Run both sittings. Apply the pass rule. Put remediation owners on anything that is not a pass.
If the gaps are ownership of the application or the automation around it, that work sits under web applications and business process automation.
Related work: Sutton Place.
We build alongside the people doing the work.
Bring us the problem you’re thinking about.