# Execution Planning

> Apply execution-planning whenever the user has made a decision and needs to turn it into action — decomposing work, sequencing tasks, estimating timelines, and assigning ownership. Triggers on phrases like "how do we execute this?", "break this into tasks", "what's the project plan?", "create a roadmap", "what are the dependencies?", "who does what by when?", "how long will this take to build?". Use proactively after decision-synthesis or architecture-evaluation produces a committed decision that requires coordinated implementation.

- Skill: `andurilcode/execution-planning` (Agent Skill)
- Install (CLI): `npx skillmds@latest add andurilcode/execution-planning`
- Raw SKILL.md: https://api.skillmd.com/api/skills/andurilcode/execution-planning/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: andurilcode (https://skillmd.com/u/andurilcode)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/andurilcode/execution-planning

---


# Execution Planning

**Core principle**: A decision without a plan is a wish. Decompose work into tasks with dependencies, owners, timelines, and risk buffers. The plan's job is not to predict the future perfectly — it's to make the critical path visible and the risks explicit.

---

## When to Use This Skill

- A decision has been made (decision-synthesis, architecture-evaluation, or direct commitment) and needs to be implemented
- Work involves multiple people, teams, or phases requiring coordination
- Someone asks "how long will this take?" and the honest answer requires decomposition
- A project is underway but has no visible critical path or dependency map
- An architecture decision (Contract E) needs to be turned into a build plan

---

## Core Methodology

### Step 1: Frame the Execution Context

- **Decision being executed**: State the committed decision. From decision-synthesis: reference the recommendation. From architecture-evaluation (Contract E): capture the ADR decision, constraints, lock-in risks, migration requirements, sequencing hints.
- **Constraints**: Non-negotiable boundaries — budget, team size, compliance, hard deadlines, technology lock-ins.
- **Stakeholder alignment**: Who has bought in, who hasn't. Residual objections (Contract B) become execution risks.
- **Definition of done**: An observable outcome. Not activity ("we built it") but result ("users can do X, metric Y improved").

### Step 2: Build the Work Breakdown Structure

Decompose recursively: **deliverables → work packages → tasks**.

- **Deliverables**: 3-7 major outputs that, together, constitute "done"
- **Work packages**: Groupings of related tasks producing a deliverable (assignable to one owner)
- **Tasks**: Smallest unit producing a verifiable output (typically 1-5 days)

Rules:
- Every task has a **verifiable output** — inspectable, demoable, or testable
- No task larger than one person-week. If it is, decompose further.
- Include forgotten tasks: documentation, testing, migration, rollback planning, stakeholder communication
- Include integration tasks explicitly — "build A" and "build B" need an "integrate A with B" task

### Step 3: Map Dependencies

For every task:
- **What must finish before this can start?** (predecessor)
- **What can't start until this finishes?** (successor)
- **What can run in parallel?** (no dependency)

Represent as a DAG. Look for:
- **Sequential chains** that force serialization — can any be parallelized with a different design?
- **Convergence points** where streams merge — high-risk coordination moments
- **External dependencies** — approvals, vendor deliveries, other teams' work — flag as risks

### Step 4: Identify the Critical Path

The longest chain of dependent tasks from start to finish — it determines the minimum possible timeline.

- Highlight the critical path explicitly — every task on it is a schedule risk
- Tasks not on it have **float** (slack time). Quantify it.
- If the critical path is too long: parallelize, reduce scope, add resources to critical-path tasks, or accept the timeline

### Step 5: Estimate Durations

Use **reference-class estimation**: estimate based on how long similar work has actually taken before, not how long you hope.

For each task, three estimates:
- **Optimistic** (O): everything goes right (10th percentile)
- **Most likely** (M): realistic with normal friction (50th percentile)
- **Pessimistic** (P): significant obstacles (90th percentile)

**Expected duration** (PERT): (O + 4M + P) / 6. Use pessimistic for critical-path tasks and external dependencies.

Common estimation failures:
- **Planning fallacy**: people underestimate by 50-100% on average. Calibrate against past actuals.
- **Anchoring on optimism**: most-likely is not optimistic
- **Ignoring integration time**: individual tasks estimated well, but the time to make them work together is missed

### Step 6: Assign Ownership

- **Owner**: One person accountable for delivery (not a committee)
- **Contributors**: Who else is needed
- **Decision authority**: Can the owner make scope/approach decisions, or escalate?

