How to Write a Handover Document: Work Completed, Actions and Ownership

A handover document is a transfer of responsibility. It should let the incoming owner understand what has been completed, what is still open, where the records are, how to operate the process or deliverable, and what they are accepting.

This guide uses a consulting scenario: a strategy review is complete, and the consulting team is handing the recommendations pack and outstanding implementation-planning actions to the client's internal project owner. The handover is not a legal release unless the contract says so. It is an operational record that reduces confusion after the project team steps back.

Define The Handover Scope

Start by saying what is being handed over and why.

This handover transfers responsibility for the customer onboarding strategy review from [consulting lead] to [client owner] effective [date]. It covers the final recommendations report, evidence log, open sponsor decisions and implementation-planning actions listed below. It does not transfer responsibility for work outside the approved project brief.

This paragraph prevents the handover from becoming a vague "everything is yours now" message. It names the scope and exclusions.

The California Project Management Framework describes closing activities as confirming custody of project products, deliverables and documentation, with deliverables acceptance based on success criteria defined earlier in the project (CA-PMF Closing). Your consulting handover should do the same: connect custody and acceptance to the criteria already agreed.

List Completed Work And Evidence

Completed work should be specific and tied to records.

Completed work

• Stakeholder interview plan completed: [number] interviews held between [dates]. Interview notes stored in [location].
• Current-state process map completed: version [x], dated [date].
• Recommendations report completed: version [x], dated [date], approved by [sponsor] on [date].
• Evidence log completed: version [x], with source references for findings F-01 to F-12.

Avoid "all discovery complete" unless you also say what that means. If something was not done, say so:

The project did not include implementation, software configuration, customer communication or legal review of customer terms.

The Federal Acquisition Institute's Project Manager's Guidebook emphasizes documenting risk information and using records such as risk registers to support management action (FAI Project Manager's Guidebook). A consulting handover should preserve the same trail: recommendations are easier to own when the supporting evidence and risk records are easy to find.

Record Outstanding Actions With Owners

Outstanding actions are the heart of a useful handover. They need owners, dates and context.

Write action notes in plain language:

Recommendation R-02 was supported by interview themes from sales and onboarding teams, but operations asked for a cost estimate before approval. The incoming owner should obtain that estimate before the sponsor decision meeting.

This gives the next owner the "why", not just the task.

Cover Access And Operating Instructions

If the handover includes documents, systems, trackers or routines, explain how to use them. Do not include passwords.

File locations

• Final report: [repository path or approved location]
• Evidence log: [location]
• Decision log: [location]
• Action tracker: [location]

Access
Access is managed by [system owner or team]. The incoming owner should request access through [approved process]. No passwords or shared credentials are included in this document.

Operating notes:

The action tracker is organized by recommendation number. Update the status column only after the owner confirms progress. Do not delete closed actions; mark them closed and keep the closure date.

This is especially important when the deliverable is a living file, not a static report.

Confirm Acceptance And Ownership

Acceptance wording should state exactly what the incoming owner is accepting.

Incoming owner acknowledgment. I confirm that I have received the documents listed in this handover, understand the outstanding actions assigned to me or my team, and know where to request access to the supporting records. This acknowledgment does not approve work outside the completed deliverables listed above.

Add outgoing owner acknowledgment:

Outgoing owner acknowledgment. I confirm that the handover reflects the current status of the project records known to me as of [date], including completed work, outstanding actions, risks and access notes.

The CA-PMF closing guidance ties deliverable acceptance to success criteria defined in earlier phases (CA-PMF Closing). Use that idea in the approval check:

• Are all deliverables listed with version and location?
• Are acceptance criteria from the project brief addressed?
• Are open actions assigned to post-handover owners?
• Are risks and limitations visible?
• Are access instructions secure?
• Is there a support period, if agreed?

Add A Support Period If Needed

Some handovers need short transition support.

For [number] business days after handover, [consulting lead] will answer clarification questions about the final report and evidence log. This support does not include new analysis, revised recommendations, implementation management or additional workshops unless approved as a separate change.

This protects the incoming owner and the outgoing team. It gives help without reopening the project.

Include Risks, Limits And Lessons

A handover that only lists completed work can create false confidence. Add a short section for known limits, active risks and lessons that will help the incoming owner.

Known limits

• Quantitative validation was limited because [data field] was incomplete for [period].
• The project did not test small-business onboarding.
• Recommendation R-04 depends on operations capacity that has not yet been approved.

Active risks

• Sponsor decision on R-02 may move beyond [date], delaying implementation planning.
• Action owner for the onboarding dashboard has not been confirmed.

Lessons for next phase

• Schedule data-owner review before executive review.
• Keep implementation recommendations separate from evidence findings so decisions can be approved one by one.

This section is not for blame. It is for continuity. The incoming owner needs to know where the project is strong and where judgment is still required.

If the handover follows a client-facing engagement, give the client a chance to correct factual errors before final acknowledgment. A simple route works:

Draft handover issued on [date]. Corrections due by [date]. Final handover issued on [date]. Acceptance or conditional acceptance recorded below.

Conditional acceptance is often more honest than forcing a yes or no:

Accepted subject to: access approval for [repository], sponsor decision on R-02 and confirmation of action owner for dashboard planning.

That wording lets ownership transfer while keeping unresolved items visible.

Store the accepted handover with the final project records.

Start From An Editable Structure

The consulting handover document template is an editable Word file with sections for scope and current position, completed work, outstanding actions, access and operating instructions, acceptance and ownership. It is a starting structure for transferring responsibility, not a guarantee that a project is legally closed or contractually accepted.