Skillquality 0.46

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

Price
free
Protocol
skill
Verified
no

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:

CriterionWeightDefinition of Success
[Criterion 1]X%[What "good" looks like]
[Criterion 2]X%[What "good" looks like]
[Criterion 3]X%[What "good" looks like]
Total100%

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:

CriterionWeightOption AOption BOption CDo 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 Score100%X.XX.XX.XX.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.

OptionOptimisticBasePessimistic
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 PointAnnual ImpactFrequencyTrend
[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 InactionYear 1Year 2Year 3Cumulative
[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.

MetricCurrent ValueIndustry BenchmarkGap
[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):

CategoryYear 0Year 1Year 2Year 3Total
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):

BenefitTypeYear 1Year 2Year 3Total
[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:

MetricValueHurdle RateAssessment
NPV$XX> $0[Pass/Fail]
IRRXX%[Org hurdle][Pass/Fail]
Payback PeriodX years[Org threshold][Pass/Fail]
ROIXX%[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):

ComponentYears 1-3Years 4-5Years 6-10Total
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

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

InitiativeDepends OnImpact if DelayedMitigation
[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):

MilestoneTarget DatePhaseSuccess CriteriaDependencies
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 CategoryPhase 1Phase 2Phase 3Total
FTEsXXXX
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)
WorkstreamDescriptionLeadKey DeliverablesDependencies
[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 / DeliverableSponsorProgram LeadWS LeadTeamClient SMEs
[Deliverable 1]ARCIC
[Deliverable 2]IARRC
[Key decision]ARCII
  • 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

RoleWorkstreamFTEDurationSkills Required
[Role 1][WS 1]X.X[Time][Skills]
[Role 2][WS 2]X.X[Time][Skills]

Budget by workstream:

WorkstreamLaborExternalOtherTotal
[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:

ForumFrequencyAttendeesPurposeDuration
Steering CommitteeBi-weeklySponsor, Program Lead, WS LeadsDecisions, escalations60 min
Program ReviewWeeklyProgram Lead, WS LeadsProgress, risks, dependencies45 min
Workstream Standup2-3x/weekWS Lead, TeamTask coordination, blockers15 min

Phase Gates (prevent premature transitions):

GateTransitionEntry CriteriaExit CriteriaApprover
G1Foundation -> Build[Requirements defined, team staffed][Assessment complete, design approved][Sponsor]
G2Build -> Deploy[Solutions developed, tested][Pilot successful, rollout plan approved][Sponsor]
G3Deploy -> 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 TypeApproval RequiredProcess
Minor scope changeProgram LeadDocument, assess impact, approve/reject
Major scope changeSteering CommitteeFormal change request, impact analysis, SteerCo decision
Timeline shift (< 2 weeks)Program LeadUpdate plan, notify stakeholders
Timeline shift (> 2 weeks)Steering CommitteeRoot cause analysis, recovery plan, SteerCo approval
Budget variance (< 10%)Program LeadDocument, adjust within contingency
Budget variance (> 10%)Steering CommitteeBusiness case for additional funding

Risk and Contingency

RiskImpactProbabilityMitigationOwner
[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:

SituationStart AtSkip
Decision not yet made, multiple paths possibleStage 1 (Options)Nothing
Recommendation exists, needs funding approvalStage 2 (Business Case)Stage 1
Approved and funded, needs execution planStage 3 (Roadmap)Stages 1-2
Roadmap exists, needs operational detailStage 4 (Implementation)Stages 1-3
Existing plan needs restructuringDiagnose first, then appropriate stageDepends

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

FromToWhat Carries Over
OptionsBusiness CaseRecommended option, investment estimate, risk profile, trade-offs accepted
Business CaseRoadmapApproved budget, benefits timeline, key risks, success metrics
RoadmapImplementationPhase 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

skillsource-anotbskill-implementation-planningtopic-agent-skillstopic-anthropictopic-claudetopic-codextopic-consultingtopic-coworktopic-gemini-clitopic-management-consultingtopic-plugin

Install

Quality

0.46/ 1.00

deterministic score 0.46 from registry signals: · indexed on github topic:agent-skills · 22 github stars · SKILL.md body (20,591 chars)

Provenance

Indexed fromgithub
Enriched2026-04-23 07:01:05Z · deterministic:skill-github:v1 · v1
First seen2026-04-18
Last seen2026-04-23

Agent access