execution-planning

name

execution-planning

description

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.

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.