Finish a handover in one sitting

Thirty minutes, one receiver, one file

A handover fails when it becomes a second project. Give it one sitting: about thirty minutes with the person who will receive the work, in the project handover tool, and stop when scope, the files they must open, and the open work each have an owner. You can deepen the record later. You cannot recover a meeting that produced a slide and no names.

This sitting produces a transfer snapshot, not the living inventory. The deliverables register keeps ID, location, version and acceptance evidence over time. The handover tool’s item columns are only Item, Location / reference, Owner and Status. Do not paste the register’s extra columns into the tool. The batch will be refused.

The handover checklist is the longer walkthrough. Use it when you are preparing alone. Use this guide when the receiving person is in the room and the clock is the constraint. Fictional sitting: Alex Morgan hands the Northstar customer portal to Riley Chen on 9 October 2026. Sam Lee still owns the payment sandbox. The launch date is not accepted.

Do not schedule a follow-up workshop in order to avoid an incomplete row. An empty Next step, written honestly, is more useful than a second meeting that repeats the same uncertainty.

Spend the half hour in four blocks

1. Five minutes — boundary. Project name, Handover date, Outgoing owner, Receiving owner. In Scope and boundaries, write what is included and what is not. If a later release or a vendor contract is outside this handover, say so. A list of files must not imply that every obligation is finished.
2. Ten minutes — files they can open. Add a handover item only if the receiver can reach it. Location / reference is a path, file name or version they can try during the sitting. Owner is who keeps that item after today, which may still be the outgoing owner for unfinished work. Status is a word you agree, such as Ready for review or Accepted. “Accepted” is a status you type. The tool does not verify it.
3. Ten minutes — open work. Each open item needs the effect, one Owner, a Next step and a Due date the owner accepts. “Some testing remains” is not an item. “Six payment tests are blocked by sandbox access” is. If the date is not agreed, leave Due date empty.
4. Five minutes — read-back. The receiver opens one referenced file before you export. If they cannot, fix the reference or mark the item as not yet accessible. Then fill Support and follow-up with how questions will be asked after today, and Acceptance criteria / confirmation with what “done” would require. Do not invent a signature the organisation does not use.

Work in the tool while you talk. A notebook that is typed up tomorrow splits the sitting into two, and the second one often never happens. Basics, the two tables and the narrative fields are enough. You do not need a slide.

Enter it so the snapshot stays honest

1. Open the handover tool and start blank if an example is showing. Replace every fictional name before you export.
2. Type the four header names before the tables. Outgoing owner and Receiving owner are people, not departments. Handover date is the day of this sitting.
3. Add handover items with Add row. If you paste from the register, copy only Item, Location / reference, Owner and Status, in that order. Leave ID, version history and acceptance evidence in the register. Preview before you add. Untouched empty rows can be replaced; rows you have typed are kept and the paste appends.
4. Add open items the same way: Open item, Owner, Next step, Due date. Cap the table at what this receiver must see. Fifty rows is the tool limit; a sitting should need far fewer. Park the rest in the register or the issue log.
5. Write Acceptance criteria / confirmation as the condition, not as a claim that it has happened. “Riley to confirm the sign-in report matches the agreed scenarios” is a condition. “Fully accepted” is a claim you cannot support from this form.
6. Review & export. Download Word or Excel so both people can keep an editable copy, and use Print / save PDF if someone needs a fixed reading copy. Save a JSON backup if you might correct the snapshot in this browser later. The draft stays on this device until you delete it.

Passwords, tokens and private keys do not go in Location / reference or in any narrative field. Point to the organisation’s access process. The tool will not redact a secret you type.

Fictional thirty-minute Northstar handover

Alex does not mark the payment work Accepted. The snapshot says the sign-in report is ready for review and the tests are open. The deliverables register keeps D-01 for the report, including whatever acceptance evidence appears later. Updating the register does not rewrite this handover file, and exporting the handover does not update the register.

If Riley finds the file path wrong during the sitting, they fix it before export. Discovering the broken path next week means the sitting did not include the open-one-file check.

Common mistakes, and the correction

The draft and paste guide is there if you resume the snapshot later. It is not a reason to delay the export that both people can keep.

What one sitting will not do

• It will not transfer access, licences or accounts. It records the reference you type. The receiver still has to sign in through your organisation’s process.
• It will not accept the work. A status word is not a signature, and the tool does not contact an approver.
• It will not stay in sync with the deliverables register, the issue log or the status report. Copy by hand when those records change.
• It will not hold the register’s ID, version and evidence columns. Keep that workbook as the inventory.
• It will not store more than one local draft, survive cleared site data without a JSON backup, or upload your files to WorkFormKit.
• It will not replace a legal novation, a support contract or a security review. Put those outside this document and mention them in Scope and boundaries if they bound the work.

Fictional close: Riley leaves with an exported file, one opened report, and Sam’s name on the payment tests. Alex keeps the same snapshot as the transfer record and updates the deliverables register afterwards, not instead. The sitting is finished when those names are in the file, not when every historical question has been answered. Questions after that date go to the contact named in Support and follow-up.