Milestone health: on schedule, delayed, severe delay — and what to do about each
A percentage complete tells you nothing on its own — 60% complete is fine at the halfway point of a milestone and alarming three-quarters of the way through it. Deriving schedule health from expected progress, not raw percentage, is what makes the number actionable.
A milestone at 60% complete is healthy, delayed or severely behind depending entirely on how much time has elapsed against its planned duration — the raw percentage alone cannot tell you which. Comparing actual progress to expected progress at this point in the timeline produces a health state that names the size of the problem and points at the intervention that fits it.
Almost every project dashboard shows a percentage-complete bar for each milestone, and almost every one of those bars is answering half a question. Sixty per cent complete is a fine place to be if the milestone is halfway through its planned duration. It is a serious problem if the milestone is three weeks from its deadline. The bar alone cannot distinguish the two, and a manager glancing at a portfolio of bars will read both situations as roughly the same.
Why percentage complete alone is meaningless
Percentage complete is a snapshot with no reference point. It answers 'how much is done' without answering the question that actually matters to a delivery date: 'is that enough, given how much time has passed?' A milestone can sit at an apparently reassuring 70% for weeks while quietly falling further behind every day, because 70% was itself already behind schedule the first time anyone looked.
Deriving health from expected vs actual progress
The fix is to calculate an expected-progress baseline from the milestone's planned start and end dates — if a milestone is 60% of the way through its calendar duration, expected progress is 60%, regardless of actual completion. Comparing actual percentage complete against that expected figure produces a variance, and the variance is what should drive the health label, not the raw completion number on its own.
| Health state | Variance (actual − expected) | What it usually means | Right intervention |
|---|---|---|---|
| On schedule | −5% to +5% | Progress is tracking the plan closely enough that normal week-to-week noise explains the gap | None — keep monitoring at the normal cadence |
| Delayed | −5% to −20% | A real slip has occurred, usually from one identifiable cause: a blocked ticket, a dependency, underestimated scope | Investigate the specific cause this week, before it compounds |
| Severe delay | Below −20% | The milestone is very unlikely to land on its planned date without a scope, resource or date change | Escalate for a decision — the plan itself needs to change, not just the effort |
A health label is not a judgement on the team. It is a measurement of distance between where the plan expected to be and where the work actually is, on a specific date.
The intervention that fits each state
Why this has to update automatically, sprint over sprint
Expected progress moves every single day a milestone is open, which means a health label calculated once at a status meeting is already stale by the next one. Recalculating it manually every week is exactly the kind of task that gets skipped when things get busy — which is precisely when a slipping milestone most needs to be caught. The health state has to be derived automatically from the milestone's dates and its live percentage complete, every time anyone looks at it, not refreshed on a schedule someone has to remember to run.
Once that is automatic, the label stops being a status someone reports and becomes a property of the data itself — visible the moment a milestone starts drifting, not two weeks later when someone finally rebuilds the report.
Goalz derives on schedule, delayed and severe delay states automatically from each milestone's dates and live progress — no manual status update required to catch a slip early.