Structuring projects so handoffs don't lose context

The expensive part of a handoff isn't the work in progress. Files transfer fine. What gets lost is the reasoning — why the client rejected the second concept, why you're not using their brand blue on the landing page, which stakeholder has to be copied on anything involving pricing.

The new person doesn't know any of it, and worse, doesn't know they don't know. So they redo a rejected direction, or say something to the wrong stakeholder, and the client concludes the agency isn't listening. That perception costs far more than the fortnight of ramp-up.

Handoffs are unavoidable — people leave, go on holiday, get pulled onto a pitch, move up. The goal isn't fewer handoffs. It's projects structured so a handoff costs days instead of weeks.

The thing that actually gets lost

Sort project knowledge into three buckets and it becomes obvious where the risk is.

Type	Example	Where it lives	Survives a handoff?
Artefacts	Files, drafts, exports	Shared drive or portal	Yes
Facts	Deadlines, budget, contacts	Contract, brief, calendar	Mostly
Decisions	Why we chose this, what was ruled out, who to avoid	One person's head	No

Artefacts are a solved problem. Facts are usually recoverable with an hour of reading. Decisions are the entire problem, and almost no agency writes them down anywhere durable, because at the moment a decision is made it feels obvious and unforgettable.

Keep a decision log

One document per project. Append-only. Every entry is one or two lines.

2026-06-14  Client rejected concept B (the illustrated route).
            Reason: too close to a competitor's rebrand last year.
            Do not revisit. Concept A approved for development.

2026-06-21  Agreed to use their existing photography rather than
            commissioning a shoot. Saves ~$8k of their budget.
            Trade-off accepted: image quality is inconsistent on
            the interior shots.

2026-07-02  Anything involving pricing goes to Marcus (CFO) before
            it goes to Dana. Dana asked for this directly.

2026-07-09  Scope: added the two extra language variants.
            Change request CR-02, +18 hours, signed.

Four entries, thirty seconds each to write, and between them they'd save a new person a week of finding out the hard way.

Rules that keep it alive: one file, not a folder. Newest at the top. Written the day the decision happens, not reconstructed later. And it includes the rejected options — a log that only records what you chose is half a log, because the most expensive handoff mistake is re-proposing something already killed.

Name the stakeholder map

Every client has a real decision structure that differs from the org chart. Who signs off. Who has veto power that isn't formal. Who needs to feel consulted. Who will derail a project if surprised.

The person who's been on the account for four months knows all of this and has never articulated it. Write it into the project record as plainly as you'd say it out loud:

Dana — Marketing Director — day-to-day contact, approves creative,
       fast to respond, prefers a call over a long email.
Marcus — CFO — approves anything over $5k, sees invoices, has
       killed two initiatives late. Loop in early on cost.
Priya — Brand — no formal sign-off, but if she objects publicly
       Dana will fold. Show her work before the wider review.

Three lines. Impossible to reconstruct from an email archive.

Four structural habits

Write briefs so a stranger could act on them. The test isn't whether the brief is complete; it's whether someone who wasn't on the kickoff call could start work from it. If a brief only makes sense to people who were in the room, the project is one absence away from trouble.

Keep client communication in shared channels. A project run through one person's inbox and DMs is a project with a single point of failure. Shared threads, shared project channels, deliverables in a shared location. Not because DMs are bad — because the history has to be somewhere other than one account.

Never let one person be the only one who has spoken to the client. Have a second person on the call occasionally, even silently. It costs an hour a month and it means the handoff starts from familiarity rather than from zero.

Record why, not just what, in your project notes. "Changed the layout" is useless in three months. "Changed the layout because their legal team requires the disclaimer above the fold" is permanent.

The handoff document

When a handoff actually happens, one page, written by the person leaving, with a live conversation on top of it. Not instead of it — the document is the record, the conversation is where the awkward parts come out.

HANDOFF — [PROJECT] — [from] to [to] — [date]

WHERE IT STANDS
[Two sentences. What's done, what's in flight, what's next.]

BUDGET AND DATES
[X of Y hours used. Next hard date and what it is.
 Any date already at risk.]

THE CLIENT
[Stakeholder map. Who approves what. Any sensitivities.]

DECISIONS THAT MATTER
[Top five from the decision log. Especially rejected directions.]

IN FLIGHT RIGHT NOW
[Anything mid-conversation, unanswered, or promised verbally
 and not yet written down. This block is the one that saves you.]

WHAT I'D WORRY ABOUT
[The honest paragraph. What's fragile, who's unhappy, what you'd
 be watching if you were staying.]

WHERE EVERYTHING IS
[Links. Files, log, threads, credentials.]

The last two blocks are the ones people skip and the ones that matter most. "Promised verbally and not yet written down" is where handoff disasters live — someone said "we'll take a look at that" on a call in week four, the client counted it as a commitment, and it exists nowhere.

Handoffs to the client

The same logic applies at the end of a project, when you hand the work over for the client to run themselves. What they need isn't a folder of files; it's the reasoning that makes the files usable — why the template is built the way it is, what to do when the thing you didn't cover comes up, who to call.

A closing document that includes the decision log, in plain language, is one of the cheapest ways to be remembered well. It also tends to generate the follow-on work, because a client who understands what they have is a client who knows what they're missing.

Do this week

Pick your most at-risk project — the one where a single person holds everything — and start a decision log for it. Backfill it from memory in twenty minutes, then append to it as things happen.

Backfilling is uncomfortable, because you'll find decisions you can no longer fully explain. Those are exactly the ones a new person would have got wrong, and right now you still have the person who can reconstruct them. In six weeks you might not.