plan

Plan

When to use it

• User asks "plan this" or "how should I approach" a task.
• Task has more than three steps or involves multiple dependencies.
• Starting a new project, feature, or complex analysis.
• Need to estimate effort, identify risks, or allocate resources.
• Before writing code, creating content, or running experiments.

When NOT to use it

• Single-step or trivial tasks (e.g., "rename this file").
• Emergency fixes requiring immediate action.
• Tasks already covered by an existing, validated plan.
• Purely exploratory questions with no deliverable.

Prerequisites

• Clear goal or problem statement.
• Access to relevant context (requirements, constraints, existing artifacts).
• Ability to break work into discrete, verifiable steps.

Procedure

1. Capture the goal

Write a one-sentence outcome statement. Include success criteria (measurable, time-bound).

1. List constraints and assumptions

Document hard limits (budget, deadline, tools, personnel) and assumptions (availability, data quality, external dependencies).

1. Identify major workstreams

Decompose the goal into 3-7 high-level phases. Each phase must produce a tangible artifact or milestone.

1. Break phases into tasks

For each phase, list atomic tasks. Each task must:

• Have a single owner (even if the owner is "self").
• Be estimable in hours or days.
• Have a clear definition of done.

1. Sequence tasks and find dependencies

Draw a directed acyclic graph (DAG) or simple list showing which tasks block others. Mark critical-path tasks.

1. Estimate effort and duration

Assign optimistic, realistic, and pessimistic estimates (in hours) to each task. Compute weighted average: (O + 4R + P) / 6.

1. Assess risks and mitigations

For each critical-path task, list top 2 risks (probability × impact) and a concrete mitigation action.

1. Create a timeline

Convert estimates into calendar dates using available capacity. Include buffer (15-20% of total estimate) after the last critical-path task.

1. Define checkpoints and reviews

Schedule a sync at the end of each phase. Specify what artifact is reviewed and who approves.

1. Produce the plan document

Compile sections 1-9 into a single Markdown file. Use tables for tasks, timeline, and risks. Save as plan-<slug>.md.

1. Validate with stakeholders

Share the plan. Collect written approval or recorded objections before execution starts.

1. Maintain the plan

Update the document at every checkpoint. Log actuals vs estimates, new risks, and scope changes. Version the file (v1.0, v1.1, …).

Rules and constraints

• Every task must have a verifiable definition of done.
• No task longer than 16 hours; split further if needed.
• Critical-path tasks must have a named owner and a mitigation.
• Buffer is mandatory; zero-buffer plans are rejected.
• Plan document must be version-controlled and accessible to all participants.
• Do not start execution until step 11 is complete.

Examples

Input

Goal: "Migrate the user-authentication service from monolith to a standalone Go microservice within 4 weeks."

Expected output

A Markdown file plan-auth-migration.md containing:

• Outcome: "Standalone auth service handling 100% of login traffic with <50ms p99 latency by 2025-08-15."
• Constraints: 2 engineers, existing PostgreSQL, zero-downtime requirement.
• Phases: 1) Design API contract, 2) Implement service, 3) Integration tests, 4) Canary deploy, 5) Full cutover.
• Task table with owners, estimates, dependencies.
• Risk table: "DB migration latency" (high), mitigation: "dual-write + backfill script".
• Timeline with dates, 20% buffer, checkpoints every Friday.
• Signed approval from tech lead and product manager.

Common mistakes

• Skipping risk assessment → surprises during execution.
• Tasks too large (>16h) → hidden complexity, inaccurate tracking.
• No buffer → any slip cascades into deadline miss.
• Missing definition of done → ambiguous completion, rework.
• Not versioning the plan → loss of decision history.

Final checklist

• [ ] Outcome statement is measurable and time-bound.
• [ ] All tasks have owner, estimate, definition of done.
• [ ] Critical path identified and buffered.
• [ ] Risks have probability, impact, and mitigation.
• [ ] Stakeholder approval recorded.
• [ ] Plan saved in version control with clear naming.