By the time a project turns red, the decision that mattered has usually already been taken — quietly, weeks earlier, by someone who did not know they were taking it. A dependency slipped and nobody escalated. A key person moved to another programme. An assumption in the plan stopped being true and no one revisited it. The status report records the consequence, accurately and far too late.

This is not a failure of reporting discipline. It is a structural property of lagging measures. Schedule variance, cost variance and RAG status are all descriptions of a position the programme has already reached. They are indispensable for accountability and nearly useless for intervention.

What a leading indicator actually is

A leading indicator is a measure that moves before the outcome does, reliably enough to act on. That last clause does a lot of work. Plenty of metrics correlate loosely with trouble; very few move early enough, and consistently enough, to justify changing a plan.

The useful ones are usually unglamorous and already sitting in your existing tooling:

  • Ageing of unresolved dependencies between teams, rather than the count of them.
  • Rate of change in scope after a baseline is set, not the absolute amount of change.
  • Time between a risk being raised and an owner being assigned to it.
  • Variance between estimated and actual effort on completed work, trended rather than averaged.
  • Concentration of critical-path work on a small number of named individuals.

None of these requires new data collection. All of them are derivable from what delivery teams already record — which matters, because any indicator that depends on people filling in a new field will decay within two quarters.

If a measure only tells you what has already happened, it is a record, not a signal.

The threshold is the hard part

Choosing indicators is straightforward. Deciding what value of an indicator should trigger what action is where most implementations fail. Set the threshold too tight and the escalation path floods; people learn to ignore it within a month. Set it too loose and you have rebuilt the status report with extra steps.

We calibrate thresholds against historical delivery data before anything goes live — running the indicator backwards across completed programmes to see how often it would have fired, and how often it would have been right. An indicator that would have raised forty alerts last year to catch three real problems is not ready. One that would have raised five to catch three is worth putting in front of a delivery director.

Expect to retire indicators. Roughly a third of the ones we stand up in a pilot do not survive calibration, either because they fire too often or because the thing they predict was already visible elsewhere. Retiring them publicly is what keeps the remaining ones credible.

Escalation is the point

An indicator with no escalation path is a dashboard decoration. Each one needs a named owner, a defined action, and a forum where it is reviewed on a fixed cadence. The action does not have to be dramatic — often it is simply "the programme director has a fifteen-minute conversation with the dependency owner this week". What matters is that the signal reliably produces a human response.

The cultural shift this requires is larger than the technical one. Teams are used to escalation being a judgement about their performance. Leading indicators reframe it as a routine consequence of a measure crossing a line that everyone agreed in advance. That reframing is most of the benefit, and it is available whether or not a model is involved.

Where AI adds something

Models earn their place in two ways. They find combinations of indicators that predict trouble better than any single measure, which humans are poor at spotting across a large portfolio. And they hold the threshold steady over time, which humans are poor at doing under pressure.

What they do not do is replace the judgement about what to do next. The escalation still ends in a conversation between people who understand the programme. The model just makes sure that conversation happens while it can still change the outcome.