Cost and schedule risk analysis

Both analyses are Monte Carlo simulations: the register is sampled many thousands of times, each run deciding independently which risks occur and how much they cost or delay, and the spread of outcomes is what the curves show. Nothing is fitted or smoothed; a curve is a count of runs.

Cost risk analysis (QCRA)

Open QCRA Analysis. The simulation runs in your browser from the current register, so there is nothing to submit and nothing to wait for beyond the run itself. Three controls sit above the results:

• Iterations: 10,000 by default, selectable from 1,000 to 25,000. More runs give a smoother curve at the tails; 10,000 is enough for a register of ordinary size.
• Seed: the starting point for the random numbers. The same seed on the same register gives the same result to the penny, which is what makes a figure in a report reproducible. Change it only to check that a conclusion does not depend on one particular draw.
• Confidence levels: P50, P65 and P80 by default. These are the percentiles reported in the table and marked on the curve.

Each risk is sampled from a triangular distribution across its minimum, most likely and maximum, and occurs in a run with its stated probability. The most likely value is weighted four to one in the expected-value figure, which is the standard PERT formula.

Reading the results

Confidence curve (S-curve)

Cumulative probability that the total risk cost is at or below a given figure. Read across from 80% to find the P80: the cost you have an 80% chance of not exceeding. A steep curve means a well-understood register; a long flat tail means a few large, uncertain risks.

Histogram

The same runs bucketed into slices (100 by default). Useful for spotting a register that is really two populations, for example a base case and a cluster of runs where one large risk occurred.

Sensitivity (tornado)

Each risk’s rank correlation with the portfolio total: how much of the movement in the total is explained by that risk. This is the list to take into a mitigation workshop, because the top few entries are where the money is.

Per-risk table

For every risk: its inputs, its expected value, its EMV, how often it occurred across the runs (which should be close to its stated probability) and its sensitivity.

The results are also rolled up by WBS code, which is what the WBS Explorer and the reports draw on.

The WBS explorer

WBS Explorer shows the work breakdown structure as a tree, with the simulated risk cost at every node: minimum, most likely, maximum, PERT expected value, EMV and the number of risks contributing. Expand a branch to trace exposure from the portfolio total down to a single package.

A node’s figure is the sum of the cost lines coded to it and to its children, so a risk whose cost lines have no WBS code contributes to the total but appears under no package. If the tree adds up to less than the register, that is where the difference is.

Schedule risk analysis (QSRA)

QSRA (Schedule) runs the register against your programme, following the five-step process a practitioner works through by hand: schedule, uncertainty, risks, mapping, then run and results. Each step has its own tab, with a status dot showing not started / in progress / complete / blocked.

1. Schedule. Import a programme file (see below), or create an empty version and enter activities by hand or by pasting CSV rows. Before anything else, work through the schedule assurance report below and mark the schedule fit for purpose.
2. Uncertainty. Assign a relative range to activities individually, or select a WBS branch and bulk-assign one with a rationale. This is the “how confident are we in the durations themselves” layer, separate from the risks.
3. Risks. Reconcile each linked risk’s register (weeks) schedule impact against what is actually modelled (days), and set its distribution and mapping weighting.
4. Mapping. On each risk, tick the activities it would delay, set a delay estimate, and record why. An optional AI panel proposes candidate activities from the risk’s description; nothing is written until you accept a suggestion.
5. Run & Results. Only available once the schedule is signed off as fit for purpose (step 1). Runs the Monte Carlo simulation and reports the outputs below.

Schedule assurance and sign-off

Before uncertainty or risk is even considered, the imported programme needs to be fit to flex. The Schedule tab runs a set of deterministic checks and shows each finding grouped by rule:

• Hard constraints (error) — a date the schedule cannot move through no matter how much uncertainty or risk is applied. These need removing, in agreement with the planner.
• Soft constraints (warning) — only legitimate with a reason (a critical resource, a governance gate), never just to hold a date.
• Open ends, non-Finish-to-Start relationships and lags — logic that cannot carry uncertainty, or activities immune to any downstream delay.
• Negative float, level-of-effort activities still wired into logic, and long remaining durations — activities likely to need excluding from uncertainty in step 2.
• A non-standard calendar — an 8-hour day misread as 24-hour can silently shrink every imported duration to a third.

Record a status and a comment against each finding, export the list as a CSV warnings report to send to the planner, and record their written confirmation once they have responded. When you are satisfied, mark the schedule fit for purpose — this unlocks step 5. If errors are still open, you can proceed with a written override reason, which is recorded against the sign-off.

Reading the milestone table

Alongside the confidence curve and levels, the Results step includes a milestone comparison table: for every milestone, deterministic date, uncertainty-only date, gross date and mitigated date, side by side. A Run DU-only preview on the Uncertainty step gives the same comparison before any risks are even mapped — if uncertainty alone already accounts for most of the delay, the schedule itself needs attention, not the risk register.

• DU Δ — days added by duration uncertainty alone (uncertainty-only date vs deterministic).
• DR Δ — days added by discrete risk on top of that (gross date vs uncertainty-only date).
• % from uncertainty — the share of the total delay attributable to uncertainty rather than risk. A high share is flagged, as it usually means the schedule’s own confidence needs work.

The simulation runs critical path analysis on every iteration (3,000 by default, up to 20,000) and also reports:

• A pre- and post-mitigation confidence curve: the cumulative probability the programme finishes at or before a given date.
• Confidence levels from P5 to P100 as finish dates, gross against mitigated.
• Joint cost and schedule: a scatter of cost against finish date from the same iterations, and a target box where you type a cost and a date to see the probability that both are met together. This only appears once the register has enough linked risks for a joint view to mean anything.

Importing a programme

Programmes can be imported directly on the QSRA page’s Schedule tab, or through Documents: upload the file to the project’s document library, then choose Import as schedule on it. Either way, the activities and their logic are read in and a new schedule version is created (and, via Documents, linked to the source file).

Two formats are supported:

• Primavera P6 XER (.xer)
• Microsoft Project XML (.xml, the MSPDI export)

Files up to 25 MB can be parsed. A programme far larger than that is usually a sign the export contains more than the schedule, and the import will refuse it with a clear message rather than time out. The import also reads the programme’s data date and calendar (working days, holidays, hours per day) from the source file, shown on a “Schedule facts” card on the Schedule tab.