7.1 Project Handover: From Delivered to Owned

7.1 Project Handover: From Delivered to Owned
Chapter 7.1 Part of 7.0 Project Closure

Deliverables Handover

Completion is when the work stops. Handover is when somebody else takes responsibility for what it produced. Projects that confuse the two end up quietly supporting their own deliverable for years.

New to this? This is the first of three sections in 7.0 Project Closure. It depends on the acceptance criteria written back in 3.1 Scope — if those don’t exist, this page is where you find out. Terms are defined at the bottom and in the glossary.

In short

  • Handover has two halves: the receiver accepts the deliverable, and the receiver accepts responsibility. Both need to happen.
  • The package is more than the thing: a runbook, access, known issues, decisions, and a person to ask.
  • A short named support window — typically 30 days — is what converts a delivery into a transfer.
  • Involve the receiving team before delivery. A handover first discussed at handover gets refused.

Completion is not handover

These are different events and they can be weeks apart:

EventWhat it meansWho decides
CompleteThe team has finished building and testingThe team
AcceptedIt meets what was agreedWhoever asked for it
Handed overSomebody else now owns running itThe receiving team, explicitly

The middle row is often skipped by assumption — we demoed it, nobody objected, so it must be fine. Silence is not acceptance. The third row is skipped far more often, and it is the expensive one: a deliverable with no operational owner stays with the people who built it, whatever the plan says.

What actually goes in the package

The six contents of a handover package and what each one's absence costs Six items. The thing itself working in production — always happens, and it is the only item that does. A short runbook — without it, every routine task becomes a support ticket. Access and credentials in the receiving team's names — without them, week one is spent chasing IT instead of learning. An honest known-issues list — without it they meet each issue alone in production. A record of who decided what and why — without it old decisions get reversed by accident. And a named person to ask for thirty days — without that they never really take ownership, and the build team remains support for years. An acceptance signature line closes the package. THE HANDOVER PACKAGE WHAT ITS ABSENCE COSTS THE RECEIVING TEAM The thing itself, working in production Always happens. It is the only item that does. How to run it — a short runbook Every routine task becomes a support ticket Access and credentials, in their names Week one is spent chasing IT, not learning The known-issues list, honestly They meet each one alone, in production Who decided what, and why Old decisions get reversed by accident A named person to ask, for 30 days They never really take ownership — and the build team is support for the next two years Accepted by  __________________   on  ____________ The last item is the one that is almost always missing, and the only one that costs nothing. A named person for thirty days is what turns a delivery into a transfer of responsibility.
None of the middle four items takes long to produce — but each has to be produced by someone who is about to be reassigned, which is why they need to be tasks with dates rather than good intentions.

The documentation that is actually worth writing

“Write documentation” is a task nobody knows how to finish, which is why it doesn’t get done. A more useful framing: write the answers to the questions the receiving team will ask in their first month.

  • How do I run the routine things? The weekly job, the monthly report, the thing that has to be restarted. Step by step, assuming no context.
  • What breaks, and what do I do? The three most likely failures and their fixes. This is worth more than a complete architecture document.
  • What’s deliberately odd? Every system has choices that look wrong until you know why. Write the why, or somebody will “fix” it.
  • Who do I call? For the vendor, for access, for the decision nobody documented.

Four short sections. A day of writing, and it removes most of the support load that would otherwise land on the build team indefinitely.

Making acceptance explicit

Acceptance needs three things: a named person, a stated basis, and a date. It does not need a ceremony.

The basis is the part people skip. “Do you accept this?” invites an unbounded review of everything anyone has ever wanted. “Here are the six acceptance criteria we agreed in March, here is each one demonstrated — do you accept?” is a five-minute conversation with a yes or no at the end.

If someone won’t sign, that is information rather than an obstacle. Usually one of three things: a criterion genuinely isn’t met (fix it), something outside the agreed scope is being asked for (that’s a change request, not a defect), or the person doesn’t feel able to take on running it — which is the real one, and no amount of demonstrating features will resolve it.

Bringing the receiving team in early

That third case is why the biggest lever in handover is timing rather than paperwork. A team asked to adopt something they had no part in shaping will find reasons not to, and most of the reasons will be legitimate.

What works, in rough order of value:

Name them at the start

Who will run this belongs in the charter, not in the last week. It costs one line during initiation and changes the entire ending.

Show them working software early

Their operational objections — monitoring, backups, access, the 3am case — are cheap to fix in month two and expensive in month six.

Let them do it while you watch

A handover session where the receiving team performs the routine tasks, with the build team present but silent, finds every gap in the runbook in an hour.

Agree the support window in writing

“Priya answers questions until 30 June, after that it’s yours”. Both sides need the end date — open-ended support is what everyone silently fears.

The administrative tail

Unglamorous, quick, and expensive when skipped: close the budget code, release licences and environments that are still being billed, transfer or terminate contracts, archive the artefacts somewhere findable, and remove access that shouldn’t persist. Half a day, and the cloud environment nobody switched off is a genre of story in its own right.

How this looks in AB

In AB Projects, the formal “deliverables handed over” signal is archiving the project. Members keep read access but lose write, so the project becomes a frozen reference rather than a deletion — which matters, because most of what a receiving team needs is the reasoning in the comments, not the deliverable.

Sign-off itself lives in a final task with a sign-off status, and the change-history tab on that task records when and by whom — replacing a manual approval log with something nobody has to maintain.

Two conventions worth adding by hand:

  • Make the handover package a task list, not a plan item. Six subtasks — runbook, access, known issues, decisions, support window, sign-off — each with an owner and a date. Otherwise they compete with delivery work and lose.
  • Put the support window end date in the project description. It is the single most useful fact about a finished project and the one most likely to be forgotten by both sides.

Terms used on this page

Handover
Transferring a finished deliverable, its documentation and its responsibility to whoever will operate it. Not the same as finishing it. More →
Sign-off
A named person’s explicit confirmation that a deliverable is accepted, against a stated basis. The moment “done” becomes a fact rather than an opinion. More →
Runbook
Written instructions for performing the routine operations of a system, assuming no prior context. The most reused document a project produces. More →
Warranty period
An agreed window after handover during which the delivering team still answers questions and fixes defects. Its value is that it has an end date. More →
Known issues
The list of defects and limitations shipped deliberately, with their workarounds. Honesty here costs a conversation; its absence costs trust. More →
Operations
The ongoing work of running what the project built. Where every successful deliverable ends up, whether or not anyone planned for it. More →

Related reading

7.3 Knowledge Transfer

Everything the receiving team needs that isn’t about running the deliverable day to day.

3.1 Defining Project Scope

Where acceptance criteria are written, which is what makes sign-off a five-minute conversation.

1.3 Projects vs Operations

What the deliverable becomes on the other side of this transfer, and why it needs an owner.

project handover deliverables handover sign-off acceptance runbook warranty period known issues operational owner documentation project closure
Published on: 2025-07-30 Last updated on: 2026-07-27

Questions & answers

Have a question about this topic? Ask below — no sign-up needed. The team reviews and answers questions here.

No questions yet — be the first to ask.

Ask a question

We’ll send a one-time email to confirm your address. Questions appear after a quick review.