A quantitative schedule risk analysis ends, in most reports, with a P80 date and a chart that ranks risks one at a time. Both answer the question the client asked. Neither explains the latest finishes, which is where a contractor's margin goes, or the combinations of risks that produce them.
This is written for planners who already run the analysis and want more from the result than a date to put in a letter.
A result is thousands of projects, not one
Every run of the simulation is a possible version of your project: a set of durations, a set of risks that happened or did not, and a finish date. A P80 says that eight runs in ten finished on or before that date. It says nothing about the other two in ten, and those two are the ones the contract was written to punish.
The tail is where the money goes
A run that finishes late carries three costs at once: the site that is still open, the delay damages that start when the date passes, and the overhead of the people who stayed to finish. A run in the tail pays all three for the longest time. Averaging it into a single date hides the fact that the project's worst outcomes are also its most expensive ones, by a wide margin.
Risks are ranked one at a time. Overruns come from combinations.
The usual chart answers “which risk, removed on its own, moves the date most”. That is a fair question with a misleading answer, because the runs in the tail are rarely there because of one risk. They are there because two or three risks landed in the same run, on the same path, in the same window. Remove the top-ranked risk and the tail barely moves, because the combination that produced it is still possible.
| Risks that happened together | Share of the worst tenth of runs | Median days late |
|---|---|---|
| Late valves + crane extension refused | 31 of 100 | 38 |
| Late valves + hydrotest failure | 22 of 100 | 34 |
| Ground conditions + late valves | 17 of 100 | 29 |
| Any single risk alone | 9 of 100 | 12 |
Group the worst runs by what happened in them
The useful analysis is the reverse of the chart. Take the worst tenth of the runs and ask which risks occurred in each. Group them. The groups are your real exposure, and each one points at a piece of schedule logic: a dependency that lets two risks stack, a buffer in the wrong place, a package with no float because somebody optimised it away.
This is the work Verian does when it reads a risk analysis: it groups the tail by the risks that produced it, names the activities those risks sit on, and says, in plain words, what change to the logic would separate them. The planner decides whether to make the change. The figures come from the simulation, not from the model that writes the sentence.
Two humps are two projects
Sometimes the distribution has two peaks. That is not noise. It usually means one risk is so large that the project is a different project when it happens: one mode where the permit arrives on time, one where it does not. Reporting a P80 across both is reporting the average of two things that never both occur. Present them separately, with the probability of each, and let the client see the choice.
Check that the buffer sits where the risk is
A buffer at the end of the schedule protects the date on paper. The tail tells you which path actually needs it. If the runs in the worst tenth share a path, the buffer belongs on that path, before the activities that the stacked risks hit, not at the end where it protects everything equally and nothing in particular.
- Read the shape, not the P80.
- Take the worst tenth of runs and group them by the risks that happened in them.
- Treat each group as a logic problem, not a risk-register problem.
- Report two peaks as two projects.
- Move the buffer to the path the tail names.