Implementation Plan 🗺️
Translating the diagnosis into a 12-week roadmap.
If the Audit 🔍 stage was what's actually true here?, this stage is what are we going to do about it, and where will it live? You walk in with a notebook of audit findings and a pre-engagement Why Asana statement. You walk out with a tree-shaped map of the organisation, a first-pass list of in-scope processes with named owners, the workspace's shell already built by your team, and a written Work Management Change Plan that defines what success will look like at the end of the project.
In this document
Asana Demo — inspire, don't teach
Organisation Mapping — from list to tree
Organisation Structure Discussion — refining the tree, owning the workspace
The Work Management Change Plan
What to prepare before this stage
What you get with the full protocol
1️⃣ What happens at this stage
This stage has three meetings and one document.
🎯 Meeting 1 — Asana Demo. A 60–90 minute working session where the Change Leaders see the platform for the first time inside their problem. Not a feature tour. A storytelling demo, shaped by the Why Asana statement and the two top problems the audit surfaced.
🎯 Meeting 2 — Organisation Mapping Workshop. A facilitated workshop on a visual canvas (Miro / FigJam / Mural — pick whichever your team already uses). The Change Leaders move the organisation from a list of teams and processes to a tree — first individually, then as a group.
🎯 Meeting 3 — Organisation Structure Discussion. A presentation-and-discussion meeting where you bring back a refined tree, walk through it process by process, name owners, and confirm who builds what in the platform. By the end of this meeting, the workspace shell exists.
⚠️ The document — Work Management Change Plan. Not a meeting. A first version is written at the close of this stage, drawing on every piece of data gathered since Discovery. It's the spine of every stage that follows.
Note on naming (Sponsor, Guardian, Change Leaders) — click to reveal
These roles were formally appointed at the
Kick-off 🏈 stage and keep their titles for the rest of the Protocol.
At this stage, the Sponsor stays in the background and signs off on scope; the Guardian owns prep and chases attendance; the Change Leaders are the primary participants and will own the resulting structure inside their teams.
2️⃣ Asana Demo — inspire, don't teach
The single most important sentence in this stage: the demo is here to inspire people, not to teach them how to use the platform.
The team will get formal training at the Training 🧑🏫 stage. Right now, they need a reason to want it. The demo's job is to make a Change Leader leave the meeting thinking "I can see how my team's worst week would look different inside this." If they leave thinking "I now know how to set up custom fields," the demo has failed and the Training 🧑🏫 stage has just been pre-emptively flattened.
How a useful demo is shaped
A demo this early in the engagement only earns its hour if it's anchored to their situation. Three inputs do that anchoring:
- The Why Asana statement — the one-sentence answer to "why are we doing this at all?" that was agreed in pre-engagement. The demo opens by restating it.
- The two top problems from the audit — pick two. Not seven. Two problems the Change Leaders said out loud at Stage 4. The demo shows how the platform handles those two problems specifically.
- The closest matching use case — most teams' problems land in one of a small number of common patterns (cross-functional project tracking, intake-and-prioritisation, team standups, client-facing work). Pick the one closest to their day-to-day and use the matching project blueprint as the canvas.
What the demo actually walks through
A useful demo, in roughly this order:
- The frame: bad habits are the result of bad systems. We don't rise to the level of our goals; we fall to the level of our systems. The platform isn't a behaviour-change tool. It's a system change that makes the behaviours follow.
- A short before / after contrast. Where their work lives today (email, chat, spreadsheets, status meetings, the Slack channel that became a system) vs. where it could live tomorrow.
- Three types of activity, three platform features. Collect — how a workflow turns intake into structured tasks. Organize — how "My Tasks" sorts the work an individual owns. Track — how the inbox and dashboards make progress visible without a status meeting.
- One advanced view per role. A view a Change Leader can see themselves living inside a week from now.
That's the whole shape. Anything past it is teaching, and teaching is the Training 🧑🏫 stage's job.
The line that lands
💬"You're not going to learn the platform today. You're going to see whether the way it works could change the way your team works. If the answer is yes, we'll teach you properly later — together."
3️⃣ Organisation Mapping — from list to tree
Most organisations think they know their structure. They have an org chart. They have a list of teams. Some have a RACI matrix. None of those documents tell you how the work flows — which is what the platform's information architecture has to mirror.
The Organisation Mapping Workshop closes that gap.
The workshop's two halves
The workshop is built around a deliberate progression: individual mapping first, group mapping second.
🎯 Individual mapping — each Change Leader, working solo on the canvas, places sticky notes for the teams they interact with and the processes they run, then draws lines between processes and the teams that touch them. No discussion. Twenty minutes of quiet, parallel work.
🎯 Group mapping — the room then merges the individual maps into a single shared map. This is where the friction surfaces. Two people mapped the same process under different names. One Change Leader didn't realise another team was in the chain. The "official" team list and the "actual" team list diverge in three places.
From the map to a tree
After the workshop, you take the merged map away and convert it into a tree structure — your work-management platform's information architecture, drawn before it gets built. The tree has three layers:
- Top — divisions or major business areas (whatever the organisation already calls them).
- Middle — teams (sometimes a 1:1 with the division, sometimes 2–3 teams under one division).
- Bottom — projects (one project per process, or several projects per process if the process is intake-heavy or has a distinct outcome at each stage).
External contractors and embedded specialists get their own block on the side, with lines drawn to the processes they sit inside.
What's reusable here
The platform-agnostic version of this exercise is the part you can lift to any tool: list → individual map → group map → tree → information architecture. The tree-to-Asana translation is the part that's specific to the chosen platform.
4️⃣ Organisation Structure Discussion — refining the tree, owning the workspace
The third meeting brings the refined tree back to the Change Leaders. The format is presentation first, discussion second.
You start by recapping where the workshop left off so the room can feel the through-line. Then you walk the tree process by process, asking three questions per process:
- Where does this process belong? A project under team A, or a cross-team project, or two projects (intake and delivery) that talk to each other?
- Who is the primary owner? Not "who manages it" — who is accountable when nobody else is sure what to do? In our experience, naming the wrong owner here is more expensive than leaving the slot blank for two weeks and naming the right one later.
- What are the relationships? Which other processes feed this one or feed off it? These dependencies become the basis for cross-project linking later in the Protocol.
Comments and edits land on the tree in the meeting itself, not in a follow-up email.
Who builds the workspace?
The single most consequential decision of the meeting is the client builds the workspace, not the coach. The team that owns the structure is the team that built it. If your facilitator (or an external party) clicks the "Create team" buttons, the team will treat the workspace like furniture you delivered — and the day they want to rearrange a room, they'll wait for you to come back.
🧰 The right pattern: a short Loom video of "how to create a team and a project, and how to add members." The Guardian distributes the video. The Change Leaders create the empty teams and projects between meetings. Mistakes are fine — encourage them. They become questions for the next session, and questions are how the team learns the platform's grain.
Where the schedule lands
This meeting is also where the must-have implementation meetings for Stage Mapping & Implementing Workflows 🛠️ – Change Alliance 👥 land in calendars. Not pencilled-in, not "we'll find a time" — booked.
5️⃣ The Work Management Change Plan
The Work Management Change Plan is the document that defines what success looks like for this engagement before the engagement gets underway.
It's the synthesis of everything you've gathered since Discovery — pre-engagement findings, the Why Asana statement workshop, the audit, and now the mapping workshop. It names what should change, in five categories: behaviours, challenges, skills, conventions, and key activities to move into the platform. And it draws a line through that list — what's in scope for the next 60–90 days, what isn't.
Why the document exists
The honest reason: without a written change plan, "did this transformation work?" becomes a vibe at the end of the engagement. With a written change plan, it's a comparison.
The strategic reason: the parts that aren't in scope are the upsell. Not because the project is artificially small, but because every transformation surfaces more problems than 60 days can address. The plan separates "what we're going to fix this quarter" from "what we should fix together next." Marked with a 🌱 in the document, the second list becomes the natural conversation at the Business Impact Review 📈 stage.
The framing rule
The plan is written in the voice of systems, not people. The opening frame:
💬 "Bad habits are the result of bad systems. We don't rise to the level of our goals; we fall to the level of our systems. We're going to change the systems — the platform, the conventions, the cadence — so that better habits follow naturally."
This isn't softening. It's accurate. People who feel personally blamed for the current state defend it. Teams who can locate the problem in the system around them step toward changing it.
How the document moves through the project
Stage 5 produces the first version. The plan is then circulated to the team for buy-in before implementation begins — reviewed by the full Change Leader group, edited, and re-issued.
After that, the plan is updated three times across the project: once after the Work Conventions 🤝 stage when the rules of cooperation are written down, once after Launch when reality has met the plan, and once at the Business Impact Review 📈 stage when the impact review is being prepared. Each update is what keeps the document honest.
6️⃣ Where teams stall
‼️ The demo turns into training. You start showing a feature, someone asks a follow-up, you answer it well, and ninety minutes later half the room has glazed over and the other half is taking notes on custom fields. The damage isn't just the meeting — the Training 🧑🏫 stage's training feels redundant when it arrives, and adoption gets the worst of both worlds. Hold the line: we're showing you, not teaching you. If a question requires a five-minute answer, defer it to a Loom or to the Training 🧑🏫 stage.
‼️ The mapping workshop runs straight into group mode. Twenty minutes of quiet individual mapping is the cheapest piece of this stage and the one most often skipped "to keep things moving." It's also the one that surfaces the divergences that matter. Don't skip it because the room will be impatient — they'll thank you when the merged map shows them something they didn't already know.
‼️ The tree has projects but no owners. A workspace where every project shows "—" in the owner field is a workspace where nobody's accountable for anything. This usually happens when the Organisation Structure Discussion meeting runs out of time and ownership questions get punted. It's better to extend the meeting by thirty minutes than to leave the meeting with un-owned projects. In our experience, un-owned projects at this stage become uninhabited projects at the Onboarding 👋 stage.
‼️ The coach (or external party) builds the workspace. The single most expensive shortcut in the Protocol. Your team did not move into a house someone else furnished — they moved into a room they helped build. If the Change Leaders haven't clicked the "Create team" button at least once before the Mapping & Implementing Workflows 🛠️ stage, adoption at Launch will be 20–30 percentage points lower than it should have been.
‼️ Scope creep on the tree. "While we're here, let's also map our finance process and our two product lines and the new initiative." The proposal scoped a specific number of processes for capacity and pricing reasons. Mapping more on the tree without re-scoping the project means you'll either run out of time at Stage 6 or you'll deliver a tree the project can't afford to implement. Keep the unmapped processes on a 🌱 list — they belong in the Change Plan upsell, not in this quarter's scope.
‼️ The Change Plan is written but never circulated for buy-in. A plan the team didn't see before implementation feels like a verdict, not a contract. Circulate the first version. Take edits seriously. Re-issue. Bringing this to your CFO: "The buy-in step costs us five days of asynchronous review. It saves us roughly a month of resistance during Stages 6–9 — that's the difference between adoption that holds and adoption that needs constant reinforcement."
7️⃣ What to prepare before this stage
- The audit's headline findings, distilled to two top problems. The demo will be shaped around these. If you don't know what the two problems are, you don't have the audit closed out yet — finish the Audit 🔍 stage first.
- The Why Asana statement, reviewed and current. A pre-engagement deliverable. Re-read it; if it no longer matches what the audit revealed, edit it before the demo.
- A working visual canvas. Miro, FigJam, Mural, a wall of stickies in a war room. Whatever the Change Leaders will actually use. The mapping workshop happens here, the tree gets built here, and the comments live here for the rest of the stage.
- A list of the organisation's teams, departments, and in-progress processes. Pulled from HR, from existing project trackers, from the audit notes — usually a mix. The mapping workshop starts with this list pasted onto the canvas.
- A RACI matrix, if one exists. Not required. Useful when present — a RACI translates cleanly into project-level ownership in the platform's information architecture.
- A short Loom (or equivalent) showing how to create teams and projects in the platform. The clients will use this between Meeting 3 and the Mapping & Implementing Workflows 🛠️ stage to build the workspace shell themselves.
- Calendar runway for Stage Mapping & Implementing Workflows 🛠️ – Change Alliance 👥. The must-have implementation meetings should be bookable in calendars by the end of Meeting 3. If half the Change Leaders are in vacation conflicts for the next four weeks, you'll surface it now and re-plan, not in three weeks at the start of the Mapping & Implementing Workflows 🛠️ stage.
⚠️ If three or more of these are missing, run Stage 5 anyway — but treat the first meeting as a working session to fill them in, and accept that the rest of the stage moves a week later than planned.
✅ What you get with the full protocol
The full Reliability Protocol is delivered as a sequence of weekly emails. 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 and Change Leaders) can act on at the pace your organisation can sustain. The artifacts you get for this stage:
- The Asana Demo script — the inspiration-not-training shape, with the line-that-lands, anchored to your two top problems and the closest matching use case.
- The Organisation Mapping Workshop runbook — the individual-first, group-second sequence, the canvas template, and the list-to-tree conversion notes.
- The Organisation Structure Discussion agenda — the three questions per process, the workspace-build handoff (with the Loom template), and the Stage 6–8 calendar block.
- The Work Management Change Plan template — the five categories, the buy-in protocol, the 🌱 upsell-marker convention, and the three update milestones across the project.
- The "client builds the workspace" Loom template — what to record, how long, and what to leave out so the team can act without you in the room.
💬 Take this with you and your Change Leaders can run the implementation plan themselves. Hit a wall — especially on the tree or the Change Plan — and want a partner — book the session below.
When to bring in a partner
The package above is what we use to run this stage ourselves. Many operators run it themselves. Bring in a partner when:
- The Asana Demo needs platform fluency you don't have yet. Inspiring without teaching is a craft — book a partner for Meeting 1 even if you run Meetings 2 and 3 yourselves.
- The tree won't settle. Two Change Leaders see the org structure differently and neither will yield. An outside facilitator names the disagreement and writes the resolution into the Change Plan.
- The Change Plan needs to be defensible to the CFO. A partner-co-authored plan with the upsell list ( 🌱 ) and ROI markers travels further inside your org than a draft from the team running the project.
If any of those land, the Reliability Diagnostic below is the lightest possible engagement — 60 minutes, no commitment beyond the session.
💡 This is Stage 5 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.