# Proj Plan Schedule

> Build a project plan and schedule with milestones, a critical path, and realistic buffers.

- Skill: `matrixx0070/proj-plan-schedule` (Agent Skill)
- Install (CLI): `npx skillmds@latest add matrixx0070/proj-plan-schedule`
- Raw SKILL.md: https://api.skillmd.com/api/skills/matrixx0070/proj-plan-schedule/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Matrixx0070 (https://skillmd.com/u/matrixx0070)
- Updated: 2026-09-08
- Page: https://skillmd.com/skills/matrixx0070/proj-plan-schedule

---


## When to use

Use this once scope is agreed (see `proj-charter`) and you need a credible timeline: what gets done in what order, which dates are load-bearing, and where the plan will break if something slips. Reach for it when someone asks "when will this ship?" and you want an answer backed by dependencies, not a guess.

**Not for:** deciding feature priority or roadmap sequencing by value (that is product-management — the plan takes the prioritized scope as input). Not for standing team cadence, ceremonies, or process documentation (that is operations). This is a delivery schedule for one project's actual work.

## Method

1. Decompose scope into deliverables, then into tasks small enough to estimate (roughly 0.5-5 days each). Decision point: any task over 5 days gets split — big tasks hide risk.
2. Estimate each task in effort (person-days), not calendar time, and record who does it.
3. Map dependencies: for each task list what must finish before it can start (finish-to-start by default).
4. Set milestones — externally meaningful checkpoints (demo, integration done, launch), not every task.
5. Compute the critical path: the longest dependency chain to the end date. Decision point: only tasks on the critical path move the finish date — protect those first.
6. Add buffers where uncertainty lives, not uniformly. Put a project buffer at the end and feeding buffers where side chains join the critical path. Decision point: high-novelty or external-dependency tasks get a bigger buffer; routine tasks get little.
7. Convert effort to calendar dates using real availability (meetings, PTO, part-time allocation), then publish milestone dates.
8. Re-baseline when scope changes via `proj-change-control`; track slippage against milestones in `proj-status-update`.

## Example

Tasks: design (3d) → build API (5d) → build UI (4d, needs API) → integrate (2d) → launch. Critical path = design+API+UI+integrate = 14 effort-days. At 80% availability that is ~18 calendar days; add a 3-day end buffer → 21 days. Milestones: "API done" day 8, "integrated" day 16, "launch" day 21.

## Pitfalls

- **Effort read as calendar.** 14 person-days is not 14 days on the wall. Divide by real availability.
- **Buffer smeared everywhere.** Padding every task invites Parkinson's law. Concentrate buffer at the end and at merge points.
- **No critical path.** Without it you protect the wrong tasks. Identify the longest chain explicitly.
- **Milestone-per-task.** Fifty milestones mean none. Reserve milestones for externally meaningful checkpoints.

## Output format

```
# Plan: <project>  BASELINE <date>
MILESTONES: M1 <name> <date> | M2 <name> <date> | ...
TASKS:
| id | task | owner | effort(d) | depends-on |
CRITICAL PATH: <task ids in order> = <n> days
BUFFERS: project=<n>d | feeding: <chain>=<n>d
AVAILABILITY: <n>%   FINISH: <date>
```