Ranking by Expected Monetary Value on a Correlated Register

The arithmetic first, because it changes the answer:

• A: 0.12 × $2.1M = $252k per occurrence.
• B: 0.55 × $380k = $209k per occurrence - but it recurs across four remaining phases: 4 × $209k ≈ $836k expected exposure.
• C: 0.90 × $40k = $36k.

A naive single-occurrence ranking puts A first. Once recurrence is priced correctly, B is more than three times A. The ranking error is not in the EMV formula; it is in applying a per-occurrence figure to a repeating risk. That alone changes what the PM actions first.

The other problems:

• EMV hides severity and variance. A carries a three-week delay to commissioning, which may be a contractual milestone with liquidated damages attached. A low-probability, high-consequence risk should not be ranked below a high-probability nuisance just because the arithmetic says so. Expected value is not a proxy for importance.
• It ignores risk appetite and thresholds. Ranking is only meaningful against the tolerance levels defined in the risk management plan.
• It assumes linearity. Delay costs in construction are step functions - a missed commissioning date can trigger standing charges, remobilisation and penalty clauses - not a straight line from 'three weeks'.
• C is not really a risk. At 90% probability it is close to a certainty: it is a cost of doing business that belongs in the baseline, or a candidate for a process fix. Carrying it in the reserve distorts both the reserve and the ranking.

What I would do instead: a probability-impact matrix on calibrated money-and-weeks scales with agreed thresholds, alongside expected value, worst-case/tail, and schedule impact - ranked separately by objective (cost, schedule, compliance) and then combined by judgement against the sponsor's stated tolerance. EMV becomes one input to the decision, not the rule that makes it.

The correlation problem. Three risks driven by the same supplier's financial distress are not independent events.

• Summing them treats them as if they cannot co-occur and as if they are three separate exposures. If they are really one underlying driver with three symptoms, the sum double-counts.
• Simultaneously, it understates the tail, because the failure mode that matters is 'the supplier fails and all three land together', which a sum of independent expected values cannot express.
• Fix: either aggregate them into a single supplier-viability risk with a combined impact and a shared trigger, or keep them separate but model the underlying driver explicitly as a common correlated variable in the simulation. Either way, name the correlation assumption in the analysis.
• Supplier distress is a live condition, not a static assumption - re-test the correlation at every review, because the moment it becomes certain we are in a different activity (contingency execution), not risk analysis.

The reserve problem.

• Summing EMVs produces an expected value, which is by construction roughly a 50% confidence figure: half the time the actual outcome exceeds it. It is not a reserve sized to an acceptable confidence level, so it is not a reserve at all - it is a forecast with a coin-flip chance of being adequate.
• It also inherits every independence assumption and every duplicate in the register, so it compounds the errors above.

What to do: Monte Carlo over cost elements and discrete risks with correlated inputs, reading off P50/P80. Set the reserve at the confidence level the sponsor or PMO chooses - that is a risk-appetite decision, not the analyst's. Where modelling credibility is low, use scenario analysis on the supplier-failure branch plus a judgement-based buffer, clearly labelled as judgement.

2/17 ≈ 12%, so the arithmetic is consistent. That is the beginning of the review, not the end.

Reference class relevance. Were those 17 deployments comparable - same platform vintage, similar interface count, similar client-owned dependencies, same delivery team? If our project is first-of-kind for this client, the base rate may be a floor, not an estimate.

Sample size. Two events in 17 trials is a very thin basis. The plausible confidence interval around 12% runs from roughly 1.5% to about 36% - a range wide enough that A and B swap places depending on where the truth sits. Treating 12% as a precise number overstates what we know.

Independence and drift. Were the two slips related to each other or to a cause that has since been fixed (or introduced)? A vendor that has changed integrators, tooling or subcontractors may have a different rate now. The history describes the past vendor, not necessarily this one.

Anchoring. 'The team believes the number is right' is not evidence; it may be attachment to a number they produced. Test it by eliciting a P10/P50/P90 on the duration of the slippage rather than a bare probability, and see whether the implied distribution is consistent with 12%.

What the number is being used for. A probability is a judgement informed by frequency, not a frequency for a one-off event. It is defensible as an input to a range and to a schedule impact assessment; it is not defensible as a standalone figure that determines a ranking and a reserve line.

And the part EMV made invisible: a 12% chance of a three-week delay to commissioning. Even at 12%, I want the schedule consequence modelled and a contingent response named - because the impact is asymmetric and the cost impact alone does not capture the contractual exposure.