What a quantitative schedule risk analysis is
A quantitative schedule risk analysis — QSRA — replaces every fixed activity duration with a range, then reschedules the whole network thousands of times, drawing a different duration from each range on every pass. What comes back is not one finish date but a distribution of them: a picture of how the programme behaves when things do not go exactly to plan.
The technique almost every QSRA uses is Monte Carlo simulation, named after the casino because it answers a hard question by sampling rather than by solving. There is no closed-form formula for when a network of a few thousand interdependent activities will finish once every duration is uncertain. Running it several thousand times and counting the answers is the practical substitute.
The output is expressed as confidence levels: a P50 date the programme beat in half of the runs, a P80 it beat in four out of five. Those are the numbers that end up in front of a steering committee.
QSRA, SRA or Monte Carlo?
QSRA (quantitative schedule risk analysis) and SRA (schedule risk analysis) generally describe the same exercise — putting numbers on schedule uncertainty. Monte Carlo simulation is the method used to get there.
Where a distinction is drawn, "quantitative" separates this from a qualitative risk assessment: a probability-and-impact matrix ranks risks, a QSRA calculates what they do to the finish date. A QCRA is the cost equivalent, and the two are sometimes run together — see cost and schedule together.
- Why one date is usually optimistic
- What drives schedule risk
- Merge bias
- Correlation
- Where the numbers come from
- How a QSRA is run
- How long a QSRA takes
- What makes a QSRA succeed
- QSRA software
- Reading the output
- Criticality and sensitivity
- Cost and schedule together
- What a QSRA will not tell you
- Standards and guides
Why one finish date is usually optimistic
A critical path calculation takes one duration per activity and produces one answer. That answer is not the most likely outcome of the project. It is the outcome that occurs if every activity takes exactly the duration written against it — which, across several thousand activities, essentially never happens.
The deterministic date is better understood as one sample from a distribution nobody has drawn, and usually a favourable one. A QSRA draws the rest of it.
What drives schedule risk
Schedule risk does not come from one place. It is worth separating the sources, because they are addressed differently and some are invisible in the schedule itself.
1. Optimism in duration estimates
Durations tend to be entered as the time the activity takes when it goes well, because that is how people think about work they have not started. The room to overrun is almost always larger than the room to underrun: an activity planned at ten days might finish in eight, but it might take twenty. The distribution of real outcomes is skewed to the right, and a single number cannot carry that.
2. Merge bias at converging paths
Wherever several paths feed one activity, that activity waits for the last of them — and the more predecessors an activity has, the lower its chance of starting on time. This is structural rather than estimating error, and it is covered in full below.
3. Correlation between activities
Activities are not independent. The same weather, the same subcontractor, the same late design release moves many of them together. Treating them as independent makes a programme look far more predictable than it is — see correlation.
4. Discrete risk events
Things that either happen or do not: a permit refused, a long-lead item arriving damaged, a key approval missed. These do not live in the duration estimates at all; they come from the risk register and are modelled separately.
5. Schedule quality itself
Missing logic, open-ended activities, hard constraints and negative lag all distort a simulation, usually towards an answer that is too good. A network that has not been checked will produce confident numbers that mean very little — which is why the quality checks come first.
6. Parallelism that is more fragile than it looks
Running work in parallel compresses the plan, but it multiplies the number of things that must all go right. Two paths side by side look efficient on a bar chart; statistically they are two independent chances to be late feeding one date.
7. What the model leaves out
Resource availability, scope change, funding interruptions and management response to bad news are all real sources of schedule risk that a standard QSRA does not represent unless they are deliberately added.
Merge bias: why converging paths make you later
Wherever several paths feed into one activity, that activity waits for the last of them. It cannot start early because two predecessors finished early; it only needs one to be late.
A worked example
Three independent paths converge on a single milestone. Each path has an even chance of hitting its date — 50 per cent on time, 50 per cent late.
The milestone is only on time if all three paths are on time. That is 0.5 × 0.5 × 0.5 = 0.125. A one-in-eight chance.
Every individual path looked like a coin toss. The merge point is a 12.5 per cent proposition, and nothing in the schedule says so.
This is merge bias, and it is the single strongest argument for running a QSRA rather than adding a contingency buffer at the end. It scales with the number of converging paths, so it is worst exactly where programmes are most complex — integration milestones, handovers, commissioning, anywhere many workstreams land on one date.
It also explains a familiar pattern: a programme where every individual team reports on track, and the integrated milestone slips anyway. No one is wrong in that conversation. The arithmetic of convergence is doing the work.
A deterministic schedule cannot show this, because with fixed durations the merge point simply takes the longest predecessor and reports no uncertainty at all. Only a simulation, which re-draws every path on every iteration and takes the maximum, reproduces the effect.
Correlation, and why ignoring it flatters the schedule
If every activity is sampled independently, the highs and lows cancel out. That cancellation is a mathematical property of averaging independent quantities, and on a large schedule it is severe.
What independence does to the spread
Take a chain of 100 activities, each with a generous ±20 per cent uncertainty, all sampled independently.
The uncertainty on the total is not ±20 per cent. It is roughly ±20 per cent divided by the square root of 100 — about ±2 per cent.
A QSRA built that way reports a programme that is almost perfectly predictable, and hands back a P80 barely later than the deterministic date. The schedule has not become reliable; the model has assumed the risks away.
Real projects do not work like that. Activities share drivers. The same weather affects every outdoor activity that season. The same subcontractor is behind on all of its packages at once. One late design release delays everything downstream of it. When one thing runs late, related things tend to run late with it.
Correlation is how that shared behaviour is represented. A global coefficient somewhere in the region of 0.2 to 0.4 is a common starting position, with higher values applied within a work package or a single contractor's scope. The precise number is a judgement, but applying none at all is not a neutral choice — it is an assumption of total independence, which is the least realistic position available.
This is the most common way a QSRA produces a confident and badly wrong answer. A result that shows a very narrow distribution on a large programme is usually reporting missing correlation rather than a dependable plan.
Where the numbers come from
A QSRA is only as good as the ranges fed into it, and those ranges do not exist in the schedule file. They come from people. This is the part that takes the time.
Three-point estimates
Optimistic, most likely, pessimistic — for each activity, or for each group of similar activities.
The most common approach is to ask, for a given activity: what is a realistic best case, what do you actually expect, and what is a bad but credible case? Those three points define a distribution the simulation samples from.
Eliciting these well is a skill. The usual failure is a pessimistic value that is not pessimistic — people anchor on the plan and offer a range far narrower than their real experience of that work. Asking for a specific bad scenario, rather than a number, tends to produce more honest bounds.
On a large schedule, ranges are usually applied to risk bands rather than activity by activity: groups of similar work sharing one uncertainty profile, so a few thousand activities can be covered by a few dozen decisions.
Which distribution
Triangular, BetaPERT or uniform — the shape matters less than people expect.
Triangular is the most widely used: it takes the three points directly and is easy to explain to the people supplying them. BetaPERT weights the most likely value more heavily and produces a slightly narrower, smoother result. Uniform says that anything between the bounds is equally likely, which is a deliberate statement that you have no information beyond the range.
The honest summary is that changing distribution typically moves the answer by a fraction of what widening the range does. Effort is better spent on the ranges than on the shape.
Duration uncertainty versus discrete risk events
Two different things, often confused, and modelled differently.
Duration uncertainty is the ordinary variability of work that will definitely happen: the excavation will take somewhere between eight and eighteen days. It is modelled as a spread around each duration.
Discrete risk events either occur or do not. These carry a probability of occurrence and an impact, and they come from the risk register rather than from the schedule.
Many QSRAs start with duration uncertainty alone, which is a complete and legitimate analysis in its own right, and add discrete events once the model is trusted. What matters is being clear about which one you ran, because a result covering only duration uncertainty understates total exposure and should not be presented as though it covered everything.
How a QSRA is run
The simulation itself takes seconds. Almost all of the effort is in the preparation and the conversation, and the sequence below is roughly how most analyses go.
-
Check the schedule is fit to model
Before anything else, the network is reviewed: open ends, missing logic, hard constraints, negative lag, out-of-sequence progress and level-of-effort activities. Every one of these distorts the result. Many QSRAs stop here and fix the schedule first, and that is the right outcome — an analysis run on a broken network produces confident nonsense.
-
Agree the scope and the target dates
Which milestones matter, what confidence levels will be reported, what will be modelled and what will not. Deciding this before the numbers exist is what stops the exercise being re-litigated after someone dislikes the answer.
-
Build a working model
Large schedules are often summarised into a smaller risk model, or grouped into risk bands, so the exercise stays tractable. The model must still reproduce the deterministic dates before any uncertainty is added — if it does not match the schedule it came from, nothing built on it is trustworthy.
-
Gather the uncertainty
Three-point ranges from the people who own the work, discrete risks from the register, and correlation assumptions. This is usually a facilitated workshop rather than a form to fill in, because the conversation exposes things the numbers alone do not.
-
Run and sanity-check
Run the simulation, then interrogate it before showing anyone. Is the spread plausible? Does the criticality ranking match what the team worries about? A distribution that is suspiciously narrow, or a P50 that lands exactly on the deterministic date, usually means something is wrong with the model rather than right with the plan.
-
Report the result with its assumptions
The confidence levels, the sensitivity ranking, and — just as important — the ranges, correlation and exclusions the numbers rest on. A P80 presented without its assumptions cannot be defended when someone challenges it, and someone will.
How long a QSRA takes
This is the question that decides whether a risk analysis happens at all, and it is rarely answered honestly.
The simulation runs in seconds. The schedule quality review is usually the longest single item, and on a schedule that has not been checked before it can take longer than everything else combined. The elicitation workshop is typically a half day to two days depending on how many risk bands and owners are involved. Model build, running and reporting are usually a few days of work around those sessions.
For a first QSRA on a programme, plan in weeks rather than days — most of it calendar time spent getting people in a room, not analysis. Once the model exists and the team is used to the questions, re-running it at each update is a fraction of that, and this is where the method earns its keep: the second and subsequent analyses are comparatively cheap.
The common failure is booking the workshop and skipping the schedule review. That inverts the effort into the one place where it does not help.
What makes a QSRA succeed
Most analyses that fail do not fail technically. They fail because of how they were set up.
- Leadership actually wants the answer. If the sponsor has already committed to a date publicly, a P80 later than that date becomes an inconvenience rather than information, and the exercise quietly turns into a search for acceptable inputs. Agreeing in advance that the result will be used is the precondition for everything else.
- It is part of the project, not an audit of it. A QSRA run alongside the planning cycle, at each update, changes decisions. One commissioned once, near a gate review, gets treated as a compliance artefact and changes nothing.
- People can say pessimistic things safely. The inputs come from the team. In a culture where admitting a range means admitting weakness, the ranges come back narrow, and a narrow input guarantees a narrow and useless output. This is the single biggest determinant of input quality.
- Facilitation is independent. Someone who does not own the outcome should run the elicitation. It is uncomfortable for a delivery lead to ask their own team for credible worst cases and then own the result.
- The schedule was fixed first. Bears repeating: network quality is a precondition, not a caveat.
- The assumptions travel with the number. A confidence level detached from its ranges, correlation and exclusions will eventually be quoted back as a commitment nobody can defend.
QSRA software
A QSRA is usually run in dedicated software that reads a Primavera P6 or Microsoft Project schedule, applies uncertainty, and simulates against the network.
Established options include Primavera Risk Analysis (formerly Pertmaster), Safran Risk, Deltek Acumen Risk and Full Monte. General-purpose Monte Carlo add-ins such as @RISK are also used, more often for cost than for schedule networks.
What they share is a scheduling engine: to re-run a network thousands of times, the tool has to reproduce the host scheduler's own calculation, including calendars, constraints and progress. That requirement, rather than the sampling, is what makes these tools substantial pieces of software — and it is why spreadsheet approximations of schedule risk tend to miss merge bias entirely, since a spreadsheet adds path durations rather than recalculating a network.
Reading the output
The histogram
Every iteration produces a finish date; the histogram counts how often each date came up. It shows the shape of the risk — where the bulk of the outcomes sit, and how long the tail runs to the right. A long right tail means the downside is much worse than the upside, which is the normal shape for a schedule.
The S-curve
The same data expressed cumulatively: for each date, the probability of finishing on or before it. It rises from zero to one, and its steepness is the interesting part. A steep curve means a tightly bounded outcome. A shallow curve means the finish could land almost anywhere, and a single committed date is close to meaningless.
P50, P80 and what sits between them
The gap is the contingency.
The P50 is an even bet — half the iterations finished by then. It is normally used as the working plan. The P80 is reached in four runs out of five, and is a common basis for an external commitment. P90 appears where the consequences of being late are severe.
The distance between P50 and P80 is the quantity a contingency conversation is actually about. If that gap is three weeks, then committing to the P50 and holding three weeks of schedule contingency is a coherent position. Committing to the P50 with no contingency is a coin toss described as a plan.
One caution worth stating plainly: a P80 is not a promise. It is a one-in-five chance of being late, derived from ranges that people estimated. Presenting it as a guarantee misrepresents both the method and the inputs.
Criticality, cruciality and sensitivity
Once durations vary, the critical path stops being a single fixed sequence. Different paths drive the finish in different iterations, and a QSRA can count how often each one does.
- Criticality index. The percentage of iterations in which an activity sits on the longest path. An activity critical in 100 per cent of runs is genuinely critical. One critical in 45 per cent of runs is a path the deterministic schedule may never have flagged, and it deserves management attention it is not currently getting.
- Duration sensitivity. How strongly an activity's own duration correlates with the project finish. It identifies where variability actually propagates, which is not always where the longest activities are.
- Cruciality. Sensitivity combined with criticality, used to rank what to act on. A long, highly variable activity that is rarely on the critical path may matter less than a short one that is always on it.
These are usually presented as a tornado chart, sorted by influence. In practice this is often the most actionable output of the whole exercise: the completion distribution tells you where you stand, and the sensitivity ranking tells you what to do about it.
Cost and schedule together
Schedule and cost risk are usually analysed separately — a QSRA on one side, a quantitative cost risk analysis (QCRA) on the other — which understates both, because on most projects being late costs money. Time-dependent costs, preliminaries, extended site overheads and escalation all follow the schedule, so a cost contingency calculated against a deterministic finish date is calculated against a date the project is unlikely to hit.
An integrated analysis loads the schedule model with costs and runs both together, so each iteration produces a matching pair: a finish date and a total cost. Plotting those pairs gives a scatter of outcomes, and from it a joint confidence level (JCL) — the probability of completing by a given date and within a given budget.
This is a noticeably harder exercise, because it needs a cost-loaded schedule and agreement on which costs are time-dependent. Where it is used, the JCL figure tends to be the number the sponsor cares about, since it is the only one that describes the commitment as it is actually made: a date and a budget, together.
What a QSRA will not tell you
The method has real limits, and being straightforward about them is what makes the results credible when they are presented.
- It cannot repair a bad network. The simulation propagates durations through the logic that exists. Missing predecessors, open-ended activities, hard constraints and negative lag all distort the result, often in the optimistic direction. Schedule quality checks come first — see the DCMA 14-point checks explained.
- It inherits the quality of the estimates. Ranges supplied to close out a workshop produce numbers with false precision. The output has as many significant figures as you like and no more authority than its inputs.
- It does not model everything. Scope change, resource constraints, funding interruptions and management response to bad news are all outside a standard QSRA unless deliberately added.
- It assumes the plan stays the plan. Real teams re-sequence, accelerate and work around problems. A simulation runs the network as written, which is why a P80 tends to be conservative in organisations that actively manage recovery.
- The result depends on choices you made. Correlation, distribution, and which activities were given ranges all move the answer. Two competent analysts can produce different numbers from the same schedule. Recording the assumptions alongside the result is not administrative overhead; it is what makes the number defensible.
QSRA standards and guides
Quantitative schedule risk analysis is covered by several established references:
- AACE International RP 57R-09, Integrated Cost and Schedule Risk Analysis Using Monte Carlo Simulation of a CPM Model. The standard reference for the method itself — how to build the model, handle correlation, and interpret the output.
- AACE International RP 65R-11, Integrated Cost and Schedule Risk Analysis and Contingency Determination Using Expected Value. Covers determining contingency from the analysis, and the expected-value approach alongside simulation.
- GAO Schedule Assessment Guide, GAO-16-89G (December 2015). Lists conducting a schedule risk analysis among its ten best practices for a reliable schedule, and sets out what a credible one involves. GAO-16-89G on gao.gov
- DCMA EVMS Program Analysis Pamphlet, DCMA-EA PAM 200.1 (2012). Does not cover risk analysis, but its 14 schedule quality metrics test the network integrity a QSRA depends on.
- Your contract or company specification. Frequently the deciding document, and it may prescribe the confidence level, the method or the reporting format.
Schedule risk analysis in GanttSnap
Schedule risk simulation is in development for GanttSnap. It is not available yet, and there is no release date to give — it will ship when the underlying scheduling engine reproduces Primavera P6's own dates reliably, and not before.
The intended first release covers duration uncertainty with correlation, not a full QSRA: discrete risk events and a risk register are outside its initial scope, and this page will say so plainly when it arrives.
What GanttSnap does today is turn a Primavera P6 or Microsoft Project schedule into an editable Gantt slide in PowerPoint, with baseline comparison, critical path and the DCMA 14-point assessment — the schedule quality checks a QSRA depends on. Schedule data is read on your own device and is not uploaded.
Frequently asked questions
What does QSRA stand for?
QSRA stands for quantitative schedule risk analysis: an analysis that puts numbers on how likely a schedule's dates are to be met, usually by running a Monte Carlo simulation over the schedule network. "Quantitative" distinguishes it from a qualitative risk assessment, which ranks risks by probability and impact without calculating their effect on the finish date.
What is the difference between QSRA, SRA and Monte Carlo simulation?
QSRA and SRA generally refer to the same exercise, with QSRA emphasising that the output is numerical. Monte Carlo simulation is the technique almost every QSRA uses to produce that output. A QCRA is the cost equivalent, and the two can be combined into an integrated analysis that reports a joint confidence level.
How long does a QSRA take?
The simulation itself runs in seconds. The work is the preparation: a schedule quality review, which is often the longest item, and an elicitation workshop of typically half a day to two days. For a first analysis on a programme, plan in weeks of calendar time rather than days. Re-running it at each update afterwards is far quicker, which is where the method pays back.
How many iterations does a Monte Carlo schedule analysis need?
Enough that the answer stops moving. For most schedules the percentiles settle somewhere between 1,000 and 5,000 iterations with simple random sampling, and sooner with Latin Hypercube sampling. Rather than picking a number, re-run the analysis and watch whether the P80 shifts. If it moves by more than a day or two between runs, the sample is too small.
Which distribution should I use for activity durations?
The choice of distribution matters far less than the range you put into it. Triangular is the most common because three points are easy to elicit in a workshop. BetaPERT puts more weight near the most likely value and produces slightly narrower results. Uniform is a deliberate statement that you know nothing beyond the bounds. Changing distribution typically moves the answer by a fraction of what widening the range does.
What is the difference between a P50 and a P80 completion date?
A P50 date is the date the simulation finished on or before in half of its iterations, so it is an even bet. A P80 is the date reached in 80 per cent of iterations, so it carries roughly a one-in-five chance of being late. P50 is normally used for the working plan and P80 or P90 for a commitment or a contingency position, because the distance between them is what the contingency is buying.
Is the critical path still meaningful after a QSRA?
It becomes one of several. Once durations vary, different paths drive the finish in different iterations. The criticality index — the share of iterations in which an activity sits on the longest path — replaces the single deterministic critical path and is often more useful, because a path that is critical in 40 per cent of runs deserves attention even though the baseline schedule never shows it as critical.
Do I need a risk register to run a QSRA?
Not for duration uncertainty, which only needs a range around each activity duration. A register is needed for discrete risk events — things that either happen or do not, such as a permit being refused — because those are modelled as a probability of occurrence combined with an impact rather than as a spread around a duration. Many analyses run duration uncertainty first and add discrete events later.
Does a QSRA replace schedule quality checks like the DCMA 14-point assessment?
No, it depends on them. A Monte Carlo simulation propagates durations through the logic network, so missing logic, hard constraints and open ends distort the result directly. Running the quality checks first is what makes the risk analysis worth reading.