Initial commit

skills/roadmap-backcast/resources/methodology.md

@@ -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