Project planner

Project planner

Invocation: user only.

Turns "we should build X" into a plan someone can execute on. Different from /team-core:task-breakdown (which assumes a spec exists) and from /role-pgm:sprint-planner (which plans one iteration). This plans the whole project arc.

Six phases

Run them in order, not in parallel. Each one depends on decisions from the previous.

Phase 1 — Define success

Before any task, get agreement on:

• Outcome — what gets better for whom, in one sentence, measurable
• Success criteria — 3-5 specific, observable criteria. "Users can do X" not "the system works."
• Constraints — deadline, budget, headcount, technology, compliance, existing-code-to-reuse
• What this is NOT — explicit non-goals. Half of project drift is the team adding things no one asked for.

If any of these are fuzzy, stop and ask the user. A plan built on fuzzy success criteria plans the wrong work.

Phase 2 — Identify deliverables

What are the major outputs? Not tasks yet — outputs.

Typical project deliverables:

• A shippable product feature or capability
• A tested, reviewed PR or PR set
• Documentation (customer-facing and/or internal)
• A launch plan (comms, support prep, etc.)
• A post-launch metrics review

Each deliverable should be nameable and should align with a success criterion.

Phase 3 — Break into tasks

For each deliverable, break into tasks that:

• Take 2-8 hours of focused work
• Have clear completion criteria (how we'll know they're done)
• Are assignable to a single owner
• Avoid both mega-tasks ("build the API") and micro-tasks ("add the import statement")

Use the same rigor as /team-core:task-breakdown for each deliverable — vertical slicing, foundations first, verification every 2-3 tasks.

Phase 4 — Map dependencies

For each task, identify:

• Hard dependencies — must finish before this can start
• Soft dependencies — nice to sequence this way but not required
• Parallelization opportunities — tasks that can run simultaneously with different owners

Produce a dependency list. For projects <30 tasks a list is enough; for bigger ones, sketch a diagram in the output.

Identify the critical path — the longest chain of hard-dependencies. Anything on the critical path slips the project; anything off it is a scheduling convenience.

Phase 5 — Estimate and buffer

For each task, estimate effort in hours (for tasks) or days (for deliverables).

Then apply a contingency buffer:

• Greenfield work or lots of unknowns: 30% buffer
• Mixed — some known patterns, some new: 20% buffer
• Well-understood pattern, low risk: 15% buffer

Buffer the schedule, not individual tasks. Applying per-task buffer hides slack; a project-level buffer absorbs the normal cross-task variance.

If the user has historical data (velocity from prior projects), prefer that over abstract estimates. Ask for it.

Phase 6 — Assign and track

For each task, clarify:

• Owner (one person, not "the team")
• Reviewer (when the task has review or approval)
• Monitoring cadence — where updates live (Slack channel, Notion, standup), how often, which format

Flag tasks with no owner — those will slip silently.

Propose a monitoring rhythm:

• Daily: lightweight Slack updates from owners
• Weekly: /role-pgm:status-report draft to stakeholders
• At each checkpoint: verification before moving on

Output

# Project plan: <name>

**Owner (overall):** <person>
**Target completion:** <date>
**Status:** Draft — pending review

## Outcome
<one sentence, measurable>

## Success criteria
- [ ] <specific + observable>
- [ ] ...

## Non-goals
- <explicit exclusion>
- ...

## Constraints
- <deadline, budget, headcount, tech, compliance, reuse>

## Deliverables

### D1: <name>
**What:** <1 line>
**Success:** <which criterion this satisfies>
**Tasks:** <count, total effort>

### D2: ...

## Task breakdown

### D1 tasks

**T1.1: <task>**
- Owner: <person>
- Effort: <hours>
- Depends on: <none | T0.3>
- Completion: <how we know it's done>

**T1.2: <task>**
...

(Repeat per deliverable)

## Dependency map
<critical-path tasks listed. If >30 tasks, ASCII diagram or link to visual.>

## Schedule

- **Total effort:** <hours>
- **Buffer:** <%> → <total with buffer>
- **Sequenced duration:** <weeks, accounting for critical path and parallelism>
- **Target completion:** <date>
- **Key checkpoints:** <dates with what's verified at each>

## Risks

| Risk | Severity | Likelihood | Mitigation |
| --- | --- | --- | --- |
| <risk> | <L/M/H/C> | <P/L/NC> | <plan> |

## Monitoring
- Daily: <format, channel>
- Weekly: <status report to whom, via what>
- At checkpoint: <what's verified>

## Open questions before we start
- [ ] <question, owner, needed by>

Review and publish

Show the draft. Common edits:

• Tighten success criteria
• Re-scope deliverables
• Adjust buffer based on user's read of risk
• Move tasks between deliverables

On approval: publish to Notion under projects path, optionally post kickoff announcement to Slack via /team-core:draft-email flow, optionally open risk log entries via /role-pgm:risk-log add.

Don't

• Don't plan without agreed success criteria. Phase 1 is not skippable.
• Don't assign tasks to "the team." Every task has one owner.
• Don't omit the buffer. Zero-buffer plans miss their dates.
• Don't skip the non-goals section. Scope creep kills more projects than bad estimates.
• Don't turn this into /role-pgm:sprint-planner. This is the macro arc; sprints implement it.

---

Methodology inspired by the shubhamsaboo "project-planner" skill.