Project template
Project Handoff Checklist: What to Transfer Before Work Changes Hands
A practical handoff checklist for transferring work between teammates, teams, contractors or client owners.
Why handoffs fail in small teams
A handoff is incomplete when the next owner has to reconstruct the goal, status, decisions or deadline from old messages. A clear checklist gives the receiving person enough context to take the next step without guessing.
Use it when someone goes on leave, a client account changes hands, a contractor finishes, or work moves to another team. Keep the document beside the current project plan and link to the actual files and tasks.
Copyable project handoff checklist
Transfer the work
Project or deliverable: Purpose and expected result: Scope included / excluded: Outgoing owner: Receiving owner: Current status (done / in progress / blocked / not started): Next action / owner / due date: Important dates and dependencies: Current files and working links: Decisions already made: Open decisions and approvers: Risks or blockers / owner / review date: Access the receiver needs: Receiver confirms the goal, status, next action and deadline: Transfer date:
| Check | What the receiving owner needs |
|---|---|
| Purpose and scope | The expected result, what is included and what has been excluded. |
| Current state | What is complete, in progress, blocked or not started, with links to the work. |
| Next action | The next step, one accountable owner and its due date. |
| Decisions | Important decisions already made and decisions that still need an approver. |
| People and access | Stakeholders, approvers and the systems or files the receiver must be able to open. |
| Risks and dates | Potential delays, dependencies, promised dates and who will review each risk. |
| Acceptance | The new owner confirms they understand the goal, status, next step and deadline. |
A simple handoff example (fictional)
An agency moves a website refresh from one account coordinator to another. The outgoing coordinator shares the agreed scope, design link, client approval date, open copy edits, developer’s next task and final approver. The new coordinator checks access, confirms the Friday review date and acknowledges the next action. The details here are fictional.
Run the handoff in five steps
- Fill in the known facts before the transfer conversation.
- Review the outcome and scope before discussing small details.
- Separate completed work, open work, blockers and unresolved decisions.
- Confirm the next action, its owner and its due date.
- Ask the receiver to summarize the plan, then record acceptance and the transfer date.
What should not go into a handoff
Do not include passwords, private access tokens or personal data the receiver does not need. Use your organization’s approved access process. Avoid unexplained file dumps and vague notes such as “nearly finished” or “check the old chat.” Record missing context as a gap to resolve.
Frequently asked questions
Who owns a project after a handoff?
Name the receiving person as the new accountable owner. Contributors may share tasks, but one person should be responsible for moving the work forward.
When should a project handoff happen?
Use one whenever responsibility changes materially, such as leave, a role change, a contractor exit or a client-account reassignment.
How is a handoff different from a status update?
A status update shares progress. A handoff transfers the context and responsibility another person needs to continue.
Where should the checklist be stored?
Keep it beside the current project plan or source of truth so the receiving owner can find it later.
Keep ownership visible after the transfer
When work changes hands, connect the new owner and next due date to the project record. See Clarityy’s task management use case, operations workflow page and project management workspace. Check current plan limits before relying on a product-specific workflow.