Milestones are the approval points that give a project its rhythm: they mark the transition between two phases and gate the move to the next one. A missed milestone is not something you catch up by working harder the following week. It pushes everything downstream.
What is it for?
Milestones take the progress of a project out of the implicit. Rather than pushing on continuously until the final presentation (where a missing part would only come to light late), they impose explicit stopping points where the team checks that it has actually produced what was needed before moving on.
Three inseparable roles:
- Formally closing a phase and clearing the move to the next one. An approved milestone commits the project. A missed milestone forces either catching up or renegotiating the scope.
- Forcing an approval appointment (CdCF review, PoC review, qualification review) that holds out against the drift of “let’s carry on, we’ll see”.
- Acting as time anchors for the backward plan and the Gantt chart: the project calendar is built around the milestones, not the other way round.
How do you set them?
Three steps:
- Identify the phase transitions of the project. On a V-model project the natural milestones are the CdCF review (cahier des charges fonctionnel, the French functional requirements specification), the concept approved, the PoC conclusive, the technical design file approved, integration delivered and the final presentation. That is the minimum skeleton. Finer ones can be added depending on what is at stake on the project.
- Fit the milestones onto the calendar by backward planning from the deadline. The milestones are the fixed points. The WBS tasks slot in between them.
- Attach a precise deliverable and a mode of approval to each milestone (team review, demo, document submitted for reading). The criterion has to make the milestone binary (passed / not passed), not a vague goal to be judged by eye on the day.
A worked case: a connected weather station project over 15 weeks.
Pitfalls
A milestone with no explicit approval criterion. A milestone reading “PoC done” cannot be used: who judges it, and against what? A milestone reading “PoC demonstrating the three axes synchronised under nominal load” can be approved. The criterion is set at the same time as the milestone, not afterwards.
Too many milestones. Half a dozen major milestones is enough on a school project. Beyond that the ritual wears out and loses its threshold effect. Each milestone becomes one step among others rather than a real stopping point that commits what follows.
Confusing a milestone with an internal deadline. One teammate delivering a subtask to another is not a milestone, it is an internal dependency. A milestone commits the phase change of the whole project, with outside approval (supervisor, client).
See also
- Technical specification — step 5, where the project milestones are set
- Project planning and tracking — the cross-cutting thread that keeps the milestones alive throughout the project
- Backward planning — planning back from the end, using the milestones as time anchors
- Gantt — the graphical tool that puts the milestones on the calendar
- WBS — breakdown of the project into tasks positioned between the milestones