project-delivery git:20260901.0757404A

Immutable. This exact content is served forever at /api/v1/blob/b32a679f9a9e89d7.

---
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.

## 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.