Imported from abhishek2chikun/consulting_agents (backend/app/skills/implementation-planning/SKILL.md). Install upstream with npx skills add abhishek2chikun/consulting_agents --skill implementation-planning. Copyright stays with the author.

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:

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:

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.

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.

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.

Current State Baseline

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

Financial Analysis

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

Investment Required (what we're spending):

Benefits Realization (what we're getting back):

Return Metrics:

Sensitivity Analysis (how robust are these numbers):

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

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

Risk Assessment

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):

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):

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

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)

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.

• 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

Budget by workstream:

Governance Structure

Meeting Cadence:

Phase Gates (prevent premature transitions):

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:

Risk and Contingency

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:

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

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.