implementation-planning
Bridge strategy to execution through structured option development, business case construction, roadmap design, and implementation planning. Use when translating a strategic recommendation into an investable, executable plan... covering option generation and scoring, financial pr
What it does
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:
- The choice: Which option, stated without hedging
- The rationale: Why this option, grounded in the evaluation
- The trade-offs: What you're giving up, and why that's acceptable
- The fallback: If this option becomes infeasible, what's the next-best alternative
- 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:
- Executive Summary (stands alone, one page max)
- Problem Statement and Cost of Inaction
- Current State with Baseline Metrics
- Proposed Solution and Future State
- Financial Analysis
- Implementation Overview
- Risks and Mitigations
- 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.
Capabilities
Install
Quality
deterministic score 0.46 from registry signals: · indexed on github topic:agent-skills · 22 github stars · SKILL.md body (20,591 chars)