Walkthrough — Acme Platform Migration (PRQ)

The Acme Platform Migration register is the worked Monte Carlo example that ships inside PRQ: a $1.5M cloud migration carrying four risks and a modelled base-estimate spread, simulated over 10,000 iterations to a funded contingency. Open /prq in another tab and follow along; if you've edited the register since your first visit, hit Sample to reset back to it. Small as it is, the register exercises every PRQ mechanic: triangular and PERT distributions, a tornado that actually ranks something, and a convergence diagnostic that comes back green.

The concepts behind everything here are covered on Monte Carlo basics and probability distributions; the tool mechanics are on Using PRQ.

The four risks

Each risk in the register has a probability of occurrence (per iteration) and an impact distribution (a triangular or PERT triple of low / mode / high values).

1. Vendor SaaS dependency outage

Operational risk. Probability of occurrence: 30%. Impact distribution: triangular (TRI) $50,000 / $120,000 / $350,000.

Reading: in any given iteration, there's a 30% chance the vendor outage triggers; if it does, the impact is somewhere in the triangular range with the mode at $120,000. The bounds are realistic: small business-day disruption at the low end, multi-day SaaS-vendor outage with workflow knock-on at the high end.

2. Data migration schedule slip

Schedule risk. Probability: 50%. Distribution: PERT $75,000 / $200,000 / $500,000.

PERT was chosen here because schedule slips tend to cluster tightly near a most-likely value, and PERT puts more weight on the mode than triangular does. The 50% probability reflects that schedule slip is a near-coin-flip event for migration projects of this size.

3. Cyber incident during cutover

Technical risk. Probability: 10%. Distribution: triangular $200,000 / $600,000 / $1,500,000.

Low-probability, high-impact. Triangular keeps the bounds as hard limits; the wide spread (mode at $600k, max at $1.5M) reflects genuine uncertainty about how big a cutover-window cyber incident could get.

4. Regulatory approval delay

Regulatory risk. Probability: 20%. Distribution: PERT $30,000 / $80,000 / $250,000.

PERT, narrow spread. Regulatory delay impacts cluster around a well-understood per-day cost; the maximum captures the rare scenario where the delay extends past a budget cycle.

The fifth input: the base-estimate spread

The register also carries base-estimate uncertainty: each iteration, the engine samples a deviation from the $1.5M base (PERT, between −5% and +15%, most likely 0%) and adds it to that iteration's total. It models the base estimate itself being uncertain, asymmetrically towards overrun, separately from any named risk. On this register it contributes about $30,000 of the P50 and $40,000 of the P80: run the same register with it disabled and the P80 drops from about $429k to about $389k. The control lives in the project header (tick the checkbox to see or change the spread), and the PDF's methodology annex records whichever setting the run used.

What the simulation produces

Hit Run simulation at the default 10,000 iterations. It completes in well under a second and the results panel expands below the simulation block.

