Complete the checklist for a real handover
Choose a specific transition: design to development, team to client or project to support. “Project finished” is too vague. This deliberately small template can be copied into a project document.
Review from the recipient's perspective. A long file list is unhelpful if the valid version is unclear. The goal is a usable basis for the next agreed step, not perfect documentation of all previous work.
Copyable handover template
| Field | Completed example |
|---|---|
| Handover | Layout version 03 to development |
| Outcome | Mobile and desktop views with confirmed content order |
| Recipient | Responsible role: development |
| Next action | Technical implementation of agreed navigation |
| Open point | Usage rights for image 02 still being clarified |
| Owner of the open point | Project lead consolidates client feedback |
| Completion criterion | Recipient can open the files and confirms they match the intended version |
Before the handover meeting
State the scope
Separate the agreed outcome from parts not yet included. Do not hide missing components behind a general “finished” status.
Identify the working basis
Compile files, versions and relevant decisions. Identify outdated versions without assuming an unavailable versioning feature.
Hand over open points
Assign a role and next step to each open point. “To be clarified later” is not an actionable task.
Test access
Check with the intended recipient that required content is accessible. Internal admin access is not a substitute.
During the meeting: questions test the handover
Ask the recipient to describe the next step in their own words. A different answer reveals ambiguity in the handover package. This is more useful than asking whether everything is clear.
In the example, development might think image selection is final. Clarify: content order is confirmed, but one image's rights are unresolved. This invents no new approval status; it visibly separates two facts.
After handover: do not confuse completion with acceptance
An organisational receipt confirms the package arrived and was identified. Whether this also constitutes contractual acceptance requires separate clarification. Use precise terms.
If a file is replaced later, identify the affected version and tell the responsible recipient exactly what changed. They should not have to guess whether work already started still matches the current basis.
From the guide to the sample project.
Try the steps in the OOKI demo: tasks, client view, time entries and invoice draft with fictional data. No login required.
Try the demo (DE)