---
name: project-delivery
description: Plans and delivers a single project — scope, estimation, scheduling, critical path, tracking, and recovering when it slips. Use this to plan a project, build or challenge a schedule, estimate credibly, track progress meaningfully, or recover a project that is late.
---

# Project delivery

A project is one bounded piece of work with an end. Coordinating several toward a shared outcome is
`pmo:program-management`.

## Scope by exclusion

Inclusions are agreed easily and understood differently. The exclusions do the work: what this
project will *not* deliver, written down and acknowledged by the sponsor.

Unwritten exclusions return as assumptions, always late, always framed as something obviously
included. Fixing that at the end is called scope creep; it is usually a documentation failure at the
start.

## Estimate as a range, and say what the range means

A single-point estimate is a forecast presented as a commitment. Give a range with the assumptions
that would move it, and be explicit about confidence.

Estimate the work, not the desired date. Estimates negotiated downward do not change the work; they
change when you find out, and the finding-out happens at the least recoverable moment.

Decompose until the pieces are comprehensible. Estimating a large unknown produces a number
correlated with optimism rather than with the work.

## The critical path is where attention belongs

Not everything late matters. Slippage on the critical path moves the end date; slippage elsewhere
consumes float. Knowing which is which is the difference between useful concern and generalised
anxiety.

Recalculate as things change — the critical path moves, and a team watching the original one is
watching the wrong thing.

Hold buffer at the project level rather than padding each task. Padded tasks absorb their own buffer
and deliver no earlier, because work expands and nobody reports finishing early.

## Track completion, not effort

Percentage complete is self-reported optimism, and it famously stalls at 90%. Track binary completion
of defined deliverables — done or not done, judged against a definition agreed in advance.

Watch the trend: whether the amount remaining is falling at the rate required. A project where
remaining work is not decreasing is a project that is late, whatever the reported percentage.

## Recovery

Diagnose first, since remedies do not overlap: scope larger than understood, capacity lower than
planned, dependencies not delivering, or an estimate that was never realistic.

Then present options with consequences — cut scope and name what, extend and say by how much, or add
capacity, which late in a project usually slows things further. Re-baseline once, visibly. Serial
one-week slips destroy credibility far faster than a single honest reset.

## Change control is what makes the scope statement mean anything

A scope boundary that anyone can move in a conversation is not a boundary. Change control is the
mechanism that turns it into one, and it needs to be light enough that people use it rather than
route around it.

- **A change is anything that moves scope, date, or cost** — including work that arrives described
  as a clarification. Most scope creep enters as a series of small reasonable requests, none of
  which was ever assessed against the whole.
- **Assess impact on all three before deciding.** "Yes, and it adds two weeks" is a decision
  someone can make. "Yes" alone is how a plan quietly stops being achievable.
- **The person who can approve a change is the person who owns the consequence.** If the sponsor
  approves scope but the team absorbs the date, changes will keep being approved.
- **Log rejected changes too.** The record of what was declined is what stops the same request
  arriving three more times, and it is the honest answer when someone asks why a feature is missing.

Re-baseline when an approved change makes the old plan meaningless, and not otherwise. A baseline
re-set to hide variance destroys the only reference you had.

## Sources

`references/sources.md` in this skill lists the outside authorities that settle the questions
here — what each one is authoritative for, and what you may do with it. Check them before
answering on anything they cover, and cite what you used. Most are free to read and not free
to reproduce; the use note on each is binding.

## Tooling

Delivery tracking: Jira, Asana, Linear, Monday.com, Smartsheet, Microsoft Project, and
similar.

Portfolio and capacity: Jira Align, Planview, Adaptive Work, and similar. Worth it when you
are reconciling many teams' plans against one capacity pool, not before.

The tool records the plan; it does not make the plan true. A status field nobody updates
between meetings is worse than no field at all.

## Never

- Agree scope without written exclusions.
- Present a single-point estimate as a commitment.
- Report progress as percentage complete.
- Add people to a late project and expect it to accelerate.