The figures below are exactly reproducible: hit Sample, enter 42 in the Seed field, run at 10,000 iterations, and your panel shows these numbers to the dollar (they're also locked to the engine by a test). Run unseeded and the figures move a percent or two between runs; the convergence line quantifies exactly how much.

• P50: about $230,000. Half of the simulated totals fell at or below this value.
• P80: about $429,000. The default funding level, which is a starting point rather than a recommendation: 80% of simulated totals fell at or below it.
• P90: about $630,000. Tail check. The gap from P80 to P90 (about $200k) tells you there's meaningful tail risk you're explicitly not funding at the P80 level.
• Mean: about $290,000. The arithmetic average of all 10,000 simulated totals.
• Std dev: about $300,000. Wide relative to the mean, reflecting the cyber-incident risk's fat tail.

Turning a percentile into money

Contingency at P80: about $429,000, or 28.6% of the $1.5M base estimate. That is the amount to carry on top of the base estimate so that 80% of the simulated outcomes fell at or below the funded line.

Read that sentence carefully, because the looser version is wrong in a way that matters. It is not an 80% chance the project comes in on budget. The distribution is of the four risks in this register plus the modelled base-estimate spread, so it says nothing about scope change, unmodelled estimating error, or anything nobody wrote down. It is a statement about the model, and it inherits every assumption the register was built on.

Which percentile you fund is a decision for the organisation rather than for whoever ran the model. PRQ defaults to P80 and lets you change it, because the level is an expression of risk appetite: the ISO 31000:2018 framework puts establishing "the amount and type of risk that may or may not be taken" with top management (clause 5.2). Australian public infrastructure generally works in P50 and P90 rather than P80. Switch the funding level on the results panel and every figure updates; the simulation does not re-run, because all of these percentiles came out of the same 10,000 iterations.

That is the real lesson in the 28.6% figure. The rule of thumb is not arbitrary, it just cannot tell you where it landed. Here the cyber incident's wide, hard-bounded impact range is what stretches the upper percentiles beyond what a flat percentage would suggest. The deterministic heuristic does not see that; the simulation does. The right next conversation is whether treatment could buy down the cyber-incident probability or its top-end impact.

Reading the tornado honestly

The sensitivity tornado ranks the four risks by the Spearman rank correlation between each risk's per-iteration contribution and the simulated total. On the default register, expect roughly:

1. Data migration schedule slip: about 45%. Top bar, in teal.
2. Cyber incident during cutover: about 32%.
3. Vendor SaaS dependency outage: about 18%.
4. Regulatory approval delay: about 5%.

If you expected the cyber incident on top, that instinct isn't wrong, it's answering a different question. An analytical variance decomposition of this register attributes most of the total variance to the cyber incident, because its impact range is so wide. The rank-correlation view asks instead "which risk moves the total from iteration to iteration?", and a 50%-probability risk switching on and off moves the total far more often than a 10%-probability one does, however heavy its tail. So the tornado points at the schedule slip as the strongest everyday driver, while the P80-to-P90 gap is mostly the cyber incident's doing. Both readings feed the treatment conversation: buy down the slip to move the middle of the distribution, buy down the cyber incident to pull in the tail.

Adding correlation: what changes, and what doesn't

The default run treats the four risks as independent. Correlation in PRQ applies to impact magnitudes: a positive entry means iterations where one risk lands high tend to be iterations where the other lands high too. It does not make risks trigger together; occurrence stays independent. Suppose the team judges that when the vendor outage bites hard the schedule slip tends to bite hard too, and likewise for a cyber incident and the slip: anchor both pairs at +0.3 (mild positive) in the "Correlation between risks" panel and re-run.

• The headline barely moves. On this register the P80 shifts by a few thousand dollars at most, within run-to-run noise. That is a finding, not a failure: most of this register's uncertainty is whether risks trigger at all, triggers stay independent, and correlating the magnitudes of risks that rarely coincide has little to correlate. Registers dominated by high-probability risks with wide ranges respond much more strongly.
• A correlation heatmap card appears after the charts, showing the pairwise rank correlations (teal positive, red negative, white independent), in the same palette the PDF report uses.
• The independence disclosure under the results flips to the rank-correlations wording, and the PDF's methodology annex records the correlation structure.

The general lesson survives the small number: aggregation is where correlation matters, and the honest way to find out what it does to your register is to run it both ways and look at the gap, exactly as you just did here.

Exporting the report

Hit Download PDF. The A4 portrait report opens with the brand cover and includes:

• Cover: project name, the headline narrative paragraph, metadata block.
• Executive summary: project metadata, key findings (mean, std dev, contingency at the funded percentile), full percentile grid.
• Distribution + S-curve: histogram and S-curve with P50 / P80 / P90 markers, drawn as vector so they print crisp.
• Sensitivity tornado: top contributors with the top bar in teal.
• Correlation heatmap: only if you specified correlations.
• Risk register: paginated table of every risk in the register.
• Methodology annex: run parameters, the correlation structure, the base-estimate uncertainty setting, the sensitivity method, distribution parameters per active risk, the independence notice, and tool and schema versions with the generation timestamp.