Project Handoff Template: Decisions, Exceptions, and Open Questions

A project handoff is complete when the next owner can continue the work, not merely when they receive the files. They need to know what happens next, which decisions still apply, and which customer conditions could change an otherwise reasonable action.

Use the template below when responsibility for an active project moves to another person. Fill it from current work records and the discussions that explain important choices. Hemory can help recover that spoken background, so preparing the handoff does not depend on retelling every meeting from memory.

Copy the project handoff template

Project:
Outgoing owner / incoming owner:
Responsibility transfers on:
Status checked on:

Current work
Deliverable / current status / next action / owner / agreed timing:

Decisions to preserve
Decision / reason / applicable scope:

Client exceptions
Requirement / who or what it applies to / why it matters:

Dependencies
What must happen first / who supplies it / effect on the next action:

Open questions
Question / person who can answer or decide / work affected:

Next checkpoint
When to review / what should be known by then:

Supporting context
Current working files / accessible explanation / relevant source dates:

Acceptance
Incoming owner has reviewed access, responsibilities, and open points:

Use a row per item where the project needs more than one. Leave unknown dates or owners marked for confirmation instead of filling them with guesses. If a section does not affect the transfer, omit it.

This template is for a change of ownership. For a colleague covering a short absence, the client account coverage guide provides a narrower brief.

A completed handoff example

Suppose a customer workshop is moving from one coordinator to another. In this fictional scenario, the team has agreed that Lena takes over from Sam on June 10. The current plan confirms a June 24 workshop, an approved agenda, and a confirmed venue. The customer discussion explains that exercises must use printed worksheets because participants cannot bring laptops onto the training floor. A separate evening session was suggested but has not been approved.

The customer’s latest email says the final attendee count will arrive June 12. Lena has agreed to prepare the print order after that count arrives and to review readiness with the training lead on June 13. These transfer arrangements are explicit inputs, not responsibilities inferred from an earlier conversation.

Project: Northstar customer workshop
Outgoing owner / incoming owner: Sam / Lena
Responsibility transfers on: June 10
Status checked on: June 9

Current work
Workshop scheduled for June 24. Agenda approved; venue confirmed.
Print order not placed. Lena will prepare it after the final attendee count.

Decisions to preserve
Use printed worksheets for the workshop exercises.
Reason: participants cannot bring laptops onto the training floor.
Scope: this workshop and its on-floor exercises.

Client exceptions
Do not replace the worksheets with a laptop-based exercise without
checking the customer's device restriction and agreeing any change.

Dependencies
Customer to provide the final attendee count on June 12, as stated in
the latest email. The print quantity depends on that count.

Open questions
An evening session was suggested but is not approved.
Lena will ask the training lead what decision is needed before changing
the agenda or making any additional booking.

Next checkpoint
June 13 readiness review with the training lead: confirm the attendee
count, print-order status, and whether the evening-session proposal
requires further work.

Supporting context
Approved agenda, venue confirmation, and customer attendee email in
the shared project folder. Device restriction explained in this brief,
with a permitted source excerpt from the planning discussion.

Acceptance
Pending Lena's check of folder access and the open evening-session item.

The next owner can prepare the print order and preserve the customer’s constraint. The unapproved evening session remains visible without becoming an extra booking someone assumes they must make.

Fill the fields that prevent a stalled handoff

Current work should describe what exists now. “Agenda discussed” and “agenda approved” are different states. Check the current document or approval record before calling a deliverable complete.

Decisions and exceptions carry the reason that a task title may omit. In the example, the device restriction is essential: it explains why switching to an online exercise would affect the customer’s ability to participate.

Dependencies and open questions show where the new owner can act and where another answer is needed. An attendee count promised for June 12 is not proof it has arrived. An idea for an evening session is not permission to book it.

Acceptance makes the transfer explicit. Sending a document does not establish that the new owner can access its files or understands the responsibilities. Use the team’s normal handoff process to resolve these points.

For a deeper explanation of how to select historical decisions for a newcomer, see briefing a new teammate on past project decisions. This template carries the information needed to take over active work.

Draft the background from Hemory discussions

You may know the current task status but have forgotten why the workshop format changed. If the planning discussion was captured in Hemory, locate it and use conversation Q&A to retrieve that reason:

Why did we choose printed worksheets, and what did we agree about an evening session?

For a handoff drawing on several discussions, give an AI agent connected to Hemory the template, the transfer details, and current records it cannot otherwise access:

Draft a project handoff for Lena taking over the Northstar workshop.
Use the handoff template, current project records, and confirmed transfer
arrangements I provide, together with the available Hemory discussions.

Explain decisions and client exceptions that affect the next actions.
Keep proposals separate from approved work. Preserve dependencies and
stated timing. Do not assign ownership or approval authority unless the
provided information establishes it.

Flag missing current status and access details. Include source references
in the working draft where available. Keep the main brief understandable
without opening my personal conversation history.

The agent helps prepare the draft; the project owners confirm the transfer. Hemory supplies available captured context, not automatic access to every project file or a shared team archive.

Review the handoff around the next action

Walk through what the incoming owner will do first. For the workshop, can Lena locate the approved agenda, tell when the print quantity can be set, and identify what remains undecided about the evening session?

Fix the missing explanation or access issue that prevents that action. Keep the brief in the project workspace, with necessary context included for anyone who cannot open the original source. After ownership transfers, maintain current status in the normal project record rather than keeping two competing versions.

FAQ

Is this the same as a project status update?

A status update reports progress. A handoff also transfers responsibility and explains the decisions, exceptions, and open points the next owner needs to continue the work.

Should every historical decision be included?

Include decisions that constrain or explain upcoming work. Put optional background in accessible references rather than making the recipient read a full chronology.

What if the outgoing owner remembers a reason that was never recorded?

Include it as a later clarification and confirm consequential details where needed. Do not present reconstructed wording as a direct quote from the original discussion.

Use the template for your next transfer of project ownership. Let Hemory help recover the reasons behind the work, then give the incoming owner a brief they can use to begin.