Running a schedule risk analysis on a Primavera P6 programme

This is the practical version: you have a live P6 programme, someone senior has asked for "the P80", and you'd like an answer this week, not a consultancy engagement. Here is the whole cycle, step by step.

1 · Get the XER out of P6

File → Export → Primavera PM (XER), current project only. The XER carries everything a QSRA needs: activities, durations, calendars, the full relationship set with types and lags, WBS, activity codes and constraints. No add-ins, no admin rights — every P6 seat can produce one. Drop it into RunMonteCarlo; it parses in the browser, and the file never leaves your machine — worth knowing if your schedule is commercially sensitive.

2 · Gate it before you trust it

Before a single iteration runs, check the network can carry risk honestly. The DCMA-aligned readiness gate flags what distorts simulation: activities with missing logic (open ends bypass risk propagation), hard constraints (they pin dates the simulation should be free to move), leads, heavy SS/FF use, out-of-sequence progress. You can run anyway — the gate is advisory — but every caveat prints in the report, where a reviewer will find it. Fix the big ones first; your P80 will be defensible instead of merely produced.

3 · Build the register against activities

Enter each discrete risk with its probability and three-point impact in working days — then map it to the activities it actually hits. This mapping is what separates a risk-driver QSRA (the AACE 57R-09 method) from crude duration-padding. Give each risk an owner, and decide how simultaneous impacts combine: in series (they add), in parallel (the worst one governs), or as a fragnet — a delay event inserted after the activity, propagating through logic without inflating the activity itself. Consents and approvals are almost always fragnets. If your register already lives in Excel, paste it straight in — the columns map automatically.

4 · Ranges — and correlation

Apply background duration uncertainty as −/+ percentages. Start from a calibration preset, then override where the team knows better. Two upgrades make this step professional: apply ranges by scope — a WBS branch, an activity code, a contractor UDF — instead of row by row; and put a correlation group over activities that share a crew or a weather window. Correlation is the difference between honest tails and flattering ones.

5 · Run — seeded, with Latin Hypercube

Set a seed (write it down — it makes the analysis exactly reproducible), switch on Latin Hypercube sampling for faster convergence, and run 5,000–10,000 iterations. On a modern laptop this is seconds. The engine re-solves the full CPM network every iteration, so path-switching — near-critical paths overtaking the deterministic one under risk — is captured naturally. The methodology page documents every formula involved.

6 · Read the answer like an analyst

• S-curve: the P50 and P80 dates, and the deterministic date's (usually humbling) percentile.
• Tornado: which risks drive the exposure, in days — the mitigation shortlist, pre-ranked.
• Criticality: which activities sit on the critical path in what fraction of iterations — including ones the deterministic plan calls comfortable.
• P80 overlay on the Gantt: each activity's simulated P80 finish drawn against its plan — the picture planners actually recognise.

7 · Report, then repeat monthly

Generate the pack — executive summary, method statement, inputs audit, results, drivers, reproducibility block — and circulate it. Next month, when the planner issues a new XER, re-link: the tool rematches your register and ranges to the new file, reports what changed, and re-runs in minutes. The monthly cycle is where schedule risk analysis stops being a deliverable and starts being a control. A complete worked example, files included, is on the examples page.