skills/anotb/management-consulting-plugin/implementation-planning

implementation-planning

Installation
SKILL.md

Implementation Planning

Translate strategic recommendations into concrete, funded, governed plans that organizations can actually execute. This covers translating strategy into executable plans across four connected stages: generating and evaluating options, building the business case, designing the roadmap, and developing the implementation plan. For the ongoing oversight structure (steering committees, status reporting, risk management), see project-governance.


The Strategy-to-Execution Arc

Most strategies fail in execution, not in formulation. The gap between "we should do X" and "X is happening" is where most value gets destroyed. This skill covers that gap systematically.

The four stages flow naturally but don't always run sequentially. Sometimes you start with options because the path isn't clear. Sometimes the recommendation is already made and you need to jump straight to business case and planning. Meet the work where it is.

  Strategic           Option            Business          Roadmap         Implementation
  Recommendation  →   Development   →   Case          →   Design      →   Plan
  "We should..."      "Here are         "Here's why        "Here's        "Here's exactly
                       the ways          it's worth it"      the order"     how we do it"
                       we could..."

Stage 1: Strategic Option Development

Before committing to a path, develop genuinely different options. Not three flavors of the same thing... structurally different approaches that represent real strategic choices.

Define the Decision

Clarify what's being decided before generating options.

  • The Question: What exactly needs to be decided? One sentence.
  • Current State: Where we are today, with data.
  • Desired State: Where we want to be.
  • Constraints: Budget limits, timeline requirements, organizational capacity, regulatory boundaries.
  • Success Criteria: What matters most in evaluating options, and how much each criterion matters relative to the others.

Define weighted evaluation criteria upfront:

Criterion Weight Definition of Success
[Criterion 1] X% [What "good" looks like]
[Criterion 2] X% [What "good" looks like]
[Criterion 3] X% [What "good" looks like]
Total 100%

Generate Options

Create 3-5 genuinely differentiated options. Each should represent a distinct strategic posture, not just incremental variations. Always include "do nothing" as a baseline.

For each option:

  • Name and description: What this option entails in plain language
  • Approach: The key moves and sequencing
  • Pros and cons: Honest assessment, not a sales pitch
  • Resource requirements: Investment, timeline, capabilities needed
  • Risk profile: What could go wrong, and how badly

Good option sets include a range: a conservative option, an aggressive option, and something in between. If all your options look similar, you haven't explored the space.

Evaluate Options

Score each option against the weighted criteria:

Criterion Weight Option A Option B Option C Do Nothing
[Criterion 1] X% [1-5] [1-5] [1-5] [1-5]
[Criterion 2] X% [1-5] [1-5] [1-5] [1-5]
[Criterion 3] X% [1-5] [1-5] [1-5] [1-5]
Weighted Score 100% X.X X.X X.X X.X

Scoring guide:

  • 5 = Fully meets criterion
  • 4 = Substantially meets criterion
  • 3 = Partially meets criterion
  • 2 = Minimally meets criterion
  • 1 = Does not meet criterion

Beyond the quantitative scoring, assess each option qualitatively:

  • Strategic fit: How well does it align with broader organizational direction?
  • Feasibility: Can this organization actually pull this off?
  • Stakeholder support: Will the people who matter get behind it?
  • Reversibility: How hard is it to course-correct if this doesn't work?

Scenario-Test the Recommendation

Stress-test the leading option under different conditions. At minimum, test against optimistic, base, and pessimistic scenarios.

Option Optimistic Base Pessimistic
Option A [Performance] [Performance] [Performance]
Option B [Performance] [Performance] [Performance]

Run sensitivity analysis on criteria weights: which criteria, if weighted differently, would change the recommendation? If a small shift in weights flips the answer, the decision is closer than it looks.

Make the Recommendation

State it clearly. A recommendation has:

  1. The choice: Which option, stated without hedging
  2. The rationale: Why this option, grounded in the evaluation
  3. The trade-offs: What you're giving up, and why that's acceptable
  4. The fallback: If this option becomes infeasible, what's the next-best alternative
  5. Immediate next steps: What happens right now to move forward

Stage 2: Business Case

The business case answers one question: is this worth doing? It must convince decision-makers to fund the initiative and provide the financial framework for tracking value delivery.

Structure the Case

