Handover to operations: a checklist, and the test that proves it worked

A handover document says what was handed over. Only a live run shows that it was. The difference is whether the receiving team can run a real job without calling the sender.

The short answer. A handover to operations is the point where responsibility for a new operation, program, facility or system passes from the people who built it to the team that will run it. It is done when that team has run a real job end to end while the sender stayed out of it. Everything else is preparation for that run.

This page is about handing an operation to the team that will run it, not about one person leaving a role.

What a handover to operations is, and when it is finished

In most projects the handover is an event: a meeting, a folder, a signature. The builders move on, and the first weeks of running show what was missing. The first unusual morning ends with a call to someone who has left.

So done has to be something you can observe. A handover is finished when the receiving team has run a real job from start to finish, with the sender watching and silent, and the result met a pass standard written down beforehand.

The handover process, in order:

1. Agree in writing what ready means and what a pass looks like.
2. Assemble the package: owners, procedures, access, open issues, contacts, history.
3. Walk the receiving team through it and complete the checklist, with evidence.
4. Run the live-run test: a real job, run by the receiving team, with the sender silent.
5. Fix what the run exposed. If it was not a pass, run again on a different job.
6. Sign off, naming any exceptions, and move responsibility.
7. Keep a support window with a written end date, then step back.

Handover comes last. On the five phases of operational readiness it is phase five, after the trial and go live. It is planned from phase one, because what counts as ready has to be agreed at the start.

What the receiving team needs to run it alone

A handover document is the written part of the package: what the receiving team needs to run the operation without the people who built it. It answers six questions.

• Who owns what. Every process, system and decision has an owner, as a role with today's name beside it. An item with no owner on the receiving side has been left behind, not handed over.
• How the work is done. Procedures for the work the team will actually do, exceptions included, with an owner, a trigger and a done condition for each step, checked against real runs. Why SOPs go out of date covers keeping them current.
• How to get in. Accounts, permissions, keys, licenses and physical access, held by the receiving team under its own names. Access in the sender's name is where first weeks stall.
• What is still open. Everything known to be unfinished, broken or risky, each with an owner and a next step. The receiving team is owed the bad news. Leaving it out only moves it to a worse day.
• Who to call. Vendors, contractors and specialists, and an escalation route for each kind of problem, including who decides when the first answer fails.
• Why it is built this way. The decisions behind the setup, the options turned down, and the incident behind each odd-looking rule. It is the part never written down, and it stops a new team from "fixing" something that was done on purpose.

Most are written from the sender's account, one of the four sources of truth. Check them against the records of the work, as the four sources sets out. The sender remembers the design. The records show what happens.

The handover checklist

A handover checklist is the list of what must be in the receiving team's hands before responsibility passes. Most stop at the item: procedures provided, access granted. That records what was sent, not what was received. The useful version puts evidence next to every item, and the receiving side confirms each row, not the sender.

Do not wait for every row before the live run. It shows whether the rows above it were true, and a ticked item that fails the run is unticked.

The live-run test

The receiving team runs a real job end to end, using only the package, while the sender stays quiet. It is the handover test in step 06 of how to document a process, applied to a whole operation: watch someone follow it, and answer nothing.

Set it up

• Use a real job. From the live workload, normal rather than easy, reaching at least one decision. A rehearsal tests the rehearsal.
• Write the pass standard first. What the finished job must look like, which steps the receiving team must do itself, and what help is allowed. Both leads agree it before the run.
• Silence the sender, and appoint an observer. The sender answers nothing, except to prevent safety risks or harm that cannot be undone, as agreed in advance. The observer writes down everything in the next list.

What to watch

• Questions. Each is a gap in the package, and it shows which one.
• Pauses. Waiting for access, a decision or a person points to a missing owner.
• Workarounds. Steps done in a way the procedures do not describe.
• Reaching out. Any call or glance toward the sender or the project team. These are the real dependencies.
• Decisions. Who made each, and whether they are the owner the package names.
• Errors nobody noticed. Check the output against the done conditions afterward. A finished job can be wrong.

What counts as a pass

If it fails, fix the package and run again on a different job, because the team has learned the first job's answers.

Handover when the operation cannot stop

Many operations cannot pause for a handover. The work keeps arriving, and the people running it are the same people being trained, which is why the phases of operational readiness overlap on a running operation. Three mechanisms make it workable.

