HomeGuides › Milestones

Milestones that mean something

Milestone dates are usually typed into a plan directly, which makes them wishes rather than forecasts.

A milestone is a conclusion, not a date

The date that matters is the one the work implies. A date typed in by hand agrees with the plan only by coincidence, and it keeps agreeing right up until somebody checks.

Deriving the forecast from the prerequisites means the milestone cannot drift out of agreement with the schedule. When target and forecast diverge, that is visible immediately rather than at the review where it is discovered.

Zero duration, real meaning

A milestone consumes no time. It marks an instant — a decision made, a thing accepted, a gate passed — and adds nothing to the project's length.

That is what makes them right for external commitments: they are points where something must be true, without implying anything about how the work leading to them is arranged.

Acceptance criteria stop the argument

"Design complete" means different things to the person who drew it and the person who must build from it. Without written criteria, a milestone is declared complete by whoever is under the most pressure to declare it.

The criteria need not be elaborate. They need to be specific enough that two people can disagree and settle it by looking.

Too many milestones is the same as none

A milestone every week has become progress reporting. They work because they are few and consequential — points where a real decision is made or a real commitment falls due.

Ten in a year that everyone can name beats fifty nobody can.

Milestone, deliverable, gate

These get used interchangeably and they are three different things. A deliverable is an artefact — a document, a build, a signed contract. A milestone is a moment something becomes true, which usually means a deliverable has been accepted rather than merely produced. A gate is a decision point where the work can be stopped, changed or funded further.

Conflating them is what produces a plan full of milestones that nobody can act on. "Draft submitted" is a deliverable pretending to be a milestone: it can be true while the thing is unusable. "Draft accepted by the client" is a milestone, because something changed for everyone downstream. And if the answer to "what happens if we do not hit this?" is "nothing, we carry on", it was never a gate.

Why milestones slip quietly

A milestone has no duration of its own, so it cannot be late by itself — it inherits every delay in everything feeding it. That makes it the last place a problem shows up rather than the first, and by the time the date moves, the cause is weeks old. The date is a symptom.

The second reason is ownership. A task with no owner gets noticed because somebody has to do it. A milestone with no owner is just a date in a document, and dates do not defend themselves. Naming a person who is accountable for the milestone — not for the work feeding it, for the milestone — is what turns it into something with a defender, and it is usually the difference between finding out early and finding out at the review.

Open the tool →