roadmap-backcast

What this skill does

# Roadmap Backcast

## Table of Contents
1. [Workflow](#workflow)
2. [Dependency Mapping](#dependency-mapping)
3. [Critical Path Analysis](#critical-path-analysis)
4. [Common Patterns](#common-patterns)
5. [Guardrails](#guardrails)
6. [Quick Reference](#quick-reference)

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