Operational handover π¦
The coach steps back, and the system keeps running.
This stage looks like the easy stage at the end. The work is done; what's left looks like a debrief and a handshake. The temptation is to fade out β the engagement gets quieter, the meetings get rarer, the partner sticks around "in case anything comes up." You are the one who decides whether the project actually closes, or whether it quietly becomes a permanent fixture in the team's life.
The work at Stage 13 is the deliberate ending: showing the change clearly enough that it can't be forgotten, transferring ownership of measurement to the people who'll keep it alive, and honestly sorting what's left β without trying to drag it into this project's scope.
In this document
Sorting the open loops β and the clean break
What to prepare before this stage
Avoid this if you don't want your transformation to fail or delay
What you get with the full protocol
1οΈβ£ What happens at this stage
This stage runs across roughly one to two weeks, picking up immediately after the Consolidation of changes π³ stage closes. The shape is three sequenced closing meetings β one with the Change Leaders to transfer responsibility, one with the Guardian to align on what the Sponsor needs to see, one with the Sponsor to debrief the whole project and decide what (if anything) comes next.
Note on naming (Sponsor, Guardian, Change Leaders, Workflow Guardians) β click to reveal
Roles were set earlier β Sponsor, Guardian, and Change Leaders at the
Kick-off π stage; the Change Alliance and its Workflow Guardians at the Change Alliance π₯ stage. By this stage every role is already in place; your job is to make the transfer of ownership visible and final, not to keep holding scope.
The Last Survey runs in parallel to capture the team's after-snapshot for side-by-side comparison with the Audit π stage baseline.
Three things happen in parallel through this stage:
- Measurement is closed: The Last Survey is sent (a parallel of the Audit π stage's baseline, scored on the same behavioural questions plus a Guardian/Sponsor satisfaction section), the deltas are calculated, and the before/after picture becomes the centre of every closing meeting. Without the delta, the change is invisible; without visibility, the next conversation defaults to cost, not outcome.
- Responsibility transfers: What you've been holding as the Operator (convention enforcement, workflow gaps, cross-team friction) moves to the Workflow Guardians named in the Change Alliance at the Change Alliance π₯ stage. The transformation partner steps fully out of the daily work β future calls become a new agreement, not an extension of this one.
The decision about the next cycle: The Consolidation of changes π³ stage already surfaced the open loops, half-finished conventions, and adjacent teams asking to be next. This stage doesn't try to solve them. It sorts them honestly β and lets the current project end on its original scope before any of that begins.
2οΈβ£ Making the change visible
The single hardest mechanic in Stage 13 is that the people who lived through the change have already forgotten what it cost them before. Three months ago the Sponsor was paying for chaos in handoffs; today the Sponsor has stopped noticing handoffs at all because the handoffs work. The change is now invisible β which means a CFO asking "was this worth it?" gets a vague answer instead of a clear one, and the team itself stops feeling proud of what changed.
The instrument that closes the gap is the Last Survey β the same set of behavioural questions you ran at the Audit π stage before any of this started, re-run at the end. Two surveys, same questions, three months apart. The baseline instrument captured what was true before; the Last Survey captures what's true now. The difference between the two is the project's case β and it's the raw material for the case study, the next-cycle conversation, and the team's own sense of what they actually accomplished.
The survey has two parts, sent to two audiences:
- Change Leaders survey (Kirkpatrick Level 3: behavioural change) β are tasks being completed in the platform; are status updates landing without being chased; are the conventions from the Work Conventions π€ stage surviving real work? Mirrors the baseline questions so the delta is comparable.
- Guardian & Sponsor survey (Kirkpatrick Level 4: business outcome and satisfaction) β did the transformation deliver what the Sponsor signed up for; what changed in how the organisation operates; what's the strongest piece of evidence the change is real?
The Project Sum-up report β the document the Guardian carries into the Sponsor debrief β is structured around the delta the survey reveals. List the metrics that moved. List the workflows that were implemented. List the behaviours that still need work. List the open loops, sorted. Show before/after side by side. The Sponsor reads it before the meeting; the meeting itself is about what to do with what the report shows, not about discovering what's in it.
3οΈβ£ The three closing meetings
Stage 13 runs three meetings in a fixed sequence β first with the Change Leaders, then with the Guardian, then with the Sponsor. Each one transfers a different thing; the order matters because each meeting's output is the next meeting's input.
Meeting 1 β Project sum-up with the Change Leaders. Run by your Guardian; the transformation partner observes. Roughly 60 minutes. Walks the team through the before/after picture, acknowledges what they built, transfers day-to-day responsibility for each workflow to the Workflow Guardians named in the Change Alliance, and surfaces any unresolved issues that need to be queued. This is where the team finds out, in plain language, that the project is ending β and that what's been built is now theirs to keep alive. The Last Survey is sent immediately after this meeting so the after-snapshot lands while the recognition is still fresh.
Meeting 2 β Project sum-up with the Guardian (1:1). Run between the Guardian and the transformation partner. Roughly 60 minutes. Walks through v.1 of the Project Sum-up report, calibrates what the Sponsor needs to see, decides which open loops to surface and which to defer, and seeds the case-study confirmation that gets approved at Meeting 3. The output is v.2 of the report β the version that goes into the Sponsor meeting.
Meeting 3 β Sponsor debrief. Run by the Guardian; the transformation partner is in the room. Roughly 60 minutes. The whole-project debrief β what was scoped, what was delivered, what changed in the business, what the Sponsor's verdict is, and what comes next (if anything). The Sponsor's sign-off here is what makes the project officially over; the final invoice ships after this meeting, not before.
4οΈβ£ Sorting the open loops β and the clean break
By the time Stage 13 lands, Stage 12 has already surfaced the things this project won't finish β workflows that don't quite fit, conventions that don't quite survive real work, teams that weren't in the original scope, adjacent problems whose owners sit elsewhere in the organisation. Stage 13's job isn't to solve them. It's to sort them β clearly enough that the current project ends on its scope, and the team knows what's worth doing next.
Some of these problems only become visible at the end β and not all of them belong to this project.
Don't try to absorb them. Name them to know what to do with them next.
The sort uses three buckets:
- Closed in this project. Workflows implemented, conventions installed, behaviours that show up reliably in the Last Survey delta. The current contract delivered these; the Sum-up report names them by name; the team owns them now.
- Queue for the next 90-day cycle. Adjacent teams asking to be next, workflow gaps that surfaced during Consolidation, second-tier conventions that need a focused sprint of their own. These belong in a new engagement, not an extension of this one. The current project closes on schedule; the next 90-day cycle picks them up as its own scoped work, with its own contract.
- A different kind of help entirely. Some problems show up as workflow problems but actually aren't. A team whose conventions keep failing because of a leadership-design issue. A senior team member whose resistance is a personal blocker, not a system one. A cross-functional misalignment that needs board-level mediation, not a better Asana project. Sometimes the deepest layer is a single person's psychological roadblock β and that needs a coach or, in the hardest cases, professional psychological support, not another workflow. Name these too β and name what kind of help each one needs. The Reliability Protocol doesn't solve these; honesty about which problems it can't solve is what earns the next conversation.
The clean break that lets the sort hold is a deliberate decision the Operator makes. Without it, the project decays into permanent fixture: the partner stays loosely available, the calls keep happening, the scope quietly creeps into related-but-not-really-related work. With it, future work is a new agreement β new scope, new contract, new commitment on both sides.
The clean break is three concrete moves:
- Name the date the project ends. Not "we'll wrap up soon." A specific calendar date the team and the Sponsor both see at the Consolidation of changes π³ stage's weekly meeting and again in this stage's closing emails. Ambiguity is what scope creep grows in.
- Move ongoing monitoring fully to the client. The Guardian runs the Last Survey, calculates the delta, owns the Health Check from the Consolidation of changes π³ stage onward. Email and phone access for questions stays open; standing meetings end on the project end date; the audit is now an internal job.
- Treat future work as a new agreement. When a sibling team asks "can we run this here too?" three weeks after close, the answer is "yes β let's scope a new project." Not "I'll just join your standup." The frame protects both sides: the team's ownership stays intact, and the partner stays scoped to work that has clarity around it.
5οΈβ£ What to prepare before this stage
- The Last Survey is configured and ready to send β same behavioural questions as the Audit π stage baseline, plus the Guardian/Sponsor satisfaction section. Delivered as a Tally form (or equivalent) the Change Leaders can fill in 10 minutes.
- The Audit π stage baseline survey results are pulled and clean β you'll need them side by side with the Last Survey results to calculate the delta. Lost baselines mean a lost case.
- The Project Sum-up report template is populated β workflows implemented, metrics moved, behaviours still in progress, open loops sorted into the three buckets, recommendations for the next cycle. Two versions: v.1 for the Guardian 1:1, v.2 (updated after that meeting) for the Sponsor debrief.
- The three closing meetings are scheduled in order β Change Leaders meeting β Guardian 1:1 β Sponsor debrief, ideally within two weeks of each other, with the Last Survey landing immediately after Meeting 1 so the deltas are fresh in Meeting 2 and Meeting 3.
- The case-study ask has been seeded β ideally at the Kick-off π stage, but at minimum by the end of the Consolidation of changes π³ stage. The Guardian meeting confirms; the Sponsor meeting approves.
- The closing emails are drafted with the right names and dates β the pre-Guardian-meeting email, the Change Leaders summary, the Guardian summary, the Sponsor summary. Each ships after the relevant meeting, not in a single batch.
- The next-cycle conversation is prepared, not improvised β if there's a candidate scope for what comes after (a sibling team, a deeper convention sprint, a leadership engagement), have it written down before the Sponsor debrief. Offer it as an option, not a pitch.
6οΈβ£ Avoid this if you don't want your transformation to fail or delay
βΌοΈ Don't let the project trail off. The single most expensive failure at this stage is the project that quietly never ends β the standing meetings get rarer but never stop, the partner is "still around if you need anything," the team never fully owns the system because someone else is still loosely responsible. Name the end date. Hit it.
βΌοΈ Don't run the closing meetings out of order. Sponsor first means the Guardian walks into the debrief unable to answer team-level questions; Guardian after Sponsor means the Change Leaders find out from their boss that the project is ending. Change Leaders β Guardian β Sponsor isn't a suggestion; it's how each meeting's output becomes the next one's input.
βΌοΈ Don't skip the Last Survey. Without the after-snapshot, the delta is a story you're telling β not a measurement the Sponsor can verify. The case study, the next-cycle conversation, the team's own sense of what they accomplished all depend on the Last Survey running. "We don't have time for it" is the failure mode disguised as practicality.
βΌοΈ Don't treat the open loops as failures. Every project surfaces work that isn't this project's job β and the temptation, on both sides, is to absorb the loops rather than name them. Absorbing them turns this stage into the next stage of an unbounded project; sorting them turns them into the next cycle's worth of work, or a different kind of help, or genuinely "leave alone." The team that learns to sort outperforms the team that tries to do it all in one engagement.
βΌοΈ Don't pitch the next project in the Sponsor debrief. The Sponsor meeting is for closing this project, not selling the next one. Mention what's possible if asked; offer a written scope if there's a clear candidate; but the debrief earns trust because it isn't a pitch. The next-cycle conversation lands cleanly when it's a separate meeting, on the Sponsor's terms.
βΌοΈ Don't keep auditing the system after handover. Once the project's officially closed, the Last Survey is filed, and the final invoice has shipped, future audit work is a new scope and a new contract. Free "I'll just check in" support after handover is what turns a closed project into a permanent fixture β and the team never learns to spot drift without you.
β What you get with the full protocol
The full Reliability Protocol is delivered as one weekly action by email β you receive one stage at a time, with one implementable artifact, and one clear next step you (or your Guardian) can act on that week. The artifacts you get for this stage:
- The Project Sum-up Report Template β pre-structured report (metrics delta, workflows implemented, behaviours still in progress, open loops sorted into three buckets, recommendations for the next 90-day cycle) plus the v.1 β v.2 revision protocol (what gets adjusted between the Guardian 1:1 and the Sponsor debrief).
- The Last Survey instrument β Tally form configured with the Kirkpatrick Level-3 behavioural questions mirroring the Audit π stage baseline, the Level-4 business-outcome and satisfaction questions for the Guardian and Sponsor, and the calculator that turns paired responses into the side-by-side delta the Sum-up report uses.
- The Three Closing Meetings Agenda Pack β minute-by-minute agendas for the Change Leaders meeting, the Guardian 1:1, and the Sponsor debrief, plus the "guide, don't take the credit" facilitator framing and the script for the Sponsor's recommendation question without it tipping into a pitch.
- The Open Loops Sort Worksheet β the three-bucket sort (closed here / next cycle / a different kind of help entirely) with the decision rubric for each bucket and the language for naming the "different kind of help" category honestly without it sounding like a pivot or a shrug.
- The Closing Emails Pack β drop-in templates for the four moments (pre-Guardian-meeting, Change Leaders summary, Guardian summary, Sponsor summary), each with placeholders for the project-specific deltas the Sum-up report surfaces.
- The Clean Break Playbook β the scope-creep failure modes mapped, the three concrete moves (named end date, measurement transferred, future work as new agreement), and the conversation scripts for the soft-pressure moments where the project would otherwise drift into permanent fixture.
π¬ Take this with you and your team can run Operational Handover yourself. Hit a wall and want a partner β book the session below.
When to bring in a partner
The package above covers the framework. Most operators run it themselves. Bring in a partner when:
- The Sponsor debrief is high-stakes. When the project's ROI is contested, when the Sponsor has shifted mid-project, or when the next-cycle conversation matters more than the closing itself, a partner sitting beside the Operator in the debrief changes the dynamic β the room reads it as a joint readout, not a vendor pitch.
- The open-loops sort surfaces problems you can't categorise. When workflow problems turn out to be team-design, leadership, or individual psychological problems, the honest sort is harder than the workflow itself. Partner-side pattern recognition across many projects helps you name what each open loop actually needs β and avoid the trap of trying to fix it all with one more workflow.
- The clean break is politically difficult. When the team has bonded with the partner, when senior stakeholders want "ongoing support" as a reassurance, or when a sibling team is already pressing for the next engagement before the current one's closed, the clean-break conversation requires a standing the Operator alone often doesn't have. A neutral partner makes the ending land as professional, not abrupt.
π‘ This is Stage 13 of the Reliability Protocol β Remote Sensei's 15-stage system for permanent organisational transformation, and the global standard for Asana implementation: making Asana and AI stick in mid-size and enterprise teams so work ships on time without anyone chasing it.