A business case that works has these sections, roughly in this order:

  1. Executive Summary (stands alone, one page max)
  2. Problem Statement and Cost of Inaction
  3. Current State with Baseline Metrics
  4. Proposed Solution and Future State
  5. Financial Analysis
  6. Implementation Overview
  7. Risks and Mitigations
  8. Recommendation

Executive Summary

This is the decision brief. Many stakeholders will read nothing else. It must contain the problem, the solution, the investment required, the expected return, and a clear recommendation.

  • The Challenge: 1-2 sentences on the problem
  • The Opportunity: What we can achieve
  • The Investment: Total capital and operating cost
  • The Return: NPV, IRR, payback period, ROI
  • The Recommendation: Proceed / Do not proceed / Proceed with conditions

Problem Statement and Cost of Inaction

Quantify the problem. "We're losing money" is not a problem statement. "We're losing $4.2M annually in customer churn driven by post-sale service failures" is.

Pain Point Annual Impact Frequency Trend
[Pain 1] $[Amount] [How often] [Getting better/worse]
[Pain 2] $[Amount] [How often] [Getting better/worse]

Calculate the cost of inaction explicitly. What happens over 3-5 years if we do nothing? This is the baseline against which the investment is compared.

Cost of Inaction Year 1 Year 2 Year 3 Cumulative
[Cost driver 1] $X $X $X $X
[Cost driver 2] $X $X $X $X
Total $X $X $X $X

Current State Baseline

Establish measurable baselines. You can't show improvement without a starting point.

Metric Current Value Industry Benchmark Gap
[Metric 1] [Value] [Benchmark] [Gap]
[Metric 2] [Value] [Benchmark] [Gap]

Financial Analysis

This is the core of the business case. Build it in layers:

