Milestone: a date that means something was finished

A milestone is a point where something is demonstrably done — a thing exists, a decision is made, an approval is given. It has no duration and no effort attached, which is exactly what makes it useful: a milestone is either met or not, and nobody can report it as seventy per cent complete. That binary quality is the entire value, and it is the first thing lost when plans are reported in percentages.

What makes a good milestone

• It is verifiable by somebody who was not doing the work — a document signed, an environment live, a payment received.
• It is binary. "Design mostly agreed" is a status, not a milestone.
• It matters to somebody outside the team, which is what gives it force.
• It sits at a point where the next phase genuinely depends on it rather than at a convenient calendar boundary.
• It carries a name describing the outcome, not the activity: "contract signed", not "contract work".

How many to have

Fewer than people expect. On a three-month piece of work, four or five is usually right; twenty turns the plan back into a task list and nothing is special any more. The useful test is whether missing it would prompt a conversation with somebody outside the team — if it would not, it is a task with a date rather than a milestone, and it belongs on the board without the ceremony.

Put payment and external commitments on milestones rather than on dates where you can. A milestone tied to a deliverable is far harder to argue about than a date tied to a calendar, both internally and with a client.

Why percentage-complete reporting is worse

Because it is unfalsifiable until the end. Work reported at ninety per cent for five consecutive weeks is the most familiar pattern in project management, and it happens because the figure is an estimate of an estimate with nothing to check it against. A milestone cannot do that: the document is signed or it is not. Percentages are useful for aggregating across a portfolio and useless for knowing whether one piece of work is in trouble — which is the question most status meetings are actually asking.

Using milestones honestly

1. Define the evidence for each one when you set it, not when you claim it.
2. Never move a milestone to make a report look better; move the date and record that you did.
3. Report met or not met, with the date it was actually met, rather than a status colour.
4. Review the sequence when one slips, because a missed milestone usually moves everything that depended on it along the critical path.
5. Keep the met dates after the work ends — that record is what makes the next estimate better than a guess.

Ettex Board treats the milestone as a card with no duration, so it sits in the sequence rather than in a separate schedule, and whether it was met is visible where the work lives. The evidence behind each one belongs with the project record rather than in the status report, because the report is read once and the evidence is asked for later.