Approval is not the finish line; it is the starting gun. From here, the question shifts from “Should we do this?” to “Are we doing what we said, at the pace we promised, and are the benefits actually landing?” This chapter lays out how to mobilize in the first 90 days, track benefits, manage variance, control changes and re-baselining, and close the loop with a disciplined post-implementation review.
22.1 Day 0–30–90 Mobilization Plan
Once the decision is taken and funding is approved, the most effective teams operate with a simple Day 0–30–90 frame. It ensures momentum without chaos.
Day 0: Immediately after approval (first 48 hours)
Your objectives in this window are clarity, alignment, and ownership.
Core actions:
- Confirm the decision and conditions in writing
- Decision, selected option, funding envelope and tranches.
- Any conditions (extra controls, additional assurance, scope limits, reporting commitments).
- Lock the “source of truth”
- Approved business case version.
- Approved model (decision version).
- Approved benefits register and risk register.
- Name and confirm key roles
- Sponsor and initiative/program lead.
- Workstream leads (Tech, Ops, Data, Change, Risk, etc.).
- PMO role (if scale justifies).
- Communicate the decision to the core team
- What was approved and why.
- What changes, and what does not.
- Immediate next steps and expectations.
Day 0 is about removing ambiguity. Everyone should know “this is real” and “this is what we’re doing.”
Day 1–30: Mobilization and detailed planning
In the first month, you shift from the high-level roadmap in the case to an executable plan.
Key priorities:
- Stand up governance
- Schedule steering committee cadence (e.g., monthly).
- Schedule working-level meetings for each workstream.
- Confirm decision rights for scope, budget variances, and design choices.
- Refine the roadmap into a delivery plan
- Translate phases into detailed milestones and activities.
- Reconfirm dependencies and critical path.
- Validate resource plans against actual availability; secure backfills and vendor slots.
- Operationalize benefits and KPIs
- Validate baselines with finance and benefit owners.
- Lock targets by period and confirm measurement mechanisms.
- Design or configure the benefits dashboard skeleton.
- Launch critical enablers
- Initiate procurement steps if contracts are not yet signed.
- Kick off key design and discovery streams (process, data, architecture).
- Start any regulatory/security reviews that are long-lead items.
- Change, comms, and stakeholder engagement
- Map impacted groups in more detail.
- Launch initial communications: why we’re doing this, what to expect, and how they can engage.
- Identify and briefly change champions or local leads.
At the end of 30 days, you want a realistic, agreed plan, not the “PowerPoint plan” from the case.
Day 31–90: Execution discipline and early proof points
The second and third months focus on demonstrating progress and de-risking the biggest uncertainties.
Focus areas:
- Hit the first real milestones
- Complete detailed design or blueprint.
- Lock vendor contracts and SOWs.
- Stand up project environments or pilots.
- Run experiments and pilots where planned
- Execute pilots that test critical assumptions (adoption, productivity, stability).
- Collect data, compare to baseline, refine economics and design.
- Start measuring leading indicators
- Adoption, cycle times, quality metrics in pilot zones or early releases.
- Use these to validate or update your benefits model.
- Build operating rhythm
- Regularly review progress against the plan (schedule, cost, risk, benefits).
- Use steering committees to unblock decisions quickly.
- Use working sessions to solve issues, not just report status.
- Prepare for Gate 1 / scale decisions (if you work with stage gates)
- Package pilot results and early risk evidence.
- Confirm readiness against gate exit criteria.
- Propose any re-phasing, scope trimming, or additional mitigation needed.
By Day 90, executives should see evidence that the initiative is under control and on a credible path to value—not just “good intentions.”
22.2 Benefits Tracking and Variance Management
Once you move into execution, your benefits case becomes a living forecast, not a static promise. You must treat benefits tracking with the same seriousness as budget tracking.
Designing benefits tracking in practice
You already defined KPIs, baselines, and targets earlier; now you operationalize:
- Benefits register as the canonical list
- Benefit ID, description, owner, formula, baseline, targets, ramp profile, and data source.
- Tagged by theme (revenue, cost, risk, customer, ESG).
- Dashboard as the view, not the source
- The underlying sources are operational systems and validated data sets.
- The dashboard pulls from those, aggregates, and shows performance vs plan.
- Cadence and integration with existing reviews
- For large initiatives: monthly benefit updates in steering, quarterly in BU or portfolio reviews.
- Use the same KPIs and numbers across project reporting and BAU performance reviews.
Variance management: when actuals diverge from the case
Variances will happen. The key is how quickly you see them and what you do.
Good practices:
- Set variance thresholds up front
- For example:
- Green: within ±10% vs plan.
- Amber: 10–20% off for more than one period; requires mitigation plan.
- Red: >20% off or structural deviation; requires sponsor-level decision.
- For example:
- Diagnose variances, don’t just report them
- Decompose the variance into drivers (e.g., lower adoption, slower ramp, operational issues, macro changes).
- Identify which parts are within your control vs external.
- Respond proportionately
- For contained, tactical variances: local mitigations (e.g., additional training, targeted marketing, process tweaks).
- For structural variances: consider revising the plan (scope, pace, or even stopping some elements).
- Engage finance on whether forecast benefits (and sometimes costs) should be re-baselined.
Link to funding and gates
If benefits are lagging and risk is rising, funding releases at upcoming gates should not be automatic:
- Use benefit performance in gate decisions:
- “We will release the next tranche only if these early KPIs are within tolerance.”
- Be explicit when recommending to proceed, pause, or pivot based on benefit evidence.
22.3 Change Control and Re-Baselining
No initiative goes exactly to plan. Change control and re-baselining mechanisms let you adapt without losing discipline or rewriting history.
Change control: what it is and why it matters
Change control is the process by which you:
- Propose changes to scope, timing, or budget.
- Assess their impact on economics, risk, and benefits.
- Decide whether to accept, reject, or defer them.
- Document decisions for auditability and future learning.
Without it, you get silent scope creep, hidden cost growth, and benefits that “somehow” never show up.
Typical change categories
- Scope changes
- Additions (new features, geographies, processes).
- Deletions (dropping a workstream or feature).
- Timing changes
- Slips in key milestones or go-live dates.
- Extended pilots or parallel runs.
- Cost changes
- Vendor overruns, additional FTEs, new third-party services.
- Risk and control changes
- New controls mandated by risk or regulators.
- Additional security/privacy requirements.
Each change request should specify:
- The driver (new requirement, risk, dependency failure, external event).
- The impact: cost, benefits, risk, timing.
- Whether it is within existing tolerances or requires governance escalation.
Re-baselining: when and how
Re-baselining means updating the “official” plan and value case that you use for future comparisons.
You should consider re-baselining when:
- External conditions have changed materially (e.g., regulatory changes, major market shifts) and the original case assumptions are no longer realistic.
- Approved scope changes significantly alter cost or benefits.
- Pilot or early phases show structurally different performance than assumed, and management decides to continue based on the new reality.
Principles:
- Do not re-baseline to hide poor execution. Distinguish between “we mis-executed” and “the world changed.”
- Keep the original case as a reference. Re-baselining creates a new version, but you must be able to compare back to the original for learning.
- Decide at the right level. Board-approved cases typically require Board-level awareness or approval for major re-baselines.
Practically:
- Prepare a re-baseline memo summarizing old vs new assumptions and economics, what drove the change, and whether to adjust targets and funding.
Update all core artifacts: model, benefits register, roadmap, funding schedule, and dashboards.
22.4 Step-by-Step Benefits Realization Guide
Here’s a concrete sequence you can follow to manage benefits from approval through to BAU.
Step 1 – Confirm benefits owners and KPIs post-approval
Right after approval:
- Reconfirm benefit owners for each theme (names or at least roles).
- Walk through KPIs, baselines, and targets with each owner to ensure they are:
- Understandable.
- Measurable with existing or planned data.
- Embedded in their performance expectations.
If owners don’t believe the numbers or don’t see how they can influence them, fix that now.
Step 2 – Integrate benefits into governance
Embed benefits in:
- Steering committee agendas (standing section on “benefits and KPIs”).
- BU or function performance reviews, where benefit owners already appear.
- Portfolio reviews, so trade-offs between initiatives reflect both cost and realized value.
Ensure finance co-presents benefits performance where possible, to increase credibility.
Step 3 – Track early leading indicators
Before lagging financial outcomes show up:
- Monitor leading indicators tied to the initiative: adoption, usage, cycle time, quality metrics, early customer feedback.
- Compare these to the expected ramp profiles in your model.
This lets you see if you are “off the curve” early, not after a year.
Step 4 – Translate outcomes into financials
At agreed cadences (e.g., quarterly):
- Use the KPI movements to calculate actual financial impact vs baseline:
- For cost: hours saved × cost per hour, or units of spend avoided.
- For revenue: additional customers × ARPU × margin.
- For risk: reduction in expected loss or avoided incidents.
- Reconcile with P&L where possible:
- Ensure “spreadsheet savings” show up as reduced spend or avoided growth, not just productivity that gets re-absorbed.
Finance should validate the numbers and sign off on realized benefits, even if there is some model-based inference.
Step 5 – Diagnose and act on deviations
When benefits are off plan:
- Use benefit drivers to diagnose: adoption vs performance vs external conditions.
- Define specific corrective actions (e.g., targeted training, process redesign, marketing adjustment).
- Assign owners and timelines for those actions; track in governance like any other work.
For persistent shortfalls, escalate to:
- Consider re-prioritizing scope: focus on elements delivering value; pause or cancel weak components.
- Decide whether to update the forecast (re-baseline) to avoid clinging to unrealistic expectations.
Step 6 – Transition benefits management to BAU
As the initiative matures:
- Shift measurement responsibility from the project to BAU teams and finance.
- Reduce project-specific reporting; maintain KPIs in standard dashboards and scorecards.
- Keep a light-touch benefits review for a defined period (e.g., 2–3 years after go-live for major transformations).
Benefits realization becomes part of normal management, not an add-on.
22.5 Post-Implementation Review Checklist
A post-implementation review (PIR) is where you close the loop: Did we get what we promised? What did we learn for next time?
Timing: typically 6–18 months after major go-live, depending on ramp, sometimes with more than one review (e.g., interim and final).
Use this checklist to frame and structure the PIR.
Scope and objectives
- Is the original business case (vX.Y) clearly identified as the reference?
- Are the original objectives and success metrics restated at the start of the review?
- Is the timeframe for review (from–to dates) explicit?
Delivery performance
- Did we deliver the solution as scoped (features, geographies, processes)? If not, what changed and why?
- Were major milestones and go-lives achieved on time? If not, how large were the variances and what drove them?
- How did actual implementation costs compare to the business case (by major category and phase)?
Benefits and outcomes
- For each major benefit theme, are we showing:
- Actual KPIs vs baseline and vs target.
- Financial impact vs planned benefits (per year and cumulative)
- Are we distinguishing between realized, in progress, and not realized / cancelled benefits?
- Are risk/ESG/compliance outcomes evaluated, not just financials (where relevant)?
- Overall, what percentage of the promised NPV or equivalent has been realized or is on track?
Variance analysis
- Are we explicit about the main drivers of differences vs the original case:
- Demand/adoption.
- Operational performance.
- External environment (market, regulation, macro).
- Execution quality (design, build, change management).
- Do we separate “we were wrong about the world” from “we mis-executed”?
- Are there clear, quantifiable examples (e.g., “adoption reached 45% vs 70% plan; this explains ~$Xm of benefit gap”)?
Governance, risk, and controls
- Did the risk profile evolve as anticipated? Were major risks managed as planned?
- Were there significant incidents (outages, breaches, regulatory findings) related to the initiative?
- Did stage-gates and funding controls work as intended, or did approvals become rubber stamps?
Lessons learned
- Are we capturing specific, actionable lessons across:
- Demand/adoption.
- Operational performance.
- External environment (market, regulation, macro).
- Execution quality (design, build, change management).
- Are lessons framed as “next time, we will…” rather than vague reflections?
- Are we identifying patterns across multiple initiatives (if you are running a portfolio PIR)?
Decisions and follow-ups
- Are we deciding what to do with remaining scope (optimize, extend, or stop)?
- Are any re-baselines or re-forecasts being approved as part of the PIR?
- Are specific methodology or policy changes agreed (e.g., stronger pilot requirements, stricter change control, revised hurdle rates)?
- Is there ownership and a timeline for implementing these improvements?
If you treat post-implementation reviews as non-negotiable—rather than optional—you transform business cases from one-off persuasion documents into part of an institutional learning loop. Over time, assumptions get sharper, cases become more honest, and the organization gets better at turning approved PowerPoint into real-world results.
