undefined logo

What a Real Project Handoff Actually Covers

Four layers most handoff docs miss — receivers find out in week one

McKinsey put high-skill knowledge workers at nearly 20% of the workweek hunting context — about 9.5 hours. Most of it for context that lives in someone else's head. Handoffs concentrate the loss — the new owner does weeks of that hunting in days.

AV
Adrienne Vance
4 min read·May 27, 2026
What a Real Project Handoff Actually Covers

By Tuesday of week one, the receiver knows the four layers the handoff doc didn't cover.

What the handoff doc covers — and what the receiver finds the hard way

The typical handoff doc carries five things: scope summary, deliverables list, asset links, stakeholder list, status snapshot. All useful. None of them tell the receiver what to do on day three when the client's COO escalates a deliverable nobody on the team flagged.

The McKinsey Social Economy report estimated knowledge workers spend nearly 20% of the workweek — about 9.5 hours — searching for and gathering information. Handoffs concentrate that loss. The new owner compresses weeks of context-hunting into days.

The typical doc — scope, deliverables, status — useful and incomplete

A standard handoff template walks the reader through what's there — pages shipped, Figma files, the kickoff deck, status as of Friday, the list of who's on the account. The template does what it asks for. It just doesn't ask the right question.

The receiver's week one — every ping is a missing layer

The pings tell the story. The receiver Slacks the outgoing owner six times in week one — each ping is about a decision rationale the doc didn't capture, a parked thread that resurfaced, a stakeholder quirk that "everyone knew," or a cadence rule that broke when the new owner missed it. Delivery leads who've tested this on their next handoff usually rewrite their doc structure before the next account changes hands.

The four layers a real handoff actually covers

A real handoff stacks four layers above the standard template. Decisions plus rationale — not "we chose Webflow," but "we chose Webflow over Framer because the client's CMS hire dropped out; revisit if a dev joins." Abandoned threads — the discovery email the client never returned, the partner SOW that fell through in week 2, the design direction the founder vetoed. Stakeholder etiquette — who needs warning before a slip, who escalates fast, who's the real decision-maker behind the named one. Recurring patterns — status goes Tuesday before 11am or the client preempts on Slack; design review needs a 48-hour buffer or rounds compress.

High-skill knowledge workers spend nearly 20% of the workweek looking for internal information or tracking down colleagues. — McKinsey Global Institute, The Social Economy (2012)

Each layer lives in tacit knowledge — Slack threads, DMs, meeting recordings, the project lead's head. Never in any artifact the receiver inherits with the handoff doc.

Decisions + rationale, and the abandoned threads no one wrote down

The outcome of a decision is easy to capture. The reasoning is harder. The conditions for revisiting it are harder still. And the threads that started and stopped — the partner deal that fell through, the experiment that didn't ship, the design direction the founder vetoed in week 3 — are invisible to anyone reading the final status. The receiver needs both, especially when one of those threads resurfaces.

Stakeholder etiquette and the recurring patterns that govern this project

Lara wants Friday updates, not Tuesday. The founder's "yes" in the meeting becomes a "no" in Maya's followup email. Real decisions go through the CTO, not the named PM. These aren't policies. They're the operating system the project lead built and never wrote down. Same with the cadence rules. Tacit knowledge, formalized.

Why handoffs miss the layer — and what surfacing it changes

The team that did the work has zero time in week 50 to extract the why behind every decision, the etiquette around every stakeholder, the meta-rule behind every cadence. The template they use doesn't ask. So the receiver inherits a doc that documents the work and leaves them to reconstruct the project.

The team rewarded for shipping never has time to surface the why

Delivery teams are paid to deliver. Knowledge surfacing is a separate job, and no one's owned it. The McKinsey number is the steady-state cost; handoff is the spike — and it falls on the receiver, not the outgoing owner, so it doesn't show up on the outgoing team's metrics.

What the 4-layer handoff looks like when assembled in one model run

The output: a 4-section handoff, roughly three pages, drafted from the scattered inputs the outgoing lead already has. Decisions + rationale, with [RATIONALE NEEDED] flags where the inputs are silent. Abandoned threads, with the resurfacing risk noted. Stakeholder etiquette, with [ETIQUETTE NEEDED] flags where signal is thin. Recurring patterns. Plus a list of the gaps the outgoing owner can fill in one async session. Three afternoons compress into one model run and a 30-minute follow-up.

Handoff quality is what your template reveals about your work

The handoff template your org uses reveals what your org thinks the work is. If the template only asks for deliverables, deliverables are what the org values — and the project's unwritten operating system stays invisible to the people paid to run it. The four-layer model isn't a docs problem to fix with a better template. It's a knowledge-surfacing problem the org never had time for. Running it once tends to change what your next kickoff doc looks like, not just your handoff.