Ordering Work by Risk-Adjusted Value

There is a moment on most capital programmes where someone says, reasonably, that the team should start with the parts people can see. The portal before the data migration. The station finishes before the utility relocation. It feels like momentum, and it produces a period where everything reported is green while every genuinely hard question remains unanswered.

Then the hard question arrives, and it arrives after the money is committed.

What is wrong with sequencing by value?

Nothing, as far as it goes. The problem is that value and uncertainty are different axes, and most prioritization sessions only have one of them on the wall.

Value estimates are conditional on the plan holding. They describe what a piece of work is worth if it goes roughly as expected. The items that threaten that condition are usually the ones with the weakest value narrative: a geotechnical investigation demonstrates nothing to a stakeholder, a legacy data migration has no demo, an environmental permit produces no visible artifact. Rank by value and those items sink, every time, without anyone deciding to deprioritize them.

Flyvbjerg's work on public infrastructure documents the downstream shape of that pattern: systematic and persistent cost underestimation across hundreds of projects, at a scale that ordinary estimating error does not explain. Kahneman and Tversky supplied the mechanism decades earlier, describing how inside-view planning produces forecasts anchored to the intended path rather than to the distribution of outcomes. A value-ordered sequence is an inside-view instrument. It assumes the path.

What should you order by instead?

Here is where the popular version of this idea goes wrong, and it is worth being precise because the imprecise version is what gets people into trouble.

The common formulation is tackle the biggest risks first, usually operationalized by reading the top bars off a tornado diagram. That is close, and it is not right. The formal criterion, established by Howard in 1966, is the expected value of information: an observation is worth making to the extent that it changes what you would optimally do. An uncertainty can be enormous and still be worth nothing to resolve early, if the answer would not change a single decision. Conversely a modest uncertainty that flips a commitment is worth resolving immediately.

So the sequencing question has two parts, not one. First, how large is the uncertainty. Second, and more important, would resolving it change what we do. Letier, Stefan and Barr applied exactly this reasoning to prioritizing software requirements and architecture decisions, and Feather and Cornford built a quantitative risk-based method for reasoning about requirements on the same logic.

In practice this produces three buckets from the top of a sensitivity ranking:

• Large, resolvable, decision-changing. These go into the next cycle of work. This is the real de-risking sequence, and it is usually shorter than people expect.
• Large, but not resolvable now. A market movement, a regulatory outcome, weather. These belong in contingency, not in the sequence. Scheduling work against them is theatre.
• Large, resolvable, but not decision-changing. The answer is interesting and nothing turns on it. Resolve when convenient. This bucket is the one teams most often mistake for urgent, because the number is big.

Why does a tornado diagram not answer this by itself?

Because it ranks inputs by how much they move the outcome, which is a statement about the model rather than about your options. It tells you where the variance lives. It does not tell you whether you can do anything about it this quarter, or whether knowing the answer would alter a commitment.

There is a further caution worth carrying. Cox showed formally that ordinal risk rankings have limited resolution and can, under specifiable conditions, invert the true quantitative ordering, particularly where probability and consequence are negatively correlated. A ranking is a starting point for a conversation about sequence, not an output you can schedule against directly. That argument is made in full in Are Risk Matrices Valid.

Is this just risk-driven development renamed?

It is the same instinct, and saying so is a strength rather than an admission. Boehm set it out in 1988. The spiral model, in his words, “creates a risk-driven approach to the software process rather than a primarily document-driven or code-driven process,” and it deliberately “defer[s] detailed elaboration of low-risk software elements and avoid[s] unnecessary breakage in their design until the high-risk elements of the design are stabilized.” He added that once risks are evaluated, “the next step is determined by the relative remaining risks.” That is this article's thesis, written thirty-eight years ago, for software.

What has changed is not the principle but the instrument. Boehm's teams assessed relative remaining risk by judgment. A programme running a quantified cost and schedule model can put a number on it, test the ordering, and re-derive the sequence as the distribution moves. The idea is old. Pointing it at a simulation is not.

What does this look like on a capital programme?

The translation is more literal than people expect. Take the drivers accounting for most of the modelled variance. Filter them through the resolvable and decision-changing tests. What survives becomes the near-term work, ahead of items with a better value story.

The sponsor conversation is the hard part, because the honest version of it is: for the next two cycles you will see less visible progress than you would have, and in exchange the number that goes to the board afterwards will be defensible. That trade is easy to describe and unpleasant to sit through, which is why it usually needs to be agreed before the sequence is set rather than defended afterwards.

The payoff is measurable, and it is the same mechanism described in What P80 Means. Resolving a high variance item removes its spread from the model. The distribution narrows, the percentile pulls toward the baseline, and the contingency arithmetic changes in your favour. De-risking first is not merely prudent, it is the thing that lets you hand money back.

Why is this an Attention problem?

Because sequencing is the purest expression of what an organization is actually paying attention to, and the default is always the visible.

No leadership team decides to defer its hardest unknowns. It happens because the prioritization ritual only asks one question, because the items that would surface are the ones nobody can demo, and because the person who would raise them is often the person with the least standing in the room. The register may well contain every one of those risks, correctly rated. Nothing in the process brings them to the moment where sequence is decided, which is the same failure described in The Risk Register Nobody Reads, applied to the calendar instead of the document.

ISO 31000:2018 puts the underlying obligation plainly in stating that risk management should be based on the best available information. A sequence chosen without reference to the model is not using the best available information, however good the model is.

Evidence matrix

What to do with this

At the next prioritization session, add one column to whatever board you already use, and label it: what decision does this change, and when. Anything that cannot answer it is not a de-risking activity, whatever its rating says. Then take the top drivers off the model and place them explicitly, in front of the sponsor, against the items they are displacing. Making the displacement visible is what turns this from a technique into a decision.