implementation-planning

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.