Consolidation of changes π³
Avoiding the backslide to old habits.
This stage looks easier than the stages that preceded it. The system is launched, the onboarding project is running, the team is mostly inside Asana. The temptation is to declare success and step back.
In this document
Making the platform the single source of truth
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
Stage 12 runs across roughly three to five weeks, starting seven to ten days after Launch Day. The shape is simple: one weekly meeting plus a weekly Health Check audit, both run by the Guardian β not the transformation partner. The meeting picks up where last week's audit pointed; the audit feeds next week's meeting. By the end of the stage, the cycle is something your organisation can run without anyone from the outside in the room.
Three things happen in parallel through this stage:
- Measurement shifts to the client. The weekly Health Check audit moves from "the coach checks the workspace" to "the Guardian checks the workspace and tells the team what they found." The transformation partner watches; doesn't audit.
- Ownership shifts to the workflow owners. Each workflow you built at the Mapping & Implementing Workflows π οΈ stage starts to belong, day-to-day, to the Workflow Guardian named in the Change Alliance at the Change Alliance π₯ stage. The Operator stops being the only person who can answer "is this still working?"
- Open issues get sorted, not solved. You won't fix everything inside this stage. You'll surface what's left, name what's worth solving first, and queue the rest for the next 90-day cycle. That sorting is the work.
Note on naming (Sponsor, Guardian, Change Leaders, Workflow Guardians) β click to reveal
Sponsor, Guardian, and Change Leaders were formally appointed at the
Kick-off π stage.
The Change Alliance was named at the Change Alliance π₯ stage β including the Workflow Guardians who'll own each individual workflow after this stage.
By now every role is in place; your job is to start handing scope to them, not to keep holding it yourself.
2οΈβ£ The Weekly Health Check
The single most load-bearing artifact in Stage 12 is a ten-minute weekly audit the Guardian runs on the live workspace. It exists for two reasons: to catch drift before it spreads, and to move measurement from your transformation partner to your own organisation. As long as the coach is the one running the audit, the system is still on training wheels.
The audit reads three live signals on the workspace:
- Are tasks moving? Past-due rate, completion velocity, whether actionable tasks have due dates and assignees at all.
- Are people actually using the platform? Asana's admin-panel insights view tells you who's signed in, who's posting, who's quietly drifting back to email and channels.
- Are conventions holding? The naming patterns, the project structures, the status-update cadence agreed at the Work Conventions π€ stage β are they showing up in this week's real work, or being silently renegotiated?
The Guardian rotates which teams or projects get the deep look β Week 1 might be Marketing, Week 2 Sales, Week 3 Operations. Three random projects, ten minutes, scored in the same scorecard each week. Trend matters more than the absolute number; the question the audit answers is "is the curve climbing, stable, or decaying?"
3οΈβ£ The meeting mix
Stage 12 runs one weekly meeting, roughly an hour long, attended by the Guardian and the Change Leaders. The thing that's different from earlier stages: the meeting type is chosen by what last week's Health Check said, not by what's written on a syllabus. Five distinct meeting types are available; you pick the one this week's data calls for, and you mix them across the stage.
The five meeting types and what each is for:
- π£οΈ A.M.A. (Ask Me Anything) β open floor. Run this when the audit shows confusion or quiet drift more than a specific failure mode. The questions team members raise will tell you what convention or feature needs the next meeting's focus.
- π Best Practice / Success meeting β run this when the audit surfaces a clear Champion or a workflow that's outperforming. The Champion shows the rest of the team how they're using the platform; recognition is public, learning is peer-to-peer.
- π§° Feature Focus workshop β run this when the audit shows people aren't using a feature they need (Forms, Rules, Portfolios, Advanced Search). Deep dive on one feature; demo on real work, not a sandbox.
- π Use Case Deep Dive β run this when the audit shows a specific workflow is breaking down (Meeting Agendas, Sprint Planning, New Hire Onboarding, Editorial Calendar). Walk through the workflow live; discuss best practices and the common failure modes.
- π Progress Review β run this near the end of the stage. Pull up the Miro frame from the Kick-off π stage with the original goals; ask each Change Leader where their team has moved relative to those goals; collect the feedback that becomes the case study.
By Week 3 or 4, the meeting before the last is typically a Continuous Improvement workshop β the Guardian runs the team through an Iceberg reminder (what changed on the surface, what's still underneath), then together they sort the open issues into "solve now," "solve in the next cycle," and "leave alone." That sort is the bridge to the Operational handover π¦ stage.
4οΈβ£ Making the platform the single source of truth
The most common failure mode at Stage 12 isn't that the team rejects the new system. It's that they're using it β and still using the old channels in parallel. Work happens in Slack, gets summarised in email, gets logged in Asana three days later. The new system becomes documentation, not the place where work actually happens.
Your job at Stage 12 is to collapse that parallel use back to one source of truth. Three moves do most of the work:
- Redirect the conversation when it lands in the wrong channel. When a team member messages you in Slack about a task, your reply is "let's move this to the task" β and then you do. Repeat for two weeks; the channel drift stops being viable.
- Publish the conventions visibly. The project that holds the team's naming, structuring, and communication conventions (built at the Work Conventions π€ stage) is open, accessible, and referenced in every meeting. If conventions are invisible, they aren't conventions; they're folklore.
- Work one-on-one with resisters. There's always someone β usually one or two people β for whom the new system feels like loss of control or loss of competence. Don't broadcast at them in meetings; sit with them privately, find what's costing them, fix it. Public pressure on a resister hardens the resistance; private support usually dissolves it.
The strongest version of this principle, used when the team is ready for it, is the rule "if it's not in Asana, it doesn't exist." It sounds extreme. It works because it removes the ambiguity that makes parallel channels survive. But it only lands when the leader using it has the standing to enforce it β which is why this rule belongs to the Sponsor or the most senior Change Leader, not to the Operator alone.
5οΈβ£ What to prepare before this stage
- The weekly meeting slot is locked in β same day, same hour, three to five weeks ahead. First meeting lands seven to ten days after Launch Day, not later.
- The Asana Workspace Audit instrument is set up β the scorecard the Guardian will use each week (whether a Tally form, a Google Form, or a structured Asana task) is configured before the first meeting.
- The portfolio dashboard from the Onboarding π stage is still live so the Health Check can pull cohort-level signals at a glance.
- The conventions project from the Work Conventions π€ stage is published and accessible to every team member β not buried in a folder, not pinned in a Slack channel, in Asana.
- The original Miro board from the Kick-off π stage is reachable β you'll need the goals frame for the Progress Review meeting and the Continuous Improvement workshop.
- The post-stage sum-up email template is ready β this stage ends with a short email to the Guardian and Change Leaders naming what's done, what's queued for the next cycle, and what closing the project will look like at the Operational handover π¦ stage.
6οΈβ£ Avoid this if you don't want your transformation to fail or delay
βΌοΈ Don't keep auditing the workspace for them. The single most expensive mistake at this stage is the transformation partner β or the Operator β running the weekly audit themselves while the Guardian watches. The audit is the load that has to shift; if it doesn't, the system collapses ninety days after the partner leaves and the Operator burns out trying to be the auditor forever.
βΌοΈ Don't measure adoption by Asana use alone. A team can log every task in Asana and still be running the real work in email. Measure whether conversations happen in the platform, whether status updates show up without being chased, whether the conventions from the Work Conventions π€ stage are surviving real work. Volume of tasks is not the signal β texture of behaviour is.
βΌοΈ Don't sweep problems under the carpet. This stage will surface workflows that don't quite fit, conventions that don't quite work, teams that weren't in the original scope. Name them in the open. Some get fixed now; the rest get queued for the next cycle. What you can't do is pretend they're not there β the team notices, and the trust in the system erodes faster than any single workflow failure does.
βΌοΈ Don't try to absorb everything into this project. When cross-team interest surfaces ("can we run this on our team next?") or a workflow gap shows up that wasn't scoped, the temptation is to extend the project to handle it. Don't. The current project ends on its original scope; the next 90-day cycle picks up what's worth doing next. Teams that learn to sequence transformation in chunks outperform teams that try to do it all at once.
βΌοΈ Don't let the meetings drift into status reporting. The hour each week is for deciding what to do next , based on what the Health Check shows. If the meeting becomes "everyone reports what they did," the load has shifted back to passive listening and the cycle is dead. The meeting is action; the audit is information; the conventions are the rule.
βΌοΈ Don't skip the public Champion recognition. Recognition feels small. It is in fact the cheapest, highest-leverage habit-installation tool in the protocol. Teams that get publicly recognised for the new behaviour start producing more of it within the same week; teams whose work goes unnoticed start producing less of it within two.
β What you get with the full protocol
The full Reliability Protocol is delivered as one weekly action by email. You don't read 15 stages in one sitting β 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 Weekly Health Check Scorecard β the ten-minute audit instrument (Tally form, pre-configured questions, Kirkpatrick Level-3 scoring, trend-tracking sheet) plus the Guardian playbook for running it solo by Week 3 and the "Vital Signs" script for introducing it to the team without setting off compliance anxiety.
- The Meeting Mix Agenda Pack β agendas for all five meeting types (A.M.A., Best Practice, Feature Focus, Use Case Deep Dive, Progress Review) plus the decision rubric that maps this week's Health Check signal to the meeting type you should run.
- The 11-question Coach Bank β eleven discussion questions calibrated for behavioural change, case-study harvesting, and surfacing the next-cycle backlog. Tag-coded so the Guardian knows when each one earns its place in the room.
- The Continuous Improvement Workshop kit β the Miro template for the closing workshop (Iceberg frame, improvement plan, next-cycle sort) plus the facilitator notes for running the sort cleanly without it turning into a wish list.
- The Single Source of Truth Enforcement Playbook β the three moves (redirect-to-tool, conventions-visibly-published, 1:1-with-resisters) with the conversation scripts and the escalation pattern for when a workflow leader can't enforce a convention themselves.
- The Post-Stage Sum-up Email Template β drop-in email the Guardian sends to Change Leaders at the end of the stage, naming what's done, what's queued for the next cycle, and what closing the project will look like at the Operational handover π¦ stage.
π¬ Take this with you and your team can run Consolidation 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:
- You don't have spare cycles for the weekly Health Check. Stage 12's measurement loop only works if someone runs it every week without fail. Partner-side co-monitoring catches drift the Operator misses during a busy month and frees the Guardian to learn the audit at a sustainable pace.
- Adjacent teams are asking to be next. When a sibling team or a cross-functional partner sees the new way of working and asks "can we run this here too?", that's not a feature of this project β it's the next project surfacing. A partner can scope the follow-on cycle while the current one closes cleanly.
- The resister conversation is high-political. Single-source-of-truth enforcement against a senior team member who's quietly working around the system is one of the most expensive conversations in the protocol. A neutral partner sitting beside the Operator changes the dynamic; alone, the same conversation often hardens the resistance.
π‘ This is Stage 12 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.