Investment Required (what we're spending):

Category Year 0 Year 1 Year 2 Year 3 Total
Capital expenditure $X $X $X $X $X
Implementation costs $X $X $X
Change management $X $X $X
Training $X $X $X
Contingency (10-15%) $X $X $X $X $X
Total Investment $X $X $X $X $X

Benefits Realization (what we're getting back):

Benefit Type Year 1 Year 2 Year 3 Total
[Revenue benefit] Top-line $X $X $X $X
[Cost reduction] Bottom-line $X $X $X $X
[Risk avoidance] Quantified risk $X $X $X $X
[Productivity gain] Efficiency $X $X $X $X
Total Benefits $X $X $X $X

Return Metrics:

Metric Value Hurdle Rate Assessment
NPV $XX > $0 [Pass/Fail]
IRR XX% [Org hurdle] [Pass/Fail]
Payback Period X years [Org threshold] [Pass/Fail]
ROI XX% [Org threshold] [Pass/Fail]

Sensitivity Analysis (how robust are these numbers):

Variable -20% Base Case +20% Swing
Benefits realization $XX $XX $XX $XX
Cost overrun $XX $XX $XX $XX
Timeline delay $XX $XX $XX $XX
Adoption rate $XX $XX $XX $XX

Which variables have the biggest swing? That's where management attention should focus.

Total Cost of Ownership (the real long-term cost):

Component Years 1-3 Years 4-5 Years 6-10 Total
Initial investment $X $X
Ongoing licensing/ops $X $X $X $X
Maintenance $X $X $X $X
Training & support $X $X $X $X
TCO $X $X $X $X

Risk Assessment

Risk Likelihood Impact Mitigation Residual Risk
[Risk 1] [H/M/L] [H/M/L] [What we'll do] [After mitigation]
[Risk 2] [H/M/L] [H/M/L] [What we'll do] [After mitigation]

Stage 3: Roadmap Design

The roadmap answers: what happens when, and in what order? It translates the approved business case into a sequenced plan with phases, milestones, and dependencies.

Define the Planning Horizon

  • Time horizon: 1 year, 3 years, 5 years (match to initiative scope)
  • Number of phases: Typically 3-4 (more phases means less clarity per phase)
  • Phase logic: What drives the sequencing? Dependencies, risk reduction, value delivery, organizational readiness?

Design Phase Structure

Each phase needs a clear objective, a reason it comes in this order, and criteria for moving to the next phase.

## Phase 1: [Name] ([Duration])

### Objective
[What this phase achieves and why it comes first]

### Key Initiatives
| Initiative | Description | Priority | Dependencies |
|------------|-------------|----------|--------------|
| [Initiative 1] | [What it involves] | [High/Med] | [What must come first] |
| [Initiative 2] | [What it involves] | [High/Med] | [What must come first] |

### Deliverables
- [Concrete deliverable 1]
- [Concrete deliverable 2]

### Success Criteria
| Criterion | Target | How Measured |
|-----------|--------|-------------|
| [Criterion 1] | [Specific target] | [Measurement method] |
| [Criterion 2] | [Specific target] | [Measurement method] |

Repeat for each phase. Common phase patterns:

  • Foundation / Build / Scale: When you need infrastructure before you can build, and proof before you can scale
  • Quick Wins / Core Transformation / Optimization: When early momentum matters for stakeholder buy-in
  • Design / Pilot / Rollout: When uncertainty is high and you need to test before committing

Map Dependencies

Dependencies drive the critical path. Map them explicitly:

Critical Dependencies (delay here delays everything):

Initiative Depends On Impact if Delayed Mitigation
[Initiative] [Predecessor] [What breaks] [What we'll do]

Resource Dependencies (shared resources across workstreams):

  • [Which teams/people are shared across initiatives]

External Dependencies (things outside your control):

  • [Vendor deliveries, regulatory approvals, market conditions]

Milestone Planning

Define the milestones that mark real progress (not just calendar dates):

Milestone Target Date Phase Success Criteria Dependencies
M1 [Date] Phase 1 [How we know we're there] [What must be done]
M2 [Date] Phase 1 [How we know we're there] [M1]
M3 [Date] Phase 2 [How we know we're there] [M2]

Good milestones are:

  • Observable (you can tell whether they happened)
  • Meaningful (they represent real progress, not just elapsed time)
  • Decision-relevant (they inform go/no-go choices)

Resource Requirements by Phase

Resource Category Phase 1 Phase 2 Phase 3 Total
FTEs X X X X
Capital $X $X $X $X
Operating $X $X $X $X

Stage 4: Implementation Plan

The implementation plan is the most granular level. It translates the roadmap into workstreams with named owners, specific deliverables, and governance mechanisms.

Define Workstreams

Break the implementation into logical workstreams. Each workstream should be:

  • Independently manageable (one lead, clear scope)
  • Small enough to track (2-4 week deliverable cycles)
  • Large enough to be meaningful (not task lists)
Workstream Description Lead Key Deliverables Dependencies
[WS 1] [What it covers] [Name] [Deliverables] [Other WS]
[WS 2] [What it covers] [Name] [Deliverables] [Other WS]
[WS 3] [What it covers] [Name] [Deliverables] [Other WS]

Develop Detailed Timeline

Build the timeline phase by phase with milestones and owners:

## Phase 1: [Name] ([Duration])
Objective: [What we achieve]

| Milestone | Target | Dependencies | Owner |
|-----------|--------|--------------|-------|
| [M1] | [Date] | [None] | [Name] |
| [M2] | [Date] | [M1] | [Name] |

## Phase 2: [Name] ([Duration])
Objective: [What we achieve]

| Milestone | Target | Dependencies | Owner |
|-----------|--------|--------------|-------|
| [M3] | [Date] | [M2] | [Name] |
| [M4] | [Date] | [M3] | [Name] |

Critical Path

Identify the longest dependency chain that drives the overall timeline:

  • [Activity A] -> [Activity B] -> [Activity C] -> [Final milestone]
  • Any delay on the critical path directly delays the project end date
  • Non-critical activities have float. Quantify it for each so you know where you have slack

RACI Matrix

Define who does what. One accountable owner per deliverable. Shared accountability means no accountability.

Activity / Deliverable Sponsor Program Lead WS Lead Team Client SMEs
[Deliverable 1] A R C I C
[Deliverable 2] I A R R C
[Key decision] A R C I I
  • R = Responsible (does the work)
  • A = Accountable (one per activity, owns the outcome)
  • C = Consulted (input before the decision)
  • I = Informed (told after the decision)

Rules: One "A" per activity. At least one "R". Minimize "C" to avoid bottlenecks. "A" and "I" should not be the same person for the same activity.

Resource Allocation

Role Workstream FTE Duration Skills Required
[Role 1] [WS 1] X.X [Time] [Skills]
[Role 2] [WS 2] X.X [Time] [Skills]

Budget by workstream:

Workstream Labor External Other Total
[WS 1] $X $X $X $X
[WS 2] $X $X $X $X
Contingency (10-15%) $X
Total $X $X $X $X

Governance Structure

Meeting Cadence:

Forum Frequency Attendees Purpose Duration
Steering Committee Bi-weekly Sponsor, Program Lead, WS Leads Decisions, escalations 60 min
Program Review Weekly Program Lead, WS Leads Progress, risks, dependencies 45 min
Workstream Standup 2-3x/week WS Lead, Team Task coordination, blockers 15 min

Phase Gates (prevent premature transitions):

Gate Transition Entry Criteria Exit Criteria Approver
G1 Foundation -> Build [Requirements defined, team staffed] [Assessment complete, design approved] [Sponsor]
G2 Build -> Deploy [Solutions developed, tested] [Pilot successful, rollout plan approved] [Sponsor]
G3 Deploy -> Operate [Full rollout complete] [Adoption targets met, handover done] [Sponsor]

Escalation Path:

  • Level 1: WS Lead resolves within 24 hours
  • Level 2: Program Lead resolves within 48 hours
  • Level 3: Steering Committee resolves at next meeting (or emergency session)

Change Control:

Change Type Approval Required Process
Minor scope change Program Lead Document, assess impact, approve/reject
Major scope change Steering Committee Formal change request, impact analysis, SteerCo decision
Timeline shift (< 2 weeks) Program Lead Update plan, notify stakeholders
Timeline shift (> 2 weeks) Steering Committee Root cause analysis, recovery plan, SteerCo approval
Budget variance (< 10%) Program Lead Document, adjust within contingency
Budget variance (> 10%) Steering Committee Business case for additional funding

Risk and Contingency

Risk Impact Probability Mitigation Owner
[Risk 1] [H/M/L] [H/M/L] [Specific action] [Name]
[Risk 2] [H/M/L] [H/M/L] [Specific action] [Name]

Contingency plans for high-impact risks:

  • If [trigger condition], then [specific response]
  • If [trigger condition], then [specific response]

Working Across Stages

When to Start Where

Not every engagement needs all four stages. Match the entry point to the situation:

Situation Start At Skip
Decision not yet made, multiple paths possible Stage 1 (Options) Nothing
Recommendation exists, needs funding approval Stage 2 (Business Case) Stage 1
Approved and funded, needs execution plan Stage 3 (Roadmap) Stages 1-2
Roadmap exists, needs operational detail Stage 4 (Implementation) Stages 1-3
Existing plan needs restructuring Diagnose first, then appropriate stage Depends

Connecting the Stages

Each stage feeds the next:

  • Options -> Business Case: The recommended option becomes the "proposed solution" in the business case. Option evaluation criteria inform risk assessment.
  • Business Case -> Roadmap: Approved investment envelope constrains the roadmap. Benefits realization timeline shapes phasing.
  • Roadmap -> Implementation Plan: Phase structure becomes the implementation timeline. Milestones become governance checkpoints.

Information That Flows Forward

From To What Carries Over
Options Business Case Recommended option, investment estimate, risk profile, trade-offs accepted
Business Case Roadmap Approved budget, benefits timeline, key risks, success metrics
Roadmap Implementation Phase structure, milestones, dependencies, resource envelope

Key Principles

  • Quantify everything. "Significant savings" convinces no one. "$4.2M annually" does.
  • Be honest about trade-offs. Every option has downsides. Hiding them destroys credibility.
  • One accountable owner per deliverable. Shared accountability is no accountability.
  • The executive summary must stand alone. It's often the only thing that gets read.
  • Build in contingency. 10-15% on both timeline and budget. Things will go wrong.
  • Include quick wins early. They build momentum and stakeholder confidence.
  • The critical path drives everything. Know it, protect it, track it.
  • Phase gates prevent premature transitions. Enforce them even when there's pressure to move faster.
  • A roadmap is a living document. Review and update regularly.
  • Match ambition to organizational capacity. An aggressive plan that an organization can't absorb is worse than a modest plan it can execute.
  • Always include "do nothing" as a baseline. It forces honest comparison.
  • Connect every initiative to a strategic objective. If you can't, question why it's in the plan.
Weekly Installs
2
GitHub Stars
20
First Seen
Mar 22, 2026