zhongwei/gh-lyndonkl-claude
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Zhongwei Li
2025-11-30 08:38:26 +08:00
commit 41d9f6b189
304 changed files with 98322 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

211
skills/roadmap-backcast/SKILL.md Normal file
View File

@@ -0,0 +1,211 @@
---
name: roadmap-backcast
description: Use when planning with fixed deadline or target outcome, working backward from future goal to present, defining milestones and dependencies, mapping critical path, identifying what must happen when, planning product launches with hard dates, multi-year strategic roadmaps, event planning, transformation initiatives, or when user mentions "backcast", "work backward from", "reverse planning", "we need to launch by", "target date is", or "what needs to happen to reach".
---
# Roadmap Backcast
## Table of Contents
1. [Purpose](#purpose)
2. [When to Use](#when-to-use)
3. [What Is It](#what-is-it)
4. [Workflow](#workflow)
5. [Dependency Mapping](#dependency-mapping)
6. [Critical Path Analysis](#critical-path-analysis)
7. [Common Patterns](#common-patterns)
8. [Guardrails](#guardrails)
9. [Quick Reference](#quick-reference)
## Purpose
Roadmap Backcast helps you plan backward from a fixed goal or deadline to the present, identifying required milestones, dependencies, critical path, and feasibility constraints. It transforms aspirational targets into actionable, sequenced plans.
## When to Use
**Invoke this skill when you need to:**
- Plan toward a fixed deadline (product launch, event, compliance date)
- Work backward from strategic goal to present steps
- Map dependencies and sequencing for complex initiatives
- Identify critical path (longest sequence that determines timeline)
- Assess feasibility of ambitious timeline
- Coordinate cross-functional work toward shared milestone
- Plan multi-year transformation with interim checkpoints
- Sequence initiatives that build on each other
- Allocate resources across dependent workstreams
**User phrases that trigger this skill:**
- "We need to launch by [date]"
- "Work backward from the goal"
- "What needs to happen to reach [outcome]?"
- "Reverse plan from target"
- "Fixed deadline, what's feasible?"
- "Backcast from [future state]"
- "Critical path to delivery"
## What Is It
A backcasting roadmap that:
1. **Defines end state** (specific, measurable target outcome and date)
2. **Works backward** (what must be true one step before? And before that?)
3. **Identifies milestones** (key checkpoints with clear deliverables)
4. **Maps dependencies** (what depends on what, what can be parallel)
5. **Finds critical path** (longest chain that determines minimum timeline)
6. **Assesses feasibility** (can we realistically achieve by target date?)
**Quick example (Product Launch by Q1 2025):**
- **Target**: Product live in production for 1000 customers by Jan 31, 2025
- **T-4 weeks** (Jan 3): Beta testing with 50 customers complete, critical bugs fixed
- **T-8 weeks** (Dec 6): Feature complete, internal QA passed
- **T-12 weeks** (Nov 8): MVP built, core features working
- **T-16 weeks** (Oct 11): Design finalized, API contracts defined
- **T-20 weeks** (Sep 13): Requirements locked, team staffed
- **Today** (Sep 1): Feasible if no scope creep and 20% time buffer included
## Workflow
Copy this checklist and track your progress:
```
Roadmap Backcast Progress:
- [ ] Step 1: Define target outcome precisely
- [ ] Step 2: Work backward to identify milestones
- [ ] Step 3: Map dependencies and sequencing
- [ ] Step 4: Identify critical path
- [ ] Step 5: Assess feasibility and adjust
```
**Step 1: Define target outcome precisely**
State specific outcome (not vague goal), target date, success criteria. See [Common Patterns](#common-patterns) for outcome definition examples. For straightforward backcasts → Use [resources/template.md](resources/template.md).
**Step 2: Work backward to identify milestones**
Start at end, ask "what must be true just before this?" iteratively. Create 5-10 major milestones. For complex multi-year roadmaps → Study [resources/methodology.md](resources/methodology.md).
**Step 3: Map dependencies and sequencing**
Identify what depends on what, what can run in parallel. See [Dependency Mapping](#dependency-mapping) for techniques.
**Step 4: Identify critical path**
Find longest sequence of dependent tasks (this determines minimum timeline). See [Critical Path Analysis](#critical-path-analysis).
**Step 5: Assess feasibility and adjust**
Compare required timeline to available time. Add buffers (20-30%), identify risks, adjust scope or date if needed. Self-check using `resources/evaluators/rubric_roadmap_backcast.json` before finalizing. Minimum standard: Average score ≥ 3.5.
## Dependency Mapping
**Dependency types:**
**Sequential (A → B)**: B cannot start until A completes
- Example: Design must complete before engineering starts
- Critical path impact: Extends timeline
- Mitigation: Start A as early as possible, parallelize where safe
**Parallel (A ∥ B)**: A and B can happen simultaneously
- Example: Backend and frontend development
- Critical path impact: None (if resourced)
- Benefit: Reduces overall timeline
**Converging (A, B → C)**: C requires both A and B to complete
- Example: Testing requires both code complete AND test environment ready
- Critical path impact: C waits for slower of A or B
- Mitigation: Monitor both paths, accelerate slower one
**Diverging (A → B, C)**: A enables both B and C
- Example: API contract defined enables frontend AND backend work
- Critical path impact: Delays in A delay everything downstream
- Mitigation: Prioritize A, ensure high quality to avoid rework
## Critical Path Analysis
**Critical path**: Longest sequence of dependent tasks (determines minimum project duration)
**Finding critical path:**
1. List all milestones with durations
2. Draw dependency graph (arrows from prerequisite to dependent)
3. Calculate earliest start/finish for each milestone (forward pass)
4. Calculate latest start/finish for each milestone (backward pass)
5. Milestones with zero slack (earliest = latest) are on critical path
**Example:**
```
Milestone A (4 weeks) → Milestone B (6 weeks) → Milestone D (2 weeks) = 12 weeks (critical path)
Milestone A (4 weeks) → Milestone C (3 weeks) → Milestone D (2 weeks) = 9 weeks (non-critical, 3 weeks slack)
```
**Critical path is 12 weeks** (A→B→D path)
**Managing critical path:**
- **Monitor closely**: Delays on critical path directly delay project
- **Add buffer**: 20-30% to critical path tasks (Murphy's Law)
- **Resource priority**: Staff critical path first
- **Fast-track**: Can non-critical work be delayed to help critical path?
- **Crash**: Add resources to shorten critical path (diminishing returns, Brook's Law applies)
## Common Patterns
**Pattern 1: Product Launch with Fixed Date**
- **Target**: Product live by date, serving customers
- **Key milestones (backward)**: GA launch, beta testing, feature freeze, alpha testing, MVP, design complete, requirements locked
- **Critical path**: Usually design → engineering → testing (sequential)
- **Buffer**: 20-30% on engineering (unknowns), 20% on testing (bugs)
**Pattern 2: Compliance Deadline (Regulatory)**
- **Target**: Compliant by regulatory deadline (cannot slip)
- **Key milestones**: Audit passed, controls implemented, policies updated, gap analysis complete
- **Critical path**: Gap analysis → remediation → validation
- **Buffer**: 40%+ (regulatory risk intolerant, build extra time)
**Pattern 3: Strategic Transformation (Multi-Year)**
- **Target**: Future state vision (e.g., "Cloud-native architecture by 2027")
- **Key milestones (annual)**: Year 3 (full migration), Year 2 (50% migrated), Year 1 (pilot complete), Year 0 (strategy approved)
- **Critical path**: Foundation work (pilot, learnings) enables scale
- **Buffer**: 30%+ per phase (unknowns compound over time)
**Pattern 4: Event Planning (Conference, Launch Event)**
- **Target**: Event happens on date, attendees have great experience
- **Key milestones**: Event day, rehearsal, content ready, speakers confirmed, venue booked, date announced
- **Critical path**: Venue booking (long lead time) often on critical path
- **Buffer**: 10-20% (events have hard deadlines, less flexible)
## Guardrails
**Feasibility checks:**
- **Available time ≥ required time**: If backward timeline reaches before today, goal is infeasible
- **Buffer included**: Add 20-30% to estimates (Hofstadter's Law: "It always takes longer than you expect, even when you account for Hofstadter's Law")
- **Dependencies realistic**: Can dependent work actually be done in sequence (handoff time, rework)?
- **Resource constraints**: Do we have people/budget to parallelize where needed?
**Common pitfalls:**
- **Optimistic sequencing**: Assuming perfect handoffs, no rework, no blockers
- **Ignoring dependencies**: "We can start everything at once" → actually highly sequential
- **No buffer**: Plans with 0% slack fail on first hiccup
- **Scope creep**: Target outcome expands during execution, invalidates backcast
- **Sunk cost fallacy**: When backcast shows infeasibility, adjust scope or date (don't plow ahead)
**Quality standards:**
- Milestones have clear deliverables (not "working on X")
- Dependencies explicitly mapped (not assumed)
- Critical path identified (know what determines timeline)
- Feasibility assessed honestly (not wishful thinking)
- Risks documented (what could extend timeline?)
- Owners assigned to each milestone (accountability)
## Quick Reference
**Resources:**
- **Quick backcast**: [resources/template.md](resources/template.md)
- **Complex roadmaps**: [resources/methodology.md](resources/methodology.md)
- **Quality rubric**: `resources/evaluators/rubric_roadmap_backcast.json`
**5-Step Process**: Define Target → Work Backward → Map Dependencies → Find Critical Path → Assess Feasibility
**Dependency types**: Sequential (A→B) | Parallel (A∥B) | Converging (A,B→C) | Diverging (A→B,C)
**Critical path**: Longest dependent sequence = minimum project duration
**Buffer rule**: Add 20-30% to estimates, 40%+ for high-uncertainty work
**Feasibility test**: Required time ≤ Available time (with buffer)

171
skills/roadmap-backcast/resources/evaluators/rubric_roadmap_backcast.json Normal file
View File

@@ -0,0 +1,171 @@
{
"name": "Roadmap Backcast Evaluator",
"description": "Evaluates backcasting roadmaps for target clarity, milestone sequencing, dependency mapping, critical path identification, and feasibility assessment",
"criteria": [
{
"name": "Target Outcome Specificity",
"weight": 1.4,
"scale": {
"1": "Vague target ('launch product', 'improve system') with no date or success criteria",
"2": "Target has date but outcome unclear or unmeasurable ('product better', 'customers happy')",
"3": "Target somewhat specific with date (e.g., 'launch by Q1') but missing quantifiable success criteria",
"4": "Specific measurable target with fixed date (e.g., '1000 customers by Jan 31, 2025') and clear criteria",
"5": "Exemplary: Precise measurable outcome with fixed date, quantified success criteria (conversion rates, NPS, revenue), constraints documented (budget, scope, quality), strategic importance articulated"
}
},
{
"name": "Milestone Quality and Sequencing",
"weight": 1.5,
"scale": {
"1": "No milestones or milestones are activities ('working on X') not deliverables",
"2": "Milestones listed but not sequenced, vague deliverables, missing key checkpoints",
"3": "5-10 milestones identified working backward, deliverables stated but some vague, basic sequencing",
"4": "Clear milestones with specific deliverables, logically sequenced backward from target, owners assigned, durations estimated",
"5": "Exemplary: 5-10 milestones with verifiable deliverables (not activities), precise backward sequencing using 'what must be true before' logic, each with owner/duration/prerequisites, milestones align to natural project phases, no missing critical checkpoints"
}
},
{
"name": "Dependency Mapping Completeness",
"weight": 1.4,
"scale": {
"1": "No dependencies identified or implicit assumptions only",
"2": "Some dependencies noted but incomplete, no distinction between sequential/parallel",
"3": "Major dependencies mapped, sequential vs parallel identified, some gaps in upstream/downstream links",
"4": "Comprehensive dependency mapping, clear prerequisites and enabled tasks for each milestone, parallel workstreams identified",
"5": "Exemplary: All dependencies explicitly mapped (sequential, parallel, converging, diverging), dependency graph or table provided, handoff requirements specified, coordination points identified, external dependencies flagged with extra buffer"
}
},
{
"name": "Critical Path Identification",
"weight": 1.5,
"scale": {
"1": "No critical path identified or not understood",
"2": "Critical path mentioned but incorrectly identified or not validated",
"3": "Critical path identified (longest dependent chain) but slack on non-critical tasks not calculated",
"4": "Critical path correctly identified with duration, non-critical paths have slack calculated",
"5": "Exemplary: Critical path precisely identified using CPM (forward/backward pass), slack calculated for all milestones, critical vs non-critical clearly distinguished, management strategy for critical path defined (monitoring, buffer allocation, acceleration options)"
}
},
{
"name": "Buffer and Risk Management",
"weight": 1.3,
"scale": {
"1": "No buffers included, optimistic estimates only",
"2": "Generic buffer mentioned ('add some extra time') but not quantified or placed",
"3": "Buffers added (e.g., 20%) but uniform across all tasks regardless of uncertainty",
"4": "Risk-appropriate buffers (20-30% for moderate, 40%+ for high uncertainty), placed on critical path",
"5": "Exemplary: Buffers calibrated by uncertainty (10-50% range), PERT or 3-point estimates used, project buffer vs feeding buffers distinguished (CCPM), risk register with mitigation/contingency plans, triggers for re-planning defined, buffer consumption monitoring plan"
}
},
{
"name": "Feasibility Assessment Rigor",
"weight": 1.4,
"scale": {
"1": "No feasibility check, assumed possible without analysis",
"2": "Basic comparison (target date vs today) but no buffer, resource constraints, or risk consideration",
"3": "Feasibility assessed (available time vs required time) with buffer, but resource/scope constraints not addressed",
"4": "Rigorous feasibility: time + buffer + resource constraints + scope, verdict (feasible/tight/infeasible) with clear reasoning",
"5": "Exemplary: Comprehensive feasibility assessment including time/buffer/resources/scope/risks, Monte Carlo or probability analysis (P50/P80/P95), if infeasible clear options provided (extend deadline X weeks, reduce scope Y features, add resources $Z cost), trade-off analysis for options, honest assessment not wishful thinking"
}
},
{
"name": "Resource and Capacity Planning",
"weight": 1.2,
"scale": {
"1": "No resource consideration, assumes unlimited capacity",
"2": "Resources mentioned but not quantified (team size, budget, constraints)",
"3": "Resource requirements estimated but not compared to available capacity, gaps not identified",
"4": "Resource requirements vs available capacity analyzed, gaps identified with mitigation (hiring, contractors)",
"5": "Exemplary: Resource loading chart showing demand over time, peak capacity vs available, over-allocation identified and resolved (resource leveling/smoothing), hiring/onboarding timeline factored into plan, budget allocated to milestones, resource constraints drive sequencing decisions"
}
},
{
"name": "Actionability and Communication",
"weight": 1.1,
"scale": {
"1": "Theoretical roadmap with no execution plan, stakeholders unclear, no ownership",
"2": "Some execution details but vague, ownership not assigned, communication plan missing",
"3": "Milestones have owners, basic communication plan (updates), but escalation path and decision gates unclear",
"4": "Actionable: owners assigned, communication cadence defined (weekly updates, milestone reviews), escalation path for delays",
"5": "Exemplary: Complete execution plan with named owners for each milestone, stakeholder communication plan (who/what/when), Go/No-Go decision gates at key milestones, escalation paths (3-level), status dashboard defined, next steps to initiate roadmap clear (approvals, kickoff, resource allocation)"
}
}
],
"guidance": {
"by_roadmap_type": {
"product_launch": {
"typical_milestones": "Requirements locked → Design finalized → MVP built → Feature complete → QA passed → Beta testing → GA launch",
"critical_path_focus": "Design → Engineering → Testing (usually 60-70% of timeline)",
"buffer_recommendation": "20-30% on engineering (unknowns), 20% on testing (bugs), 10-20% on beta (user feedback)",
"red_flags": ["No feature freeze milestone", "Testing squeezed at end", "No beta period", "Scope creep not controlled"]
},
"compliance_deadline": {
"typical_milestones": "Gap analysis → Remediation plan → Controls implemented → Policies updated → Internal audit → External audit passed",
"critical_path_focus": "Gap analysis → Remediation → Audit validation",
"buffer_recommendation": "40%+ (cannot miss regulatory deadline, audit findings may require rework)",
"red_flags": ["<30% buffer (high risk of missing)", "No internal audit before external", "Remediation not sequenced by dependency"]
},
"strategic_transformation": {
"typical_milestones": "Strategy approved → Pilot complete → Learnings applied → Phase 1 rollout → Phase 2 rollout → Full migration",
"critical_path_focus": "Pilot and learning (foundation for scale)",
"buffer_recommendation": "30%+ per phase (unknowns compound over time)",
"red_flags": ["No pilot/learning phase", "Trying to scale without validation", "Organizational change management missing"]
},
"event_planning": {
"typical_milestones": "Date announced → Venue booked → Speakers confirmed → Content ready → Rehearsal → Event day",
"critical_path_focus": "Venue booking (long lead time), speaker coordination",
"buffer_recommendation": "10-20% (hard deadline, less flexible)",
"red_flags": ["Venue not secured early", "No rehearsal milestone", "Content creation squeezed at end"]
}
}
},
"common_failure_modes": {
"optimistic_sequencing": {
"symptom": "Assumes perfect handoffs, no rework, no blockers; 0% buffer",
"root_cause": "Wishful thinking, pressure to say 'yes' to deadline, Hofstadter's Law ignored",
"fix": "Add 20-30% buffer to estimates, use PERT 3-point estimates (optimistic/likely/pessimistic), review against historical data"
},
"missing_dependencies": {
"symptom": "Tasks planned in parallel that actually require sequential completion, integration surprises",
"root_cause": "Didn't ask 'what must be true before this starts?', assumed work is independent",
"fix": "Explicit dependency mapping (prerequisite/enables table), review with technical leads, identify converging/diverging points"
},
"wrong_critical_path": {
"symptom": "Managing wrong tasks as critical, actual delays surprise team",
"root_cause": "Intuition-based not calculation-based, didn't account for all dependencies",
"fix": "Use CPM forward/backward pass, calculate slack, validate with project management tool"
},
"scope_creep_invalidates_plan": {
"symptom": "Milestones slip because scope expanded mid-project",
"root_cause": "No requirements freeze, stakeholder says 'just one more feature', change control missing",
"fix": "Requirements freeze milestone, change control process (cost/timeline impact analysis before approving), stakeholder alignment on must-haves vs nice-to-haves"
},
"ignoring_resource_constraints": {
"symptom": "Plan shows 10 engineers needed, only have 5, tasks over-allocated",
"root_cause": "Assumed can parallelize everything, didn't check capacity",
"fix": "Resource leveling (delay non-critical tasks), resource smoothing (steady demand), hire/contract to fill gaps"
},
"no_feasibility_check": {
"symptom": "Backcast reaches before today, team commits anyway, fails predictably",
"root_cause": "Sunk cost fallacy, pressure to commit, hope over reality",
"fix": "Honest feasibility assessment, if infeasible present options (extend date, reduce scope, add resources), escalate to leadership for decision"
}
},
"excellence_indicators": [
"Target outcome is specific, measurable, with fixed date and quantified success criteria",
"5-10 milestones working backward from target, each with clear deliverable",
"Milestones sequenced using 'what must be true before' logic",
"Dependencies explicitly mapped (sequential, parallel, converging, diverging)",
"Critical path identified using CPM or visual dependency graph",
"Slack calculated for non-critical milestones",
"Buffers calibrated by uncertainty (20-50% range based on risk)",
"Feasibility rigorously assessed: required time (with buffer) ≤ available time",
"Resource constraints analyzed (team capacity vs requirements)",
"If infeasible, clear options provided with trade-offs (extend deadline, reduce scope, add resources)",
"Risk register for timeline threats with mitigation/contingency",
"Owners assigned to each milestone",
"Communication plan defined (weekly updates, milestone reviews, escalation path)",
"Assumptions and constraints explicitly documented",
"Honest assessment not wishful thinking (acknowledges tight timelines, risks)"
]
}

387
skills/roadmap-backcast/resources/methodology.md Normal file
View File

@@ -0,0 +1,387 @@
# Roadmap Backcast: Advanced Methodologies
## Table of Contents
1. [Critical Path Method (CPM) Mathematics](#1-critical-path-method-cpm-mathematics)
2. [Advanced Dependency Patterns](#2-advanced-dependency-patterns)
3. [Buffer Management Techniques](#3-buffer-management-techniques)
4. [Multi-Track Roadmaps](#4-multi-track-roadmaps)
5. [Risk-Adjusted Timeline Planning](#5-risk-adjusted-timeline-planning)
6. [Resource Optimization](#6-resource-optimization)
## 1. Critical Path Method (CPM) Mathematics
### Forward Pass (Earliest Start/Finish)
**Process**:
1. Start at beginning, assign ES=0 to first milestone
2. For each milestone: EF = ES + Duration
3. For dependent milestones: ES = max(EF of all prerequisites)
4. Continue until end milestone
**Example**:
```
Milestone A: ES=0, Duration=4, EF=4
Milestone B (depends on A): ES=4, Duration=6, EF=10
Milestone C (depends on A): ES=4, Duration=3, EF=7
Milestone D (depends on B, C): ES=max(10,7)=10, Duration=2, EF=12
```
**Project duration**: EF of final milestone = 12 weeks
### Backward Pass (Latest Start/Finish)
**Process**:
1. Start at end, assign LF = EF of final milestone
2. For each milestone: LS = LF - Duration
3. For prerequisites: LF = min(LS of all dependents)
4. Continue until start milestone
**Example** (working backward from D):
```
Milestone D: LF=12, Duration=2, LS=10
Milestone B (enables D): LF=10, Duration=6, LS=4
Milestone C (enables D): LF=10, Duration=3, LS=7
Milestone A (enables B, C): LF=min(4,7)=4, Duration=4, LS=0
```
### Slack Calculation
**Slack** (or Float) = LS - ES = LF - EF
**Milestones with zero slack are on critical path**:
- Milestone A: 0-0=0 ✓ Critical
- Milestone B: 4-4=0 ✓ Critical
- Milestone C: 7-4=3 (3 weeks slack, non-critical)
- Milestone D: 10-10=0 ✓ Critical
**Critical path**: A → B → D (12 weeks)
### Using Slack for Scheduling
**Milestones with slack**:
- Can be delayed up to slack amount without impacting project
- Use slack to smooth resource utilization
- Delay non-critical work to free resources for critical path
**Example**: Milestone C has 3 weeks slack
- Can start as early as week 4 (ES=4)
- Must start no later than week 7 (LS=7)
- Flexibility to schedule based on resource availability
## 2. Advanced Dependency Patterns
### Soft Dependencies vs Hard Dependencies
**Hard dependency** (cannot proceed without):
- Example: Cannot test code until code is written
- Enforce strictly in schedule
**Soft dependency** (preferable but not required):
- Example: Prefer to have design complete before engineering, but can start with partial design
- Allow overlap if timeline pressure, accept rework risk
### Lag and Lead Time
**Lag**: Mandatory delay between dependent tasks
- Example: "Concrete must cure 7 days after pouring before building on it"
- Add lag to dependency: A → [+7 days lag] → B
**Lead**: Task can start before prerequisite fully completes
- Example: "Can start integration testing when 80% of code complete"
- Negative lag or start-to-start dependency with offset
### Conditional Dependencies
**Branching dependencies**:
```
Design Complete → [If design approved] → Engineering
→ [If design rejected] → Redesign → Engineering
```
**Include in backcast**: Plan for expected path, note contingency branches
### External Dependencies (Outside Team Control)
**Vendor deliveries, regulatory approvals, partner integration**:
- Identify early (longest lead time often on critical path)
- Add extra buffer (40-50% for external dependencies)
- Establish contract penalties for delays
- Plan alternative paths where possible
**Example**:
- Primary path: Vendor delivers component → Integration (4 weeks lead time, +50% buffer = 6 weeks)
- Backup path: Build in-house (8 weeks, more reliable) - evaluate cost/benefit
## 3. Buffer Management Techniques
### Critical Chain Project Management (CCPM)
**Concept**: Remove buffers from individual tasks, aggregate into project buffer at end
**Traditional approach**:
- Task A: 4 weeks + 20% buffer = 4.8 weeks
- Task B: 6 weeks + 30% buffer = 7.8 weeks
- Total: 12.6 weeks
**CCPM approach**:
- Task A: 4 weeks (aggressive estimate)
- Task B: 6 weeks (aggressive estimate)
- Project buffer: 50% of critical path = 5 weeks
- Total: 15 weeks (4+6+5)
**Benefits**: Prevents Parkinson's Law (work expands to fill time), focuses on project completion not task completion
### Buffer Placement
**Project buffer**: At end of critical path (protects project deadline)
**Feeding buffer**: Where non-critical path joins critical path (prevents non-critical delays from impacting critical)
**Example**:
```
Critical: A (4w) → B (6w) → D (2w) → [Project Buffer: 3w]
Non-critical: C (3w) → [Feeding Buffer: 1w] → D
```
**Feeding buffer protects against C delaying D's start**
### Buffer Consumption Monitoring
**Traffic light system**:
- **Green** (0-33% buffer consumed): On track
- **Yellow** (33-67% buffer consumed): Warning, monitor closely
- **Red** (67-100% buffer consumed): Crisis, corrective action needed
**Example**: 12-week critical path, 3-week buffer
- Week 8 complete, 1 week delay → 1/3 buffer consumed → Green
- Week 10 complete, 3 weeks delay → 3/3 buffer consumed → Red (need to accelerate or extend deadline)
## 4. Multi-Track Roadmaps
### Parallel Workstreams
**Identify independent tracks**:
- Track 1 (Frontend): Design → Frontend dev → Frontend testing
- Track 2 (Backend): API design → Backend dev → Backend testing
- Track 3 (Infrastructure): Cloud setup → CI/CD → Monitoring
**Synchronization points** (all tracks must converge):
- Integration testing (requires all 3 tracks complete)
- Deploy to production (requires integration testing + infrastructure ready)
**Managing multi-track**:
- Assign clear owners to each track
- Identify longest track (determines overall timeline)
- Monitor convergence points closely (often become critical)
### Portfolio Backcasting (Multiple Initiatives)
**Scenario**: Launch Products A, B, C by Q4 2025
**Approach**:
1. Backcast each product independently
2. Identify resource conflicts (same people/budget needed)
3. Sequence to resolve conflicts (stagger starts, prioritize critical path work)
4. Re-assess portfolio feasibility
**Resource smoothing**: Adjust non-critical task timing to avoid resource over-allocation
## 5. Risk-Adjusted Timeline Planning
### Monte Carlo Simulation for Timelines
**Process**:
1. For each milestone, estimate optimistic/likely/pessimistic duration (3-point estimate)
2. Run 1000+ simulations, randomly sampling from distributions
3. Generate probability distribution of project completion dates
**Example**:
```
Milestone A: Optimistic=3w, Likely=4w, Pessimistic=6w
Milestone B: Optimistic=4w, Likely=6w, Pessimistic=10w
Milestone D: Optimistic=1w, Likely=2w, Pessimistic=4w
```
**Simulation results**:
- P50 (median): 12 weeks (50% chance complete by week 12)
- P80: 15 weeks (80% chance complete by week 15)
- P95: 18 weeks (95% chance complete by week 18)
**Use P80 or P90 for deadline setting** (realistic buffer)
### PERT (Program Evaluation and Review Technique)
**Expected duration formula**:
```
Expected = (Optimistic + 4×Likely + Pessimistic) / 6
```
**Example**:
```
Milestone A: (3 + 4×4 + 6) / 6 = 4.17 weeks
Milestone B: (4 + 4×6 + 10) / 6 = 6.33 weeks
Milestone D: (1 + 4×2 + 4) / 6 = 2.17 weeks
Critical path: 4.17 + 6.33 + 2.17 = 12.67 weeks
```
**Standard deviation** (measures uncertainty):
```
σ = (Pessimistic - Optimistic) / 6
```
**Example**:
```
Milestone B: σ = (10 - 4) / 6 = 1 week
```
**68% chance B completes within 6.33 ± 1 week = 5.33 to 7.33 weeks**
### Risk-Driven Milestone Sequencing
**Identify highest-risk milestones** (technical unknowns, novel work, external dependencies)
**De-risk early**: Sequence high-risk work toward beginning of roadmap
- Learn quickly if infeasible
- Maximize time to pivot if needed
- Avoid sunk cost trap (months invested before discovering blocker)
**Example**:
- High risk: "Integrate with Partner X API" (never done before, unknown technical constraints)
- **Do early**: Spike integration in month 1, not month 6 (discover blockers sooner)
## 6. Resource Optimization
### Resource Leveling
**Problem**: Resource over-allocation (need 10 engineers, have 5)
**Solution**:
1. Identify over-allocated periods
2. Delay non-critical tasks (use slack)
3. If still over-allocated, extend critical path
**Example**:
```
Weeks 1-4: Tasks A + C = 10 engineers needed, have 5
Task C has 3 weeks slack → Delay C to weeks 5-7
Result: Weeks 1-4 (Task A: 5 engineers), Weeks 5-7 (Task C: 5 engineers)
```
### Resource Smoothing
**Goal**: Minimize resource fluctuations (avoid hire/fire cycles)
**Approach**: Shift non-critical tasks within slack to create steady resource demand
**Example**:
```
Original: Weeks 1-4 (10 eng), Weeks 5-8 (2 eng), Weeks 9-12 (8 eng)
Smoothed: Weeks 1-4 (6 eng), Weeks 5-8 (6 eng), Weeks 9-12 (6 eng)
```
### Fast-Tracking (Overlapping Phases)
**Concept**: Start dependent task before prerequisite fully completes
**Example**:
- Traditional: Design complete (week 4) → Engineering starts (week 5)
- Fast-track: Engineering starts week 3 with 75% design complete → Risk of rework if design changes
**When to fast-track**:
- Timeline pressure, small slack margin
- Low risk of design changes (stable requirements)
- Acceptable rework cost (10-20% likely)
**When NOT to fast-track**:
- High design uncertainty (rework >50% likely)
- Regulatory work (cannot afford rework)
- Critical path already has adequate buffer
### Crashing (Adding Resources)
**Concept**: Shorten critical path by adding resources
**Example**: Task B (6 weeks, 1 engineer) → Add 2nd engineer → Completes in 4 weeks
**Constraints**:
- **Diminishing returns**: 9 women can't make a baby in 1 month (Brooks's Law)
- **Communication overhead**: Adding people initially slows down (ramp-up time)
- **Indivisible tasks**: Some work cannot be parallelized
**When to crash**:
- Critical path task, high priority to accelerate
- Task is parallelizable (coding yes, architecture design harder)
- Resources available (budget, hiring pipeline)
- Early in project (time to onboard)
**Cost-benefit**:
```
Crashing cost: 2nd engineer for 4 weeks = $40K
Benefit: 2 weeks earlier → Capture market window worth $200K
ROI: ($200K - $40K) / $40K = 400% → Crash
```
---
## Workflow Integration
**When to use advanced techniques**:
**CPM mathematics** → Complex roadmaps (>10 milestones), need precise critical path
**Advanced dependencies** → Multi-team coordination, conditional paths, external dependencies
**Buffer management** → High-uncertainty projects, regulatory timelines, want buffer visibility
**Multi-track roadmaps** → Cross-functional initiatives, parallel product development
**Risk-adjusted planning** → Novel work, high stakes, leadership wants confidence intervals
**Resource optimization** → Constrained resources, want to minimize hiring/layoffs
**Start simple, add complexity as needed**:
1. **Basic backcast**: Target → Milestones → Dependencies → Critical path (visual/intuitive)
2. **Moderate complexity**: Add buffers, resource constraints, risk register
3. **Advanced**: CPM calculations, Monte Carlo, CCPM, resource leveling
**Tools**:
- **Simple** (5-10 milestones): Spreadsheet, Gantt chart, whiteboard
- **Moderate** (10-30 milestones): Asana, Monday.com, Jira with dependencies
- **Complex** (30+ milestones): MS Project, Primavera, dedicated project management software with CPM/PERT
---
## Case Study: Product Launch Backcast
**Target**: SaaS product live with 1000 paying customers by Dec 31, 2024
**Milestones** (working backward):
1. **Dec 31**: 1000 customers (Target)
2. **Dec 1**: GA launch, marketing campaign, 100 customers
3. **Nov 1**: Beta complete, pricing finalized, sales ready
4. **Oct 1**: Feature complete, QA passed, beta started (50 users)
5. **Sep 1**: MVP built, alpha testing with 10 users
6. **Aug 1**: Design finalized, APIs defined, engineering staffed
7. **Jul 1**: Requirements locked, design started
8. **Jun 1** (Today): Project approved, team forming
**Dependencies**:
- Sequential: Requirements → Design → Engineering → QA → Beta → GA
- Parallel: Marketing (starts Sep 1) ∥ Sales training (starts Oct 1)
**Critical path**: Requirements → Design → Engineering → QA → Beta → GA = 30 weeks
- Requirements: 4 weeks
- Design: 4 weeks
- Engineering: 12 weeks
- QA: 4 weeks
- Beta: 4 weeks
- GA ramp: 4 weeks
- **Total**: 32 weeks
**Feasibility**:
- Available: Jun 1 to Dec 31 = 30 weeks
- Required (with 20% buffer): 32 × 1.2 = 38 weeks
- **Verdict**: Infeasible by 8 weeks
**Options**:
1. **Extend deadline**: Launch Feb 28, 2025 (+8 weeks)
2. **Reduce scope**: Cut features, launch MVP-only → Engineering 8 weeks instead of 12 → Saves 4 weeks, still need +4
3. **Accelerate**: Add 2 engineers to shorten Engineering 12→10 weeks → Costs $80K, saves 2 weeks, still need +6
4. **Combination**: Reduce scope (-4 weeks) + Accelerate (-2 weeks) + 10% risk acceptance (+2 weeks buffer removed) = 30 weeks → **Feasible**
**Decision**: Reduce scope to MVP, add 1 engineer, accept 10% risk → Launch Dec 31 with 70% confidence

362
skills/roadmap-backcast/resources/template.md Normal file
View File

@@ -0,0 +1,362 @@
# Roadmap Backcast Template
## Workflow
Copy this checklist and track your progress:
```
Roadmap Backcast Progress:
- [ ] Step 1: Define target outcome
- [ ] Step 2: Work backward to milestones
- [ ] Step 3: Map dependencies
- [ ] Step 4: Identify critical path
- [ ] Step 5: Assess feasibility
```
**Step 1: Define target outcome**
State specific outcome, date, success criteria. See [Target Definition](#target-definition).
**Step 2: Work backward to milestones**
Ask "what must be true just before?" iteratively. See [Milestone Backcasting](#milestone-backcasting-process).
**Step 3: Map dependencies**
Identify sequential vs parallel work. See [Dependency Mapping](#dependency-mapping).
**Step 4: Identify critical path**
Find longest dependent chain. See [Critical Path](#critical-path-identification).
**Step 5: Assess feasibility**
Check time available, add buffers, identify risks. See [Feasibility Assessment](#feasibility-assessment).
---
## Roadmap Backcast Template
### Target Definition
**Target Outcome**: [Specific, measurable end state]
**Target Date**: [Fixed deadline - DD/MM/YYYY]
**Success Criteria**:
- [Criterion 1]: [Quantifiable measure of success]
- [Criterion 2]: [...]
- [Criterion 3]: [...]
**Why this matters**: [Business impact, strategic importance, consequences if missed]
**Constraints**:
- **Budget**: [Available resources]
- **Team**: [Available capacity, FTEs]
- **Dependencies**: [External constraints, vendor timelines, regulatory deadlines]
- **Scope**: [Must-haves vs nice-to-haves]
---
### Milestone Backcasting Process
**Working backward from target date:**
#### Milestone 0: Target Outcome (T+0)
**Date**: [Target date]
**Deliverable**: [Final outcome achieved]
**Owner**: [Name/Role]
**Dependencies**: [What must be complete for this to happen]
#### Milestone 1: [Name] (T-[X weeks/months])
**Date**: [Date]
**Deliverable**: [Specific output, not activity]
**Owner**: [Name/Role]
**Duration**: [X weeks/months]
**Dependencies**: [Requires milestone 2, 3 complete]
**What must be true before**: [State of world needed to start this milestone]
#### Milestone 2: [Name] (T-[X weeks/months])
**Date**: [Date]
**Deliverable**: [...]
**Owner**: [...]
**Duration**: [...]
**Dependencies**: [...]
**What must be true before**: [...]
#### Milestone 3: [Name] (T-[X weeks/months])
**Date**: [Date]
**Deliverable**: [...]
**Owner**: [...]
**Duration**: [...]
**Dependencies**: [...]
**What must be true before**: [...]
#### Milestone N: Starting Point (Today)
**Date**: [Today's date]
**Deliverable**: [Current state, what we have now]
**Owner**: [...]
**What we need to begin**: [Resources, approvals, information to start milestone N-1]
---
### Dependency Mapping
**Dependency Graph**:
```
[Milestone A] ──→ [Milestone B] ──→ [Milestone D] ──→ [Target]
↑
[Milestone C] ────────────────────────┘
```
**Dependency Table**:
| Milestone | Depends On (Prerequisites) | Enables (Downstream) | Type | Can Parallelize? |
|-----------|---------------------------|----------------------|------|------------------|
| [Milestone A] | None (start) | [B] | Sequential | No (on critical path) |
| [Milestone B] | [A] | [D] | Sequential | No (on critical path) |
| [Milestone C] | [A] | [D] | Parallel with B | Yes (non-critical) |
| [Milestone D] | [B, C] | [Target] | Converging | No (on critical path) |
**Parallel workstreams** (can happen simultaneously):
- [Milestone X] ∥ [Milestone Y]: [Why these can be parallel]
- [Milestone Z] ∥ [Milestone W]: [...]
**Converging points** (multiple prerequisites):
- [Milestone M] requires both [A] AND [B]: [Coordination needed]
**Diverging points** (one enables multiple):
- [Milestone N] enables [X], [Y], [Z]: [Handoff process]
---
### Critical Path Identification
**Critical path** (longest dependent chain):
```
[Start] → [Milestone A: 4 weeks] → [Milestone B: 6 weeks] → [Milestone D: 2 weeks] → [Target]
Total: 12 weeks
```
**Alternative paths** (non-critical, have slack):
```
[Start] → [Milestone A: 4 weeks] → [Milestone C: 3 weeks] → [Milestone D: 2 weeks] → [Target]
Total: 9 weeks (3 weeks slack)
```
**Critical path milestones** (zero slack, delays directly impact target):
- [Milestone A]: [Why on critical path, impact if delayed]
- [Milestone B]: [Why on critical path, impact if delayed]
- [Milestone D]: [Why on critical path, impact if delayed]
**Non-critical milestones** (have slack, can absorb delays):
- [Milestone C]: [X weeks slack, latest finish date without impacting target]
**Critical path management**:
- **Monitor**: [How will we track critical path progress? Weekly reviews, dashboards]
- **Accelerate**: [Can we add resources to shorten critical path? Cost/benefit]
- **Buffer**: [20-30% buffer on critical path tasks built in? Where?]
---
### Feasibility Assessment
**Time Analysis**:
| Component | Estimate (weeks) | Buffer (%) | Buffered (weeks) |
|-----------|------------------|------------|------------------|
| [Milestone A] | [4] | [20%] | [4.8] |
| [Milestone B] | [6] | [30%] | [7.8] |
| [Milestone D] | [2] | [20%] | [2.4] |
| **Total (critical path)** | **12** | - | **15** |
**Available time**: [Target date - Today = X weeks]
**Required time** (with buffer): [15 weeks]
**Feasibility verdict**:
- ✓ **Feasible** if Available ≥ Required (with X weeks margin)
- ⚠ **Tight** if Available ≈ Required (±10%)
- ✗ **Infeasible** if Available < Required
**If infeasible, options**:
1. **Extend deadline**: Move target date to [new date] (need X additional weeks)
2. **Reduce scope**: Cut [feature Y], defer [feature Z] to post-launch
3. **Add resources**: Hire [N contractors/FTEs], cost $[X], reduces timeline by [Y weeks]
4. **Accept risk**: Proceed with [X%] probability of missing deadline
---
### Risk Register
**Risks to timeline**:
| Risk | Probability (H/M/L) | Impact (H/M/L) | Mitigation | Contingency |
|------|---------------------|----------------|------------|-------------|
| [Vendor delay on component X] | H | H | Contract penalties, alternate vendor identified | Built 4-week buffer in milestone B |
| [Key engineer leaves] | M | H | Cross-train team, document tribal knowledge | Contractor bench available |
| [Scope creep from stakeholder Y] | H | M | Requirements freeze by milestone 2, change control process | Reserve 2 weeks flex time |
| [Technical unknowns in integration] | M | H | Technical spike in milestone 3, architecture review | Parallel path with simpler approach |
**Triggers for re-planning**:
- Critical path milestone delayed >1 week → Escalate, re-assess feasibility
- Scope change >20% → Re-run backcast, adjust target or timeline
- Resource loss >25% → Revisit parallelization, extend timeline
---
### Resource Allocation
**Team capacity**:
| Role | Available FTEs | Required FTEs (peak) | Gap | Mitigation |
|------|----------------|----------------------|-----|------------|
| [Engineering] | [5] | [7] | [-2] | [Hire 2 contractors by milestone 2] |
| [Design] | [2] | [2] | [0] | [Sufficient] |
| [QA] | [1] | [3] | [-2] | [Outsource testing for milestone 4] |
**Budget**:
- **Total required**: $[X]
- **Allocated**: $[Y]
- **Gap**: $[X-Y] → [Source: reallocation, additional funding, scope reduction]
---
### Communication Plan
**Stakeholder alignment**:
- **Weekly updates**: [To whom, what format, starting when]
- **Milestone reviews**: [After each milestone, with stakeholders X, Y, Z]
- **Go/No-Go gates**: [At milestones A, C before committing to next phase]
**Escalation path**:
- **Level 1** (delays <1 week): Team lead resolves
- **Level 2** (delays 1-2 weeks): Product manager adjusts plan
- **Level 3** (delays >2 weeks or feasibility threat): Executive decision on scope/date
---
## Guidance for Each Section
### Target Definition
**Good target outcomes** (specific, measurable):
- ✓ "1000 paying customers using product by Jan 31, 2025"
- ✓ "SOC 2 Type II certification achieved by regulatory deadline Sept 1, 2025"
- ✓ "Conference with 500 attendees, NPS >40, on Oct 15, 2024"
**Bad target outcomes** (vague, unmeasurable):
- ❌ "Launch product soon"
- ❌ "Improve compliance"
- ❌ "Hold successful event"
### Milestone Backcasting
**Ask iteratively**: "What must be true just before [current milestone]?"
**Example (Product Launch)**:
- **Target**: 1000 customers using product
- **T-2 weeks**: Product in production, scaling, monitoring working
- **T-6 weeks**: Beta complete, critical bugs fixed, ready for GA
- **T-10 weeks**: MVP feature complete, QA passed
- **T-14 weeks**: Design finalized, APIs defined
- **T-18 weeks**: Requirements locked, team staffed
- **Today** (T-20 weeks): Feasible if starting now
**Milestone quality**:
- **Clear deliverable**: "Design finalized" not "working on design"
- **Verifiable**: Can objectively check if done
- **Owned**: Named person responsible
- **Estimated**: Duration in days/weeks/months
### Dependency Mapping
**Identify dependencies by asking**:
- "Can this start before [X] completes?" (sequential vs parallel)
- "What does this milestone need to begin?" (prerequisites)
- "What can't start until this finishes?" (downstream dependencies)
**Common patterns**:
- **Waterfall phases** (design → build → test): Sequential, little parallelization
- **Workstreams** (frontend ∥ backend ∥ infrastructure): Parallel, converge for integration
- **Approvals/Reviews**: Often converging (need multiple sign-offs)
### Critical Path Identification
**Shortcuts for small roadmaps** (<10 milestones):
1. Draw dependency graph
2. Visually trace longest path
3. Sum durations on that path
**For complex roadmaps** (>10 milestones):
- Use project management tools (MS Project, Asana, Jira with dependencies)
- Critical path method (CPM) calculation (forward/backward pass)
**Interpreting critical path**:
- Critical path length = minimum project duration
- Slack on non-critical tasks = flexibility
- Delays on critical path directly delay target
### Feasibility Assessment
**Buffer guidance by uncertainty**:
- **Low uncertainty** (done similar work before): 10-20% buffer
- **Medium uncertainty** (some unknowns, dependencies): 20-30% buffer
- **High uncertainty** (novel work, many risks): 30-50% buffer
- **Regulatory/Compliance**: 40%+ buffer (risk intolerant)
**Feasibility decision tree**:
```
Available time ≥ Required time (with buffer)?
├─ Yes → Proceed, monitor critical path closely
├─ Within 10% → Proceed with risk acknowledgment, escalation plan
└─ No → Re-plan (extend date, reduce scope, or add resources)
```
---
## Common Patterns by Context
**Product Launch**:
- Critical path: Design → Engineering → Testing (usually 60-70% of timeline)
- Buffer: 20-30% on engineering, 20% on testing
- Risks: Scope creep, technical unknowns, vendor delays
**Compliance/Regulatory**:
- Critical path: Gap analysis → Remediation → Audit
- Buffer: 40%+ (cannot miss regulatory deadline)
- Risks: Audit findings require rework, controls take longer than expected
**Event Planning**:
- Critical path: Venue booking (long lead time), content creation, speaker coordination
- Buffer: 10-20% (hard deadline, less flexible)
- Risks: Speaker cancellations, venue issues, low registration
**Strategic Transformation**:
- Critical path: Foundation work (pilot, learnings) before scaling
- Buffer: 30%+ per phase (unknowns compound)
- Risks: Organizational resistance, scope expansion, funding cuts
---
## Quality Checklist
- [ ] Target outcome is specific and measurable
- [ ] Target date is fixed (not flexible)
- [ ] Success criteria are quantifiable
- [ ] 5-10 major milestones identified working backward
- [ ] Each milestone has clear deliverable (not activity)
- [ ] Each milestone has owner assigned
- [ ] Dependencies explicitly mapped (prerequisites identified)
- [ ] Parallel workstreams identified where possible
- [ ] Critical path identified (longest dependent chain)
- [ ] Duration estimates include 20-30% buffer
- [ ] Feasibility assessed: required time ≤ available time
- [ ] Risks to timeline documented with mitigations
- [ ] Resource constraints identified (team, budget)
- [ ] Communication plan for stakeholder updates
- [ ] Escalation path defined for delays
- [ ] If infeasible, options provided (extend date, reduce scope, add resources)