How Often Should You Re-Run a Risk Analysis?

A practitioner posted the question plainly on a project controls forum: how often should a quantitative schedule risk analysis be carried out, and is there a guideline or reference anyone can point to? The thread ran to eight replies. Weekly, monthly, quarterly, six-monthly, and at milestone gates were all proposed with equal confidence. Nobody cited anything, because there is nothing to cite.

I went looking for that citation properly, expecting to find it behind an AACE paywall. It is not there either. There is no peer-reviewed study establishing an optimal re-analysis frequency for cost or schedule risk during execution. That absence is worth stating out loud, because the profession has been answering the question as though the answer were known.

Why is the cadence question unanswerable?

Because it asks about the wrong variable. A re-analysis is worth running when the model would come back different, and what makes a model come back different is not elapsed time. It is a change in the underlying uncertainty.

Consider two programmes, both three months past their last re-forecast. One has completed a high variance geotechnical investigation, closed two of its top five risk drivers, and had a permit approved early. The other has held steady on a long sequence of low variance activities and learned nothing new. A quarterly cadence re-runs both. Only one of them will produce a materially different curve, and the other consumed a modelling cycle to confirm what everyone already knew.

Now reverse it. A programme two weeks past its last re-forecast discovers that its critical procurement has slipped and the vendor is disputing scope. Under a quarterly cadence, that programme waits ten weeks to learn what the delay does to its P80, which is ten weeks of decisions made against a number everybody in the room knows is wrong.

What does the research actually support?

The closest thing to an evidence base is not about re-analysis frequency at all. It is about when to act on control information, which is the adjacent question and turns out to be more useful.

Vanhoucke examined the dynamic use of project performance and schedule risk information during tracking, and found that dynamic thresholds for triggering corrective action outperform static ones. He also found something that should change how a programme sets up its control regime in the first place: the better tracking approach depends on the topology of the schedule network. Serial networks respond better to top-down earned value control, while parallel networks respond better to bottom-up schedule risk analysis. A follow-up study measured control efficiency across both fictitious and empirical project data.

Two things follow. First, the profession already has evidence that condition-based triggering beats calendar-based triggering in the closely related problem of when to intervene, and there is no obvious reason the logic would reverse for when to re-measure. Second, the right answer is programme-specific in a way a universal cadence cannot capture, because it depends on the shape of the network.

What should actually trigger a re-analysis?

Four categories, each defined by the fact that it changes the distribution rather than merely the progress report.

A high variance item resolves

When an item that carried significant spread is completed or retired, its uncertainty leaves the model. The distribution narrows and the percentile pulls in toward the baseline. This is the trigger organizations most often miss, because nothing has gone wrong, so nobody thinks to look. It is also the only trigger that produces good news, and the one that justifies releasing contingency on evidence rather than on optimism.

An activity passes its most likely duration

The moment an activity runs beyond the most likely value it was given, the three-point estimate that fed the model is known to be wrong for that item. Waiting for the activity to finish before updating discards the warning at exactly the point it still has option value.

Scope changes

A scope change moves the baseline the distribution is measured against. The old percentile is not stale, it is describing a different project. No amount of re-running the old model fixes that; the model has to be rebuilt against the new baseline.

A material new risk is identified

A newly identified risk with meaningful consequence changes the model whether or not it has occurred. This is the trigger most dependent on the organization actually surfacing risks, which is a conditions problem before it is a modelling one, and which is why The Risk Register Nobody Reads is upstream of everything on this page.

Notice what is not on the list. The end of a month is not on the list. A board meeting is not on the list. Both are perfectly good reasons to report the current number, and neither is a reason to recompute it.

Does that mean cadence is useless?

No, and this is where the practical answer lands. A trigger-based regime needs a floor, for the same reason a smoke alarm needs a test schedule: triggers depend on someone noticing, and noticing degrades.

So set a minimum interval as a backstop rather than as the mechanism. If nothing has triggered a re-analysis in a defined period, re-run it anyway, and treat the fact that nothing triggered as itself a finding worth examining. On most capital programmes I would set that floor at the reporting cycle the governance body already runs on, which makes it free to administer. The distinction matters: the floor is there to catch a failure of attention, not to be the reason the model gets updated.

What does the standing literature say about the cycle?

That risk management is a loop is not in dispute, and it is older than most of the frameworks that claim it. The Software Engineering Institute at Carnegie Mellon published its continuous risk management model in 1996, built on six repeating functions: identify, analyze, plan, track, control, and communicate. NASA adopted the same structure and states in its agency risk management requirement that risk management includes two complementary processes, Risk-Informed Decision Making and Continuous Risk Management.

ISO 31000:2018 makes the same point as a principle rather than a process. Clause 4(e) states that risks can emerge, change or disappear as an organization's context changes, and that risk management anticipates, detects, acknowledges and responds to those changes in an appropriate and timely manner. Clause 4(h) adds that risk management is continually improved through learning and experience.

All of that establishes the loop. None of it establishes a clock speed, which is precisely the gap this article is about.

Why is this an Adaptability problem?

Because the constraint is almost never the simulation. Re-running a model is a few hours of work for someone who already has it built. What stops organizations re-forecasting is that the answer might be unwelcome, and that nobody has decided in advance what will happen when it is.

An organization that has not agreed what a moved P80 obliges it to do will avoid producing one. That avoidance never announces itself; it shows up as a re-analysis that keeps slipping down the priority list, a model whose owner has moved to another programme, and a number in the board pack that has not changed in four quarters. The technical capability is intact. The condition that would let the organization use it is not.

The test is simple and worth applying honestly. When the re-forecast last moved against you, what happened? If the answer is that the number was revised and the plan was not, the cadence question was never the real one.

Evidence matrix

What to do with this

Write down the four triggers, name who is responsible for spotting each one, and set a backstop interval tied to the governance cycle you already run. Then answer the question that decides whether any of it matters: when the number moves against you, what changes? If nobody can say, fix that before fixing the cadence.