A project handoff checklist for notes, files and next steps

A handoff is complete when the receiving person can continue the work. Sending a folder or a long summary is only one part of that transfer. The recipient also needs to understand the current state, the next decision, the source of truth and the limits of their access.

This checklist applies to a small business process, an event, a creative project or an internal task changing owners. It focuses on practical continuity. It does not replace a contract, a legal retention requirement or an organization-specific approval process.

State the handoff outcome

Begin with one sentence explaining what the recipient is taking over. Name the scope and the point at which their responsibility begins. “Take over venue coordination after the room is selected” is clearer than “Help with the event”.

List what remains with the original owner. A recipient can act more confidently when boundaries are explicit. If they may gather quotes but cannot approve a payment, record that distinction.

Include a date for the transfer and an agreed review point. A handoff spread across several messages can leave both people assuming the other is responsible. A clear transfer moment reduces that ambiguity.

Summarize the current state

Write what has been completed, what is in progress and what has not started. Include the latest relevant decision and the version of any material that was approved. Avoid describing a published draft as approved unless the approval was actually recorded.

Separate facts from assumptions. “The venue replied that Friday is available” is a fact you can link to. “We expect around 20 attendees” is an assumption until confirmed. The receiving person needs to know which statements can support a decision.

A practical status summary might say:

Venue options are collected. No booking has been made. The preferred room is available subject to confirmation. Participant numbers are still estimated. The next action is to confirm attendance before reviewing the deposit conditions.

This summary gives the recipient a sequence, rather than a pile of background.

Identify the source of truth for each item

A handoff often combines notes, file links and discussion history. Explain where the authoritative material lives. Draftnod can hold the note, published versions and the review record; a linked document or design file remains in its original service.

For each important link, say what it contains and whether it is a working file or a reference copy. A generic folder link forces the recipient to search. A named file plus its purpose gives them a usable starting point.

The links and images guide explains the permission boundary between a shared note and an external asset. Check that the recipient can access the source service before treating the handoff as ready.

Write next steps in dependency order

List the first few actions in the order they can actually be completed. If an action depends on a decision, put the decision first. If approval is needed before an external commitment, state that explicitly.

Give each step a completion signal. “Review the draft” is vague; “Check the dates and return a list of corrections on version 2” is observable. Include a deadline where there is a real deadline, rather than creating urgency to make the list look organized.

Do not overload the handoff with every future possibility. The recipient needs enough context to begin, and a clear location for deeper background. Link to a focused note when a later step is complicated.

Record risks and unresolved questions

Risks are useful when they describe a specific condition and its consequence. “The quote expires on Thursday; after that the room price may change” guides action. “Timing risk” does not.

For unresolved questions, name the person or source that can answer them. If nobody has that information, state that investigation is required. Do not hide uncertainty behind confident language.

Keep sensitive information out of a general handoff project unless it is appropriate for every recipient with access. A PIN is not a substitute for deciding which information should be shared. Read the PIN safety checklist before distributing access details.

Publish the handoff and request a read-back

Save the note privately first, review it, then publish the version you want the recipient to use. Send the project-specific link and PIN privately. Identify the handoff task by name so the recipient does not need to guess where to begin.

Ask the recipient to summarize their first step and any missing access. This read-back is more useful than a simple “received”. It reveals whether the note communicates the same plan you intended.

When corrections are required, publish a new version and explain the difference. The version history guide covers how to preserve earlier context while making the current revision clear.

A practical handoff checklist

• Scope: what responsibility is transferring, and what remains elsewhere?
• Status: what is complete, pending and blocked?
• Decisions: which version or outcome has actually been approved?
• Sources: where are the notes, working files and reference copies?
• Access: can the recipient open the project and every linked asset?
• Next steps: what should happen first, and what counts as done?
• Risks: which conditions could change the plan?
• Confirmation: has the recipient explained the next action back?

For readable checklists and headings, see W3C's guidance on accessible writing. Use the guidance to make the handoff easier to scan, while adapting the content to your actual organization.

Follow up on the first outcome

Schedule the first check around a concrete result, such as a confirmed venue answer or a reviewed draft. Ask what remains unclear and update the shared record. This closes the gap between receiving information and using it.

The onboarding notes guide expands this pattern for someone joining a process for the first time. Open a workspace and test your handoff with one low-risk project before making it the standard for more complex work.