A Health Check That Changed the Outcome — A Worked Example

This is an illustrative example. The scenario and figures are composed to show the method, not drawn from a named engagement.

A replacement customer portal, eight months in on a twelve-month plan. Status reports have been green since month four. The sponsor is comfortable.

The delivery manager runs the health check because something feels wrong and she cannot say what.

Question 1 — would you bet on the end date?#

Asked of herself, honestly: no.

Asked of the three team leads separately, so they were not answering in front of each other: no, no, and "probably not".

Nobody had said so. Not because anyone was concealing anything — each had reasons that sounded manageable in isolation, and none felt like the moment to escalate.

That is the finding the rest of the check exists to explain.

Question 2 — progress measured how?#

The report tracked effort spent against plan: 68% of budgeted days used, 70% of the timeline elapsed. Green.

Recounted as completed and accepted work: 41% of the scope had been accepted by the business.

The two numbers had been diverging since month five and nobody was tracking the second one, so nothing surfaced the gap.

Question 3 — the ageing items#

The nine-day decision latency was the one that changed the conversation. The team ran two-week iterations. A decision taking nine days meant most iterations contained a stall, and the team had adapted by working around blockers rather than escalating them — which made the delay invisible in the reporting.

Question 4 — what changed since baseline?#

Fourteen approved changes. Each assessed on its own, each individually reasonable, each approved by the sponsor.

Nobody had added them up:

The sponsor had approved nine weeks of additional work without ever being shown that figure, because it had only ever been presented one change at a time.

Question 5 — testing#

Testing was scheduled to begin in month ten. Nothing substantial had been tested. Integration with the two upstream systems had not been attempted.

Deferred integration and deferred testing are the two most reliable predictors of a late finish, and both were present.

What the check produced#

Not a colour. Three numbers the sponsor had never seen: 41% accepted against 70% elapsed, +9 weeks of approved change, and 9 days to get a decision.

The two decisions#

Decision 1 — scope. Presented with the arithmetic, the sponsor cut two of the fourteen changes and deferred a further three to a second phase. That recovered roughly five weeks.

Decision 2 — decision latency. The sponsor delegated approval below a threshold to the product owner, and committed to a standing 30-minute slot twice a week for anything above it. Decision time fell from nine days to under two within a month.

The second decision cost nothing and was worth more than the first.

The outcome#

Delivered six weeks later than the original date, with an agreed reduced scope, and the sponsor knew about it in month eight rather than month eleven.

That is what a health check is for. It did not make the project faster; it made the situation visible while there was still room to act.

What transfers#

Ask the direct question, separately, of several people. "Would you bet on this date?" produces answers that a status meeting does not.

Measure accepted work, not effort spent. They diverge quietly and only one of them predicts a date.

Add up the changes. Sponsors approve individually reasonable things. The aggregate is rarely what they intended, and they are generally grateful to see it.

Treat decision latency as a project metric. If the team waits nine days for answers, no delivery improvement changes the outcome.

See project management, the health check, and the status report template built so these numbers appear without anyone volunteering them.

Back to Project Management