Chapter 5 – From risk register to simulation
The Quantitative Schedule Risk Analysis Handbook · Edition 1, August 2026 · by the team behind [Epoch SRA](https://epochsra.com), an Excel add-in for schedule risk analysis · corrections welcome at contact@epochsra.com
Every program keeps a risk register. Almost none of them are connected to the schedule. Likelihood and severity get scored, the heat map gets presented – and the finish date stays exactly where it was. That disconnect is the single cheapest thing to fix in most risk processes, because the register already contains the information a simulation needs.
What a register row really says
"Thermal-vacuum chamber availability. Likelihood 3, severity 2. Affects the [TVAC](/guide.html#tvac) test task." Read as simulation input, this row makes three claims: an event exists with some probability of occurring; if it occurs, a specific task gets longer; the impact has a rough magnitude. That is precisely the shape of a discrete risk overlay: a Bernoulli draw per iteration – does the risk fire in this future? – and, when it fires, days added to the mapped task, propagating through the network from there.
Note what the register does not say: which dates change. It cannot know – that depends on the network, the float, and every other risk firing or not in the same future. The simulation exists to compute exactly the consequence the register cannot state.
The mapping is the work
Connecting register to schedule means answering, for each risk: which task does this hit? In our experience this question exposes more process weakness than any audit. Risks mapped to nothing ("program-wide") are often risks nobody has thought through to a mechanism. A register where most rows map to specific tasks is a register that has been argued with – and arguing with the register is the point.
Two honest categories remain after mapping. Genuinely program-wide risks (a funding delay touches everything and nothing specifically) deserve the label. And risks that turn out, on inspection, to be issues – already happened – belong in an event log with recorded actuals, not in the probability space.
Scores are not probabilities – yet
A likelihood of "3" on a 5×5 grid is an ordinal judgment, not a percentage. Turning scores into simulation inputs requires a mapping – 3 means roughly such-and-such probability; severity 2 means roughly so-many days – and the quality of that mapping decides the honesty of everything downstream. Chapter 7 treats this fully; the short version is that mappings disciplined by historical outcomes beat mappings voted on in a meeting, and both beat the most common alternative, which is no mapping at all.
The trap to avoid at this stage is the seductive one: ranking risks by likelihood × severity and calling it analysis. That product ignores the network entirely. A modest risk on a zero-float chain into your integration event can move the finish more than a frightening risk sitting on 200 days of slack. Which risks actually matter is a measured question, and it is the next chapter's subject.
--- In practice: take your register's top three risks and write, next to each, the specific task ID it would delay and a days-range for the impact. If any of the three resists this exercise, you have learned something about that row – and about how ready the register is to inform dates.