Project Handover Checklist: What to Include

What should a project handover checklist contain?

A project handover checklist should contain the current state of the work, where every artefact lives, who can access what, what is still open, and how the receiver gets help after the outgoing owner leaves. The test is simple: could a competent colleague take over next Monday using only what is written down?

Most thin handovers fail for the same reason. They document the things (files, systems, tasks) and skip the judgement (why the architecture looks odd, which client call must not slip, which vendor is quietly unreliable). The list below is built to capture both, and it is deliberately boring — boring checklists get completed.

A useful framing: you are not transferring information, you are transferring the ability to make decisions.

The 40-item project handover checklist

The table is designed to be copied into a spreadsheet or a task board. Each row has a named owner and an evidence column, because “yes, shared” is not evidence. Add a link, a file path, or a date instead.

Two rows get skipped most often. Row 19, the decision log, stops the new owner from reversing an expensive decision. Row 23, informal commitments, is where reputational damage hides: the account manager promised a client a discount in a call that exists nowhere but in memory.

How long does a project handover take?

Plan four to six weeks for a role with meaningful system access, and two to three weeks for a narrow, well-documented workstream. The number depends less on the size of the project than on how much of it lives in one person’s head.

A realistic six-week pattern:

• Week 1: nominate the receiver, open the checklist, run a 90-minute kickoff covering scope and the top five risks.
• Weeks 2–3: documentation sprint. The outgoing owner fills the gaps in the checklist while the receiver sits in on real meetings.
• Weeks 4–5: reverse shadowing. The receiver performs the work — deploy, client call, invoice approval — while the outgoing owner watches and corrects.
• Week 6: sign-off, plus a 30-day check-in booked before the last day.

The reverse shadowing week is the one teams cut when the schedule slips, and it is the one that produces most of the transfer. Watching someone do the job is passive. Doing it while someone corrects you is where the tacit knowledge moves.

The cost of the overlap, in numbers

Assume a departing operations lead on a loaded cost of $520 per working day, and a receiver on $430. A four-week overlap (20 working days) costs 20 × $520 + 20 × $430 = $19,000 in duplicated labour. That sounds expensive until you compare it with the alternative: a two-day handover and a three-week discovery period after the exit, during which the receiver is paid $9,030 to reverse-engineer a system while the rest of the team waits on answers.

A middle path that many teams use: two weeks of full overlap, then one month of paid availability at four hours per week. For the same role, that is 10 × $950 = $9,500 plus 16 hours at the departing rate ($1,664), roughly $11,164 — about 40% cheaper than full overlap, and it keeps a safety net during the first monthly close.

How do you know the handover is finished?

You know it is finished when the checklist score is above the agreed threshold and the receiver has completed at least one full cycle of the recurring work unaided. Counting documents is not enough; the proof is a closed month-end, a deployed release, or a client review run by the new owner.

Weighting makes the score honest. Split the 40 items into three tiers and give each tier a different value:

Now suppose the review finds 11 of 14 critical items done, 15 of 20 standard items done, and 2 of 6 improvement items done. The score is (11 × 5) + (15 × 2) + (2 × 1) = 87 out of 116, or 75%. That is a failing handover even though 28 of 40 boxes are ticked, because three critical items are missing — most likely credentials, warranty terms, or the escalation path.

A workable rule: no sign-off below 100% of critical items and 85% of the total. Everything else becomes a dated action with a named owner, reviewed at the 30-day check-in. That prevents both failure modes — a false “complete” that hides gaps, and an endless perfectionism that keeps the outgoing person on the payroll for months.

What changes when the handover is vendor-to-client?

Nothing in the first 40 items disappears, but four obligations become contractual rather than courteous: proof of acceptance, warranty terms, an asset register, and credential rotation. In an internal move, a missed item is an inconvenience. In a vendor handover, it is a commercial dispute.

The handover package for a vendor engagement should include:

• Acceptance evidence. Signed test results, UAT logs, and the punch list with dates. Without it, the client cannot prove the deliverable met the specification, and the vendor cannot prove it was accepted.
• Asset register. Every licence, subscription, domain, SSL certificate, and cloud resource, with the legal owner named. Accounts registered to a vendor email address are the most common post-handover emergency.
• Warranty and support terms. Start and end dates, response times, what voids the warranty, and who to call. Put the escalation matrix in the same document.
• Credential rotation plan. Shared passwords from the build phase must be rotated at handover, and the rotation must be logged. The vendor’s engineers should lose access on a specific date, not “soon”.
• Source and build reproducibility. Repository access, build scripts, environment variables, and a tested restore from backup.
• Exit assistance clause. Days of support included after go-live, and the rate for additional days.

