Using Project Risk Quantification
PRQ runs a Monte Carlo cost-risk simulation against a register of project risks. Open it at /prq and you land on the Acme Platform Migration sample register: four risks against a $1.5M base estimate. Edit it in place to see the engine respond, hit Sample to reset back to it, or New to start a blank register (your /account company and default risk matrix pre-fill when you have them).
This guide assumes you understand Monte Carlo basics. If not, start with Monte Carlo basics for project risk and Probability distributions in PRQ first.
The project header
Three fields, all editable inline:
- Project name: appears in exports, the PDF cover, and the headline narrative paragraph.
- Base estimate (optional): the cost figure the contingency is calculated against. PRQ runs without one, but the contingency callout and the convergence diagnostic both lean on it. With no base estimate the results show total exposure rather than contingency above base, and convergence is measured against the P90 value itself.
- Currency: USD, AUD, EUR, GBP or JPY. Drives the formatting of every numeric output. Internal storage is unitless; switching currency changes the label, not the numbers.
The project header also carries base-estimate uncertainty: a spread around the base estimate that the engine samples each iteration and adds to the totals. Tick the checkbox to enable it, pick a shape (PERT, triangular or uniform) and set the bounds as percentages of base. The sample register ships with it enabled (PERT −5% / 0% / +15% of base), and the PDF's methodology annex records the setting for whichever register was run. It is a simulation input, so editing it invalidates a completed run.
The risk register
Each row is a risk with four properties:
- Risk name: short identifier.
- Category: Technical, Commercial, Schedule, Operational, Financial, Regulatory, External, Management or Other. Descriptive metadata carried into the report and exports; it doesn't affect the simulation.
- Probability of occurrence: the chance, per simulation iteration, that this risk triggers. A 30% probability means in any one iteration there's a 30% chance the risk fires and contributes its impact to the iteration's total.
- Impact distribution: the family of values the impact could take if the risk does trigger. Triangular, PERT and fixed are the workshop defaults; lognormal (elicited as median and P90 in dollars), normal and uniform sit on the specialist shelf (see probability distributions for when each is the honest choice).
Click a risk's name (or the pencil icon) to edit it. Hit Add risk to add a new one, and the bin icon to delete. The header above the table tracks "active in the simulation": risks without both a probability and an impact distribution are kept in the register but excluded from the run.
Correlation between risks (optional)
Below the register is a collapsed "Correlation between risks" row. Open it to specify pairwise rank correlations between the active risks. The matrix is K×K (K being the number of active risks), with the upper triangle editable; the lower triangle mirrors automatically and the diagonal is pinned at 1.0.
Correlation here applies to impact magnitudes: when two risks are positively correlated, iterations where one lands high tend to be iterations where the other lands high too. It does not make risks trigger together; occurrence stays independent. The methodology page covers why that distinction matters and what correlation does to the tail.
Use anchor values: −0.3 mild negative, 0 independent, +0.3 mild positive, +0.6 strong positive. Workshop-based judgement is usually the right input source; arbitrary numbers are worse than leaving the matrix as identity.
Validation runs on every change. If your matrix isn't positive semi-definite (which can happen when you specify incompatible pairwise correlations), the panel surfaces the smallest eigenvalue and offers Apply nearest valid correction, the Higham nearest-correlation-matrix method. The correction preserves the structure as best it can while making the matrix valid.
Choosing iteration count
The simulation block exposes presets: 1,000 / 5,000 / 10,000 / 25,000 / 50,000. The default is 10,000, which is enough for stable P50 to P90 figures on most registers. Fewer iterations run faster and are fine for rapid what-if tuning in a workshop, but the percentiles will wander between runs. More iterations tighten the far tail (P95 and beyond) for tail-sensitive analyses.
You don't have to guess: the convergence badge in the results view measures whether your iteration count was enough for the register you actually ran. If it reads "Marginal", bump to the next preset and re-run.
Next to the iteration preset is an optional Seed field. Leave it blank for an ordinary run; enter any whole number and the run becomes exactly reproducible: same seed, same register, same figures, which is what lets a reviewer rebuild the number in front of them.
Running the simulation
Click Run simulation (the singular teal CTA on the page). The button switches to a progress bar with a Cancel affordance. The engine runs in a Web Worker so the UI stays responsive even at 50,000 iterations.
If the worker can't start (rare; it happens in some restrictive corporate environments where Web Workers are blocked at the browser level), the same simulation runs on the main thread instead. You'll see a soft notice, and the method is unchanged.
Reading the results
After the run finishes, the page expands to show:
Run summary band
Project name, iteration count, active-risk count, base estimate, and the run timestamp, with a pill on the right that reads "Converged" (green) or "Marginal" (ochre) per the convergence diagnostic.
Choosing the funding level
Above the stat row is a row of percentile buttons: P50, P75, P80, P90, P95. This is the level the project is funded to, and it defaults to P80 as a starting point rather than a recommendation. Changing it does not re-run anything, because every one of those percentiles came out of the same simulation; only which one the panel reads changes.
The choice is stored on the project, not in the browser session, so it travels with an export and can be seen later by anyone reviewing the model. That is deliberate: which percentile an organisation funds is an expression of risk appetite, and ISO 31000:2018 clause 5.2 puts establishing "the amount and type of risk that may or may not be taken" with top management. The tool's job is to compute the figure and record the choice, not to make it.
Hero stat row
Four stat cards. The first, wide with an ink ground and a teal value, is the contingency at the funded percentile. The other three are P50, P80 and P90 in their semantic colours (confidence-green, teal, ink), shown whichever level you fund so you can see what the choice costs.
Headline narrative
A locked-structure paragraph that names the project, the active-risk count, the iteration count, the P50, P80 and P90, the contingency dollar amount and percentage of base at the funded level, and the top three contributors to variance. The same paragraph appears on the PDF cover so the on-screen and printed versions tell the same story.
Three full-bleed chart cards
Histogram (40 buckets of total impact with dashed percentile markers for P50, P80 and P90), S-curve (cumulative distribution of total impact), and tornado. The tornado offers two rankings behind a small toggle: rank correlation (Spearman, between each risk's per-iteration contribution and the simulated total) answers "what moves the total from iteration to iteration", so frequent risks rank high; variance share (analytical) answers "what stretches the spread", so fat-tailed low-probability risks rank high. Both are true and they can disagree; the caption states which view is showing. The top tornado bar is teal, the singular "look here first" cue.
All percentiles strip and key findings
Seven percentile cells (P10 / P25 / P50 / P75 / P80 / P90 / P95) with P50 and P80 highlighted, the convergence half-width detail beneath them, and a key-findings card with mean, standard deviation, iteration count and active risks.
Risk register table
Demoted treatment at the bottom of the page: the same register you fed in, formatted for the report reader rather than for editing.
Importing and exporting
Import loads a previously exported register envelope back into the editor, which closes the backup-and-handoff loop the JSON export exists for. Two export formats:
- Export JSON: the full register envelope (schema v2). Use it for backup, version control, or handoff. The result isn't included, only the inputs, so the export is reproducible and lightweight.
- Download PDF: an A4 portrait report with the brand cover. Sections: cover with the narrative paragraph, executive summary (key findings and the percentile grid, with contingency at the funded percentile), distribution and S-curve, sensitivity tornado, correlation heatmap (when correlation was applied), the paginated risk register, and a methodology annex recording the run parameters, distribution parameters per active risk, the correlation structure, the independence notice, and the tool and schema versions. Charts render as vector, so they stay crisp at any zoom.
Iterating on the model
The most valuable thing PRQ does is let you ask "what if?" Edit a risk's probability or distribution and re-run; the contingency responds. A few patterns that come up repeatedly:
- The top contributor. The tornado tells you which risk drives most of the variance. If you can buy down that risk's probability or top-end impact (via treatment), the contingency shrinks materially. If you can't, the right response might be to escalate it for explicit acceptance.
- The correlation flip. Run once with identity (independent), then add the correlations you suspect, and re-run. The gap between the two contingency numbers tells you how much your independence assumption was hiding.
- The convergence check. If the convergence badge says "Marginal" at 10,000 iterations, you have either too-rough distributions (refine them) or genuinely fat tails (bump to 50,000 and document the choice).