focus&leapIndependent thinking.
Useful action.

Tools / Field notes

Write a project handoff someone can actually use

Give the next person the context, current files, open decisions and first action they need to continue confidently.

A handoff fails when the recipient receives a folder but cannot tell what is current, what has been decided or what they are expected to do. More documentation does not automatically solve this. A useful handoff gives someone an understandable starting point and access to the evidence behind it.

Start with the current state

Open with a short description of the project’s purpose and what is true now. Distinguish work that is drafted, approved, delivered or live. These states have different implications. An uploaded file may still need review; an approved design may not yet exist in the public product.

Use specific language: “The homepage copy is approved; the mobile layout is awaiting review; the public site still shows the previous version.” That sentence is easier to act on than “Website almost done.” Include the date so that the recipient can recognise whether the description may have become stale.

Provide a compact index of the current brief, working files, approved outputs and relevant decisions. Label each link by its purpose. Check that the recipient has the intended access before considering the handoff complete. Do not solve an access problem by making private material public.

Avoid attaching several similar versions without explanation. If older material matters, put it in a clearly marked archive and state why it remains relevant. Preserve important history without making the next person guess which file governs the work. A simple table of document, owner and status can be enough.

Explain the decisions that constrain the next step

Record choices that a new person might otherwise reopen: the audience, excluded features, agreed tone, approval owner or technical limitation. Add the reason when it affects future decisions. “We use this format because the client edits it weekly” is more informative than “Use this format.”

Keep the explanation proportionate. The recipient does not need every conversation that preceded the decision. They need the constraint, its source and a way to ask about unresolved questions. Separate confirmed requirements from your own recommendations so that a suggestion does not quietly become a rule.

Name the open work

List remaining actions with an owner, a relevant date and any dependency. Mark assumptions that still need verification. “Check the final link after publication” is different from “Link checked.” Clear state prevents an unfinished validation from being inherited as a completed fact.

For a small project, three sections may be enough: ready to use, waiting for a decision and next action. If the project is larger, group by workstream. Do not make the structure so detailed that maintaining it becomes a separate project. The recipient should be able to find the immediate next move quickly.

Make the first action unambiguous

End with a concrete starting instruction: “Review the three marked paragraphs, then send changes to the copy owner before Wednesday.” Include what should happen if the action fails or the needed person is unavailable. This is especially useful across time zones, when a vague handoff can cost an entire working day.

Invite the recipient to explain the next step back in their own words if the stakes or complexity justify it. Their questions reveal missing context better than asking whether everything is clear. A handoff is successful when the work can continue, not when the sender has sent a message.

Save the handoff alongside the project index and update it if the state changes before the recipient starts. The weekly review is a useful moment to identify projects that need a refreshed handoff rather than another status meeting.

Include one example of done

Show what a completed next step would look like. A reviewer might need to leave comments in a specific document; a publisher might need to confirm the public URL; a designer might need to save an editable source alongside the export. Naming this expected evidence prevents two people from using the same word for different states.

If you include a checklist, make each item observable. “Check quality” is hard to transfer. “Confirm the approved headline appears on the public page” is easier to verify. Use only the detail needed for the actual handoff, and let the recipient ask for more context where the work requires judgement.