Amey-Thakur Milestone planning
A milestone is a checkpoint that demonstrates something works, not a date by which effort has been expended. Milestones defined by activity rather than outcome let a project be ninety percent complete for months.
Method
- Define each milestone by a demonstrable outcome. Something you can show or test, since design complete is unverifiable while a working end-to-end path is not.
- Front-load the risk. The first milestone should prove the most uncertain assumption, because learning it fails early is the whole point (see project-risk-management).
- Keep milestones close together. Two to four weeks apart, so a slipping project is visible within weeks rather than at the end.
- Build a thin end-to-end slice first. A narrow path through the whole system finds integration problems that layer-by-layer construction defers to the end.
- Make each independently valuable where possible. A project that delivers something at each milestone survives cancellation and reprioritisation.
- Do not move a milestone without a decision. Slipping dates silently is how a plan detaches from reality (see scope-change-control).
- Review at each one honestly. What was learned and whether the plan still holds, rather than only whether the date was met.
Boundaries
Milestones structure delivery; they cannot create certainty about work that is genuinely exploratory. Too many creates ceremony overhead. Milestone dates are estimates and inherit their uncertainty (see estimation-techniques).