Operational handover πŸ“¦

The coach steps back, and the system keeps running.

The Reliability Protocol β€” 15 stages, 4 phasesYou are at Stage 1: Discovering problems worth solvingALIGNMENTFOUNDATIONADOPTIONMOMENTUM123456789101112131415You are hereALIGNMENT1. Discovering problems2. Preparations3. Kick-off4. Audit5. Implementation PlanFOUNDATION6. Workflow Mapping7. Work Conventions8. Asana AllianceADOPTION9. Training10. Launch11. Onboarding12. ConsolidationMOMENTUM13. Operational Handover14. Business Impact Review15. Post-Transformation
The 15-stage Reliability Protocol map. Stage 13 opens the Momentum phase (Stages 13–15) β€” the current project closes here; what comes after is structurally a new agreement.

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

What happens at this stage

Making the change visible

The three closing meetings

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.

Making the change visibleBEFORE β€” Stage 4AFTER β€” Stage 13Past-due rate: 30%Past-due rate: 8%Status chased weeklyStatus posted in-platform"Who owns this?" β€” unclearOwnership visible in workflowMemory is unreliable. People stop seeing the before. The difference visualised is what stops the change from becoming folklore.
The Last Survey runs the same questions as the Stage 4 baseline. The delta is the project's case. Without it, the change is folklore

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.

Each meeting's output is the next one's inputMeeting 1Change Leaders‒ Show before/after‒ Acknowledge what was built‒ Transfer day-to-day toWorkflow Guardians‒ Send Last Survey right after→ output: responsibilitytransferredMeeting 2Guardian (1:1)‒ Walk through Sum-up v.1‒ Decide what the Sponsor sees‒ Seed the case study‒ Sort the open loops→ output: Sum-up v.2 readyMeeting 3Sponsor debrief‒ Whole-project readout‒ Sponsor verdict‒ Confirm case study‒ Name what's next (separately)→ output: sign-off
Three meetings, fixed order

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.

Sorting open loops fromprevious StageClosed in this projectβ€’ Workflows implementedβ€’ Conventions installedβ€’ Behaviours showing in deltaNamed in the Sum-up. Team owns thesenow.Next 90-day cycleβ€’ Sibling team asking to be nextβ€’ Workflow gaps not in scopeβ€’ Convention sprint phase 2New engagement, new contract. Not anextension of this one.A different kind of helpβ€’ Leadership-design issueβ€’ Personal blocker in a key personβ€’ Cross-functional mediationNot a workflow problem. Needscoaching, org design, sometimes apsychologist β€” not another Asanaproject.Bucket 1Bucket 2Bucket 3
Three buckets. The clean close depends on naming + decision what's 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.

End of project β€” Sponsor debriefπŸ›‘οΈ Path A β€” Clean break🚫 Path B β€” Permanent fixture1. End date named publicly2. Measurement transferred to Guardian3. Future calls = new agreementβ†’ Last Survey filedβ†’ Final invoice shipsβ†’ Standing meetings endβ†’ Team fully owns the systemNext-cycle decision happens cleanly, separately, when the team actually needs it.1. End date stays vague2. Partner keeps auditing "just in case"3. "Loose support" never quite endsβ†’ Standing meetings get rarer, not zeroβ†’ Scope creeps into related workβ†’ Partner becomes quiet dependencyβ†’ Team never fully owns the systemFeels supportive. Hollows out the team's ownership of what was built.
Two paths. The clean break is harder in the moment and cheaper across the year. The permanent fixture feels supportive and quietly hollows out the team's ownership of what they just built.

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.

➑️ How it works · ➑️ Client results

Yes, we use cookies in accordance with the Privacy Policy