Business Impact Review 📈
What changed, what didn't — and what's next.
This stage is the only stage that happens after the implementation project is over. It closed at the Operational handover 📦 stage — the partner left, the standing meetings ended. Which is exactly why it's the easiest stage to skip — there's no momentum carrying you into it, no one on the calendar to run it, and your team has moved on.
In this document
Why your transformation results were invisible when the project closed
Leading vs. lagging — what you measure, and when
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 as a single review, at least two months after the implementation project closed — once your team has had time to become genuinely fluent. There's one core deliverable: a business-impact readout for the Sponsor that answers the question they've been carrying since they signed the cheque — was it worth it? The narrative is simple, and it's only honest now:
Now that your team is fluent, here is the time and money you're saving.
That sentence couldn't be said when the project closed. At the Operational handover 📦 stage you proved the leading signals — the system is built, your team is using it, the data shows control. This stage proves the lagging result — the reclaimed hours, the meetings that stopped happening, the clarity that means work no longer stalls waiting on someone. Same Level 4 of the Kirkpatrick model; different half of it, measured at the only time it can be.
Note on naming (Sponsor, Guardian, Change Leaders, Change Alliance, Workflow Guardians) — click to reveal
Sponsor, Guardian, and Change Leaders were formally appointed at the
Kick-off 🏈 stage; the Change Alliance — including the Workflow Guardians — was named at the Change Alliance 👥 stage.
By this stage every role has been in place for months, and ownership of measurement transferred to your Guardian at the Operational handover 📦 stage.
Your job now isn't to introduce anyone new — it's to make sure the Guardian actually runs the deferred review now that the partner is gone.
2️⃣ Why your transformation results were invisible when the project closed
The single hardest thing to explain to a Sponsor is why you didn't hand them an ROI number on the last day of the project. The answer is that there wasn't one yet — and any number you'd produced would have been measuring the wrong month.
Change follows a curve. In the first month, productivity drops as people learn new ways of working together — this is the dip, and most of it is noise. Through months two and three the rituals start to stick and the chaos recedes. Only by around month four is the new system genuinely the source of truth, your team working on autopilot. Measure "time saved" during the dip and you'll prove the transformation made things worse. The lagging result has to be given time to exist before it can be measured.
This is a named principle, not a convenience. In Kirkpatrick's model it's "value must be created before it can be demonstrated" — you cannot show a business result that the team hasn't yet had time to produce. The deliberate two-month-plus gap isn't a delay in the project. It's the measurement working as designed.
3️⃣ Leading vs. lagging — what you measure, and when
Kirkpatrick describes one organisational result — the flag at the top of the mountain — reached through leading indicators, the little flags marching up that show you're on track before the summit result arrives. The Reliability Protocol measures that climb in a deliberate order across the last two stages:
- Adoption is behaviour, not a result. People logging in, posting updates, running their work inside the platform is on-the-job application — Kirkpatrick Level 3 (Behavior) . It's the precursor, not the prize. A team can be fully adopted and you still haven't proven a business outcome.
- Operational reliability is the leading indicator — measured at the Operational handover 📦 stage. Are deadlines being hit? Are status updates landing without being chased? Can work be delegated without chaos? These show up early and predict the business result. You took this snapshot when the project closed.
- The business result is the lagging indicator — measured now, at this stage. Reclaimed hours, status meetings that stopped happening, the clarity that means nobody's hunting through email to find out who owns what. This is the summit flag — and it only appears once your team is fluent.
There's a catch most teams hit here: you usually have no clean financial baseline. The client never tracked "hours lost to chasing status" before the transformation, so there's no clean old number to set the new one against.
The honest move — and the one Kirkpatrick prescribes — is not to fabricate one. It's to monitor the outcome over time and quantify it as the data accumulates.
What makes the result credible isn't a single number pulled from nowhere — it's the chain of evidence: the adoption you can see, the operational-reliability signals that were already climbing when the project closed, and now the business outcome landing on top of them, read against the expectations the Sponsor set at the start. Each link was measured in its own window; stacked together, they're a case a CFO accepts.
4️⃣ What to prepare before this stage
- The close-of-project snapshot is saved and findable — the operational-reliability reading you captured at the Operational handover 📦 stage. It's the link in the chain of evidence the business result builds on top of.
- A calendar trigger is set for at least two months after the project closes — the review does not schedule itself once the partner has gone. Set the reminder the week the project ends, not when you happen to remember.
- The Guardian still has access to the workspace data and dashboards — measurement ownership transferred at the Operational handover 📦 stage; make sure that access didn't lapse when the partner left.
- The Sponsor's original expectations are written down — what they said "good" looked like at Kick-off. Return on Expectations is measured against their stated expectation, not a generic benchmark.
- The lagging outcomes you'll ask about are agreed in advance — the categories you'll read (time reclaimed, meetings reduced, ownership clarity), confirmed with the Sponsor rather than improvised in the room.
5️⃣ Avoid this if you don't want your transformation to fail or delay
‼️ Don't measure too early. A business-impact reading taken in month one measures the dip, not the change — and proves the opposite of what's true. Wait until your team is fluent. The gap is the method, not procrastination.
‼️ Don't let the review go unscheduled. This is the one stage with no momentum behind it: the project's closed, the partner's gone, the meetings have stopped. If you don't set the trigger and own the date, the review quietly never happens and the result is never proven.
‼️ Don't fabricate an ROI number. A dollar figure you can't defend is worse than no figure — the first sceptical question collapses it. A credible chain of evidence (the close snapshot, the later delta, a teammate's story) beats a fabricated number every time. Report Return on Expectations, not ROI theatre.
‼️ Don't confuse adoption with results. "Everyone's using Asana" is a behaviour, not a business outcome. If the readout stops at adoption, the Sponsor still doesn't know whether the money bought anything. Push through to what the adoption produced .
‼️ Don't skip the close-of-project measurement. The business result lands far harder as the top of a chain — the operational-reliability signals you captured at the Operational handover 📦 stage are what it builds on. Skip that reading and the chain has a hole in it, with no way back to fill it.
‼️ Don't turn the readout into a sales call. The review earns trust precisely because it's an honest measurement, not a pitch. The number stands on its own; whatever comes next is a separate conversation, on the Sponsor's terms.
✅ 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 4-Month Reliability Maturity Map — the Installation → Calibration → Sustainability arc that tells you when each kind of result becomes measurable, so you read the business impact at the right month instead of measuring the dip.
- The Leading-vs-Lagging Measurement Framework — which signals to capture when the project closes versus which to capture at the later review, each mapped to its Kirkpatrick level so you always know what a number is actually proving.
- The Chain-of-Evidence Builder — how adoption (behaviour), operational reliability (leading), and the business outcome (lagging) stack into a single proof a Sponsor accepts — and how to present it without a clean financial baseline.
- The Sponsor Return-on-Expectations Readout — the structure for the business-impact conversation: how to frame the result against the expectations set at the start, and how to handle the no-baseline question. (The conversation script itself is part of the gated toolkit.)
💬 Take this with you and your team can run the Business Impact Review 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 have no clean baseline and the result is contested. When the Sponsor's expectation was fuzzy at the start, or the value is being questioned now, turning ambiguous dashboard data into a defensible delta is harder than it looks — partner-side pattern recognition across many transformations is what makes the number hold up.
- The review keeps slipping. This stage has no built-in momentum. If the date has already moved twice, a partner running the read on a fixed date is often the only way it actually happens before the window closes and the data goes stale.
- The result opens a bigger question. A strong result often surfaces the next thing worth doing — a sibling team, a deeper convention sprint. Deciding whether that's a real next cycle or a distraction is its own conversation, and a neutral partner helps you scope it honestly rather than drift into it.
💡 This is Stage 14 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.