Write the acceptance window into the contract — for example, 10 business days to raise defects in writing after delivery, after which the package is deemed accepted. That clause removes most of the ambiguity that turns a handover into a three-month argument.

How do you run handover sessions so knowledge actually sticks?

Run fewer, longer sessions with a task attached, and require the receiver to produce something at the end. A recorded walkthrough that nobody rewatches is documentation theatre.

Three formats work reliably:

1. Teach-back. The outgoing owner explains a process for 20 minutes, then the receiver explains it back and performs it once. Gaps show up immediately and get written into the checklist.
2. Paired execution. Both people do the real task together — the monthly invoice run, the release deploy — with the receiver driving from the second attempt onward.
3. Recorded walkthroughs, scripted. Ten to fifteen minutes each, one topic per recording, named by topic and date, with the corresponding checklist row linked. Anything over 30 minutes will not be watched.

Keep a session log with date, topic, attendees, and the checklist rows covered. When someone asks in March why a process works this way, the log points to a recording instead of a rumour.

> Practical tip: Ask the outgoing owner to list the five questions they are asked most often. Those five become the first five walkthrough recordings — the cheapest capture of knowledge that is actually in demand.

What are the most common handover mistakes?

• Starting in the final week. The last week is for sign-off and goodbyes. Documentation written under that pressure is a list of links, not a transfer.
• Treating the document as the deliverable. The document is evidence. The deliverable is a receiver who can operate without help.
• No receiver named until late. Without a named receiver, nobody tests whether the documentation is usable, and access checks never happen.
• Access granted but never tested. A shared vault folder that the receiver cannot open is worse than no folder, because it creates false confidence.
• Skipping the decision log. The new owner reopens settled questions, the team relitigates, and momentum dies.
• Forgetting the calendar. Recurring obligations — board reports, vendor invoices, certificate renewals — are invisible until one is missed.
• No close-out for the outgoing accounts. Orphaned admin accounts are a security finding waiting for an audit.
• No 30-day check-in. The first month surfaces the gaps; without a scheduled review, those gaps become permanent workarounds.

When is a formal handover checklist overkill?

For a two-week side task with no system access and no external contact, a 40-item checklist is bureaucracy. Scale the list: pick the 12 items that would actually hurt if lost, and move on.

The checklist also struggles in two other situations. First, when the outgoing person has already checked out emotionally — in that case the manager must own the documentation sprint, not the leaver. Second, when the receiving team has no capacity to absorb the work — a perfect handover to an already-overloaded team simply relocates the failure. Check capacity before you check documentation.

Finally, if the same role has been handed over three times in two years, the problem is role design, not handover quality: critical knowledge sits in one position with no incentive to document it continuously. Pair ownership, review documentation quarterly, and the next handover becomes a formality instead of a rescue.

How do you track a handover without a spreadsheet sprawl?

A handover is a project with a deadline, a small team, and 40 deliverables. Treat it like one. Create a dedicated space, one task per checklist row, an owner per row, and a due date measured backwards from the exit date. Attach the evidence to the task instead of keeping it in a folder nobody can find.

That is what Doitify is built for: multi-level tasks and sub-tasks, checklists, owners and due dates, documents attached to the work, plus reports that show completion by owner. A handover board with 40 rows and a readiness percentage takes an afternoon to set up and gives the manager a defensible answer when HR asks whether the transition is on track. It is not the only way to do this — a well-structured spreadsheet works for a single small handover — but the advantage of keeping evidence next to the task is that sign-off becomes a review, not an archaeology project.

*Transparency note: Doitify is our own product. We use it for exactly this kind of short, deadline-driven project, and we have kept the checklist above tool-agnostic so you can run it anywhere.*

Conclusion

A project handover checklist is a contract between the person leaving and the person staying. Its value is not the document — it is the argument it forces about what “transferred” actually means, while there is still time to fix the gaps.

Copy the 40 items, weight them, and set the sign-off rule before the handover starts: 100% of critical items, 85% overall, one full work cycle completed by the receiver. Then book the 30-day check-in. Teams that do those three things spend the first month of a transition answering questions about the future instead of reconstructing the past.

If this post on project handover checklist was helpful, you might also enjoy Project Assumptions vs Constraints: What’s the Difference? (2026) and SEO Project Management Template.