Hand off work when two teams mean different things by done
Reconcile twelve fictional handoff records, distinguish submission from acceptance, and prepare criteria, a meeting script, an email and a review worksheet.
On this page
A handoff is usable when the receiving person can check the work against an agreed definition and knows what happens if it fails. Sending a file, completing development and accepting the result are different events. Record each one separately before reporting that the work is finished.
This guide produces a handoff record, a short meeting script, an email and a review checklist. The example and downloadable records are original fictional teaching material. They are not observations of a company or evidence that a checklist improves performance. Replace the proposed terms with conditions that the actual teams agree to.
Reconcile the twelve items before assigning blame
A fictional configuration team submits twelve items to an operations team. At the agreed check-in, eight have been accepted, two returned for clarification and two have not been reviewed. Each item has one current state; the twelve records cover the complete teaching batch. The submission register alone calls all twelve complete because the files were sent.
| Record state | Count | What it supports |
|---|---|---|
| Accepted | 8 | The receiving team checked and accepted these items |
| Returned for clarification | 2 | A response is required; final acceptance is outstanding |
| Awaiting review | 2 | No receiving-team decision is recorded |
| Total submitted | 12 | All twelve were sent; submission does not establish acceptance |
Eight of twelve submitted items are currently accepted: 66.7%, rounded to one decimal. The two unreviewed items remain in the batch denominator. If you also report acceptance among reviewed items, that is eight of ten, or 80%, and must carry the different denominator. Neither measure says that the receiving team caused a delay. The expected review times and reasons for the two returns require separate records.
The downloadable CSV retains all twelve items and their states. These are configuration items, not twelve people or twelve projects. There are no elapsed-time measurements, costs or prior-period figures in the example. Do not report faster delivery, an improvement percentage or a causal explanation from these counts.
Write acceptance as something another person can inspect
“Send the configuration” describes an action. “The receiving reviewer can open the file, match it to the agreed version, run the stated check and find the result” describes a proposed acceptance condition. These conditions must fit the actual work; not every handoff needs software tests or a long checklist.
| Field | Proposed content for this exercise | What still needs agreement |
|---|---|---|
| Scope | The twelve listed configuration items | Whether the receiving team accepts this batch boundary |
| Version | A recorded file or record version per item | Which version is authoritative |
| Check | Inspect the agreed required fields and supporting result | The exact fields and acceptable result |
| Reviewer | A named receiving role | The person, availability and authority |
| Response | Accept, return with a reason, or retain pending status | Review deadline and escalation contact |
| Change | Link a corrected version to the returned item | Whether the change affects other accepted items |
A criterion should be specific enough for both sides to apply it to one example before adopting it. Ask the sender and receiver to check the same item independently, then compare what they regarded as evidence. A disagreement is useful information about the definition. It is not automatically a failure by either person.
Resolve one returned item without rewriting history
Take fictional item H09, which was returned for clarification. Keep the original submitted record and returned state. Add the reviewer’s exact question, the version examined and the missing information. The current materials do not state what was missing, so leave the reason unknown until the reviewer supplies it. Do not invent a missing field to complete the form.
The sender then proposes a correction or explains where the required evidence already exists. Record the next action, responsible person, target time and dependency. All four remain pending agreement in this example. A correction does not become accepted when the sender uploads it: the receiving reviewer still needs to inspect it against the agreed criteria and record the result.
If both teams change the criteria during the discussion, keep the old criteria, the agreed change and its effective scope. Do not retrospectively label the first submission defective under a rule that did not apply then. If another accepted item needs a new check, identify it explicitly rather than silently resetting the entire batch.
Run a short alignment conversation
Use one concrete record to keep the discussion manageable. The aim is to agree on evidence and responsibilities, rather than win an argument about the word done. A facilitator can read the following fictional script and stop wherever a fact or commitment is missing.
We have twelve submitted items. Eight are accepted, two returned for clarification and two await review. Our submission register and your acceptance record measure different events. For H09, could we inspect the version and the exact question together? Then we can agree what evidence would allow you to accept it, who will supply it and when you can review it. The reason and timing are still open; I am not treating either as agreed.
Ask the receiving person to describe the check in their own words. Ask the sender to show where the evidence will appear. Confirm the response route for an incomplete item and who can decide when the agreed reviewers are unavailable. Record actual agreement in the meeting note; silence, attendance or being copied on an email does not prove consent or approval.
Send an email that preserves the open questions
Subject: Please confirm acceptance checks and review arrangements for the twelve-item batch
At our check-in, twelve configuration items have been submitted: eight accepted, two returned for clarification and two awaiting review. The current accepted share of the submitted batch is 8/12 (66.7%); sending all files does not establish acceptance.
Please confirm the check and evidence needed for H09, the responsible reviewer, and a feasible response time. We propose recording the item version, check result, acceptance or return reason, and next action in the shared register. These arrangements are awaiting your agreement. If the criteria change, please identify which items and versions the change applies to.
Once the arrangements are confirmed, we will update the pending actions and report acceptance separately from submission. We have not established a cause for the outstanding items or measured an efficiency improvement.
Replace the requested time with a real deadline only after checking the decision need and the receiver’s availability. Avoid “as soon as possible” when a specific dependency matters. If a deadline cannot be agreed, record the dependency and ask the authorized owner to choose between scope, timing or additional support.
Review the handoff without overstating the effect
At the next check-in, inspect every previously outstanding item. Retain its prior state, new version, actual response and evidence. Count a returned item as accepted only when the receiving decision is recorded. If the review window is still open, report that fact rather than treating silence as rejection or success.
Use the downloadable worksheet to record the agreement and follow-up. It separates an action being completed from its observed effect. A more complete register may make the status clearer, but that does not prove that delivery became faster. To evaluate timing later, define start and end events, include unfinished items and compare compatible work. The present example supplies none of those measurements.
Before sending the update, check that all twelve items remain accounted for, each status has evidence, every new commitment is actually agreed, and unknown causes remain unknown. Keep the submitted and accepted totals side by side. A useful closing request names the specific unresolved decision and who has authority to make it.
When the discussion is a broader disagreement about priorities, use the work disagreement guide. When an outstanding dependency threatens a milestone, prepare a project delay update with the effect and request still distinguished from the cause. The handoff record supplies evidence to those conversations; it does not decide their outcome.