project-delivery

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.