RACI where coordination is complex:
- **Responsible**: Does the work
- **Accountable**: Owns the outcome (one person only)
- **Consulted**: Provides input before
- **Informed**: Notified after

### Step 7: Design Milestones and Risk Buffers

Place milestones at points where progress is **objectively observable** — not "50% complete" but "API endpoints deployed and passing integration tests."

Risk buffers:
- **Task-level**: Add to high-uncertainty tasks (use the gap between most-likely and pessimistic)
- **Project buffer**: 15-25% of critical path duration at the end. Absorbs accumulated variance individual estimates miss.
- **Feeding buffers**: Where a non-critical-path stream feeds into the critical path, add a buffer at the merge point

### Step 8: Surface Execution Risks and Resource Asks

Top risks paired with mitigations:

- **Dependency risks**: External teams, vendor delays, approval bottlenecks
- **Capability risks**: Skills the team doesn't have, unfamiliar technology
- **Scope risks**: Requirements likely to change or expand
- **Integration risks**: Components that must work together but built separately

For risks requiring resources, time, or scope changes beyond what's been approved, produce a resource ask in Contract C format for argument-craft:
- **What's needed**: Specific resource, time extension, scope change
- **Why**: The execution risk or critical-path constraint driving the ask
- **Consequence of not getting it**: What fails, degrades, or gets delayed

---

## Output Format

### 🎯 Execution Objective
- **Decision being executed**: [decision — reference source analysis if applicable]
- **Definition of done**: [observable outcome that proves completion]
- **Hard constraints**: [budget, team, deadline, compliance, technology lock-ins]
- **Stakeholder alignment status**: [who's bought in, residual objections]

### 📋 Work Breakdown Structure
| # | Deliverable | Work Package | Task | Output | Owner | Est. Duration |
|---|-------------|-------------|------|--------|-------|---------------|
| 1.1.1 | [Deliverable 1] | [Package 1.1] | [Task] | [Verifiable output] | [Person] | [O/M/P → Expected] |

### ⚖️ Dependency Map
```
[Task 1.1.1] → [Task 1.1.2] → [Task 2.1.1]  ← CRITICAL PATH
[Task 1.2.1] → [Task 1.2.2] ─────────────→ [Task 2.1.1]
                              (float: X days)
[Task 3.1.1] (parallel, no dependencies)
```

### 📊 Timeline and Milestones
| Milestone | Date | Proof of Completion | On Critical Path? |
|-----------|------|--------------------|--------------------|
| [Milestone] | [date] | [observable output] | Yes / No |
| **Project buffer** | [date range] | — | — |

### 👥 Ownership Matrix
| Work Package | Responsible | Accountable | Consulted | Informed |
|-------------|------------|-------------|-----------|----------|
| [Package] | [who] | [who] | [who] | [who] |

### ⚠️ Top Execution Risks
| Risk | Likelihood | Impact | Mitigation | Owner |
|------|-----------|--------|------------|-------|
| [risk] | H / M / L | [what breaks] | [action] | [who] |

### 🔄 Resource Asks (Contract C → argument-craft)
| What's Needed | Why | Consequence of Not Getting It |
|--------------|-----|-------------------------------|
| [resource/time/scope change] | [risk or constraint] | [what fails or degrades] |

---

## Thinking Triggers

- *"What's on the critical path that I'm not seeing?"*
- *"Where are the integration points, and who owns the handoff?"*
- *"Am I estimating based on how long this took last time, or how long I wish it would take?"*
- *"What external dependency could blow up this timeline?"*
- *"If I had to cut scope to hit the deadline, which deliverables would I protect?"*

---

## Common Traps

**Activity-based milestones**: "Design phase complete" is not a milestone. "API schema reviewed and approved by consuming teams" is. Milestones must be observable from the outside.

**Estimating without decomposing**: "The project will take 3 months" is a guess. Break it down, estimate the pieces, and let the critical path tell you the timeline.

**Ignoring the planning fallacy**: Every team thinks they're the exception. Use reference-class data, not gut feel.

**No project buffer**: Individual estimates absorb individual variance. Project buffers absorb correlated risk — things that affect multiple tasks simultaneously (team member leaves, requirements change, integration is harder than expected).

**Single-point estimates**: "Takes 5 days" hides all uncertainty. Three-point estimates force you to confront what could go wrong.

**Phantom parallelism**: The plan shows tasks running in parallel, but the same three people are assigned to all of them. Resource-constrained scheduling is different from dependency-constrained scheduling.