• Overlap. For a defined period both sides are responsible, and the line is drawn by piece of work, not by date: one shift, site or type of job at a time. Each slice gets its own checklist and live run.
• Shadowing, both ways. First the receiving team watches the sender. Then the roles reverse: the receiving team runs real work and the sender watches. That is the live-run test. Last, the receiving team runs alone, with the sender reachable but absent.
• A named fallback. Before the receiving team works alone, write down who takes over if a run goes wrong, what triggers that, and how the work is returned. It is a named person with an end date, not "the project team" in general.

Sign-off that means something, and the support window after

A signature is worth what it is attached to. The receiving side's accountable lead should give it, not only the sender, and it should travel with the evidence: the checklist, the live-run record and the open-issues register. It says one thing: we ran it, it worked, and it is ours now.

• Responsibility moves at sign-off, not at the date in the plan. If the date arrives and the live run has not passed, the date moves, or the sender stays accountable, in writing. With overlap, this applies slice by slice.
• Exceptions are named. A sign-off can read "accepted, with these exceptions", each with an owner and a date. That beats a clean signature over known gaps.

After sign-off comes the support window, in which the sender still answers questions and fixes defects in what was delivered. It needs a written end date, a scope and a first contact on each side. Running the operation and new work are out of scope.

At the end, review what was asked; each question is a last fix to the package. A window with no end means the sender is still the operator.

Handover, transition and commissioning: the terms, plainly

The words are used loosely, and loose use causes arguments about who is responsible. As this page uses them:

• Handover. Responsibility for a whole operation, program, facility or system passes to the team that will run it, with the package that makes that possible.
• Handoff. One piece of work passing from one person or shift to the next. In US usage the words overlap, and the difference that matters is size. A handoff can be checked by reading it. A handover has to be checked by running it.
• Transition. The whole move from project to steady running: preparation, overlap, handover and the support window. It is phase five of the five phases.
• Commissioning. Proving that a facility, line or system performs as designed and meets the owner's requirements, often including operator training and turnover documents. It proves the systems. Handover proves the team runs them. A line can pass commissioning and fail a live run.
• Activation, or go-live. The operation starts for real, in phase four. Handover follows it, as a separate event with separate evidence.

How handovers fail

• It is an event, not a test. A meeting and a signature, and the first real run comes after the builders have gone.
• The package describes the system, not the work. Specifications, and nothing on what to do the morning the report does not arrive.
• The receiving team joins at the end. They never helped define ready or corrected a draft, and people spot what is missing from a draft more reliably than they recall it.
• Access stays with the sender. It works until that person is not there.
• The date is fixed and the readiness is not. Sign-off follows the calendar instead of the test.
• The bad news is trimmed. The receiving team finds the open issues one at a time.

A handover document: headings you can copy

Use these as the contents. Each maps to rows of the checklist.

1. Scope: what is handed over, what is not, and the date responsibility passes
2. Readiness definition and pass standard
3. Owners
4. Procedures, with verified dates
5. Systems, data and access
6. Open issues
7. Contacts and escalations
8. Why it is built this way: decisions and incidents
9. Live-run test record
10. Sign-off and named exceptions
11. Support window: scope, contacts, end date

The document is for the team's first bad day, not for the file.

Common questions

What is a handover document?

The written part of the handover package: what the receiving team needs to run the operation without the people who built it. It covers owners, procedures, access, open issues, contacts and the reasons behind key decisions.

What is a handover checklist?

A list of what must be in the receiving team's hands before responsibility passes, with the evidence that each item is done, confirmed by the receiving side. Without evidence, it records what was sent, not what was received.

What is the handover process?

Seven steps: define ready, assemble the package, complete the checklist with evidence, run a real job with the sender silent, fix what it exposed, sign off with exceptions named, and keep a support window with a written end date.

What is the difference between handover and handoff?

The words overlap, and in US usage they are often interchangeable. Here, handover is responsibility for a whole operation passing to the team that will run it, and handoff is one piece of work passing between people or shifts. A handover has to be checked by running it.

At which phase does the handover to operations happen?

Last. In the five phases of operational readiness it is phase five, after the trial and go live. On a construction project it follows commissioning. It is planned from phase one, because ready has to be defined at the start.

← All writing