project-delivery

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.

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.