# Free project handover checklist template

> A practical project handover checklist in nine sections, with a filled supplier example and steps for checking actions, access and ownership.

Source: https://plexiidesk.com/blog/free-project-handover-checklist-template
Topic: Clients and teams (https://plexiidesk.com/blog/c/clients-and-teams)
Author: The Plexii team
Published: 2026-11-08

A handover is finished when the person taking over can do the next piece of work without you. A document full of background is not enough if they cannot open the files, do not know who can approve a change, or discover the first deadline after it has passed.

This free project handover checklist gives you nine sections to work through together. Every row is set out below, so you can copy the checklist into Excel, Google Sheets or the system you already use, or start from the ready-made [handover desk template](https://plexiidesk.com/templates/handover) in Plexii. No account is needed to use the checklist.

If you want the note beside the work it describes, [download Plexii free](https://plexiidesk.com/download). It runs on Mac and Windows and is free forever for personal use. You can also use this checklist without changing your existing tools.

## How the checklist is laid out

Set it up as one table. Each checklist row has a section, an item to complete, an owner role, a due date, a status, and space for notes or evidence.

Replace owner roles with actual people in your private working copy. Use **Not started**, **Waiting**, **Ready** or **Not applicable** consistently. Ready means the receiver can use that part of the handover, not merely that someone has written a paragraph about it.

The example follows a fictional supplier-onboarding project. Two suppliers have been approved; a third is waiting on an insurance review. That modest scenario is useful because it includes a real dependency, a decision maker and a date when somebody must act.

## 1. State the position and the finish line

In **Status**, write where the work stands and what finished means. Keep those separate. describes neither.

The example says: The next owner now knows that collecting documents is not the finish line. Approval and ordering access are still required.

Add an as-at date if the position changes quickly. If there are ten suppliers, link to the current register rather than pasting ten changing statuses into the handover. The checklist should identify the authoritative record, not create a competing one.

Before moving on, ask the receiver to describe the finish line back to you. If you disagree, settle it now. An argument about what meant is much harder after the original owner has left.

## 2. Record decisions that should not be reopened

In **Decisions**, include the decision, its reason and a rejected option where that would save someone time. Do not write a history of every meeting.

For the supplier project: use the existing approval portal because it preserves the approval record; emailed forms were ruled out because they would create a second process without the same trail. This explains both what to do and why the apparently easier alternative was not chosen.

Link to approval evidence when it matters. is less useful than a dated decision record the receiver can open. Separate decisions already made from recommendations still waiting for approval.

You do not need to defend every preference. Prioritise choices that constrain the next person's work: scope, supplier, budget, acceptance criteria and promises made to others.

## 3. Turn open questions into named dependencies

The **Open questions** row should say what is unknown, who can answer and what happens if the answer does not arrive. A list of question marks simply hands uncertainty to somebody else.

Our example asks whether Supplier C's insurance certificate is acceptable when it expires before the contract ends. The risk reviewer must decide whether a renewal undertaking is sufficient. The receiver's job is to obtain that answer, not to quietly decide an insurance question outside their authority.

Write the question in a form someone can answer. is a topic. is a decision. If there are several open dependencies, put them in a linked register with a responder and due date for each.

## 4. Give the receiver a first morning

Under **Next actions**, write the first three actions in order. Start each with a verb and name the thing to open or change.

The filled example uses: request the renewal, check portal permissions, send the approval summary. The first action starts in . That is enough detail to begin without a search through email.

Avoid or . Those phrases require the receiver to reconstruct your thinking before doing anything. A useful action has a visible stopping point: the request has been sent, access has been checked, or a summary has reached the approver.

If the first action depends on an answer, name a useful alternative. The receiver can check the other two suppliers' ordering access while the risk reviewer considers the certificate.

## 5. Test files and access, not just links

The **Files and access** row identifies current working files, evidence and the location everyone should treat as authoritative. Archive or label superseded versions before the walkthrough.

Then ask the receiver to open each important location using their own account. A link that works for the outgoing owner can still fail for everyone else. Check editing rights where editing is required, not only viewing.

Never include passwords, recovery codes or shared secret answers in the checklist. Use your organisation's approved account-transfer process. If access depends on IT, give that request an owner and a deadline before the transfer.

For a workspace layout, use the [handover desk template](https://plexiidesk.com/templates/handover). For broader practice, our [project handover guide](https://plexiidesk.com/blog/project-handover) explains how to pass on the work itself rather than a description of it.

## 6. Explain who has authority

In **People**, record roles and escalation routes. A long contact list is not useful if it does not say which person can approve an exception.

The supplier example distinguishes the procurement lead, who approves orders, from the risk reviewer, who accepts insurance evidence. The incoming lead coordinates the work but does not inherit either person's authority by default.

Use the normal work contact route and include availability constraints where relevant. Keep personal phone numbers out of broadly shared copies unless sharing them is appropriate and agreed. Tell stakeholders who their contact will be after the transfer; do not expect them to discover the change through a spreadsheet.

## 7. Pair dates with triggers and responses

In **Dates and risks**, record the deadline and the point at which a response becomes necessary. Those are often different dates.

The example order release is 18 November. If renewal evidence is still missing on 16 November, the incoming lead holds Supplier C's order and notifies procurement. The earlier trigger creates time to act before the final deadline.

Write risks as something that could happen, followed by the consequence and response. is too broad. tells the receiver what to watch.

## 8. Run a walkthrough with the receiver driving

The **Walkthrough** row is not complete because a meeting happened. It is complete when the receiver demonstrates the first action.

Let them share or show their working view. Ask them to find the current certificate, identify the reviewer and explain the escalation date. Resist narrating every click. Where they hesitate is where your handover needs another link, clearer wording or better access.

For work organised in Plexii, a desk can hold the notes, files, tables and tasks for the project together. The [agency and client-service workspace](https://plexiidesk.com/for/agency-client-service) is one example of keeping related material in the same place. Follow your organisation's sharing rules for confidential supplier or client records; the [people and sharing guides](https://plexiidesk.com/help/c/people) explain Plexii's access options.

## 9. Make acceptance explicit

The **Acceptance** row records the transfer time, remaining gaps and fallback contact. It is an operational agreement, not a substitute for any formal contractual acceptance you need.

In the example, ownership transfers at 16:00 local office time on 12 November. Insurance review remains open, and the outgoing lead is available the next working morning. Nobody has pretended that an unresolved item disappeared because the handover meeting ended.

After transfer, preserve a dated copy. If you will be away, agree one route for genuine questions and when you will respond. For ongoing updates, see [keeping clients informed without another status email](https://plexiidesk.com/blog/client-status-updates). The [clients and teams collection](https://plexiidesk.com/blog/c/clients-and-teams) covers the wider pattern of making work understandable to other people.

## Common questions

**Is this checklist suitable for a short period of leave?**
Yes. Keep the status, next actions, access, deadlines and escalation details. Mark genuinely irrelevant rows Not applicable rather than deleting evidence that you considered them.

**Can I keep the checklist in another tool?**
Yes. The columns are simple enough for any spreadsheet, task tool or shared document. Read the filled example in this guide first if you want to see how much detail to include.

**Who signs off the handover?**
The outgoing and incoming owners should agree the operational transfer. Your manager, client or contract may require a separate approval; the checklist does not override that requirement.

**What if access is still missing on transfer day?**
Record the gap, the person resolving it and an agreed temporary route. Do not mark the handover Ready while the receiver cannot reach material needed for the first action.

**Should completed work be included?**
Include completed work that explains the current position or a decision. Link to the archive for the rest. The receiver needs enough history to continue, not every file ever created.

**How often should I update a long-running handover?**
Update it when ownership, deadlines or dependencies change, and confirm the as-at date immediately before transfer. For rolling coverage, agree a regular review with the person sharing responsibility.