Schedule risk analysis: Monte Carlo, P50 and P80 dates

A schedule gives one finish date. Reality gives a range. Schedule risk analysis turns the plan into a distribution of possible finish dates by simulating the project thousands of times with uncertain durations and the risks that may happen, so you can say how likely a date is and what drives it. The answer is usually sobering: the deterministic finish is often less than 30% likely.

Why one date is not enough

Every duration in a schedule is an estimate, and estimates are uncertain. When paths merge, uncertainty compounds: an activity that waits for three predecessors starts when the latest of them finishes, so merges push the likely finish later than the plan, even when each estimate is reasonable on its own. This merge bias is why projects with "realistic" durations still finish late, and why adding up optimistic and pessimistic cases by hand does not work.

How Monte Carlo simulation works

1. Give the uncertain activities a range: a minimum, most likely and maximum duration (a three-point estimate) and a distribution shape.
2. Add the discrete risks from the risk register: events with a probability and an impact on specific activities.
3. For each iteration, sample a duration for every activity, decide which risks occur, and recalculate the whole network with its logic, calendars and constraints.
4. Repeat a few thousand times. The finishes form a distribution: the share of iterations finishing by each date is the probability of finishing by that date.

Latin hypercube sampling spreads the samples evenly across each range so results settle with fewer iterations; a fixed seed makes a run repeatable, so a change in the result means a change in the inputs.

P50, P80 and the deterministic date

The P50 is the date with a 50% chance of being met: as likely to be beaten as missed. The P80 is met in 80% of iterations, a common basis for commitments and for schedule contingency. The deterministic date is the plain CPM finish; the analysis reports how likely it is. The gap between the P50 or P80 and the target is the schedule contingency the project needs, or the risk it is carrying without saying so.

What drives the result

• Criticality: the share of iterations in which an activity was on the critical path. An activity critical in 40% of runs matters even if it is not critical in the plan.
• Sensitivity: how strongly an activity's duration moves the project finish, often shown as a tornado chart.
• Risk event impact: which register risks, when they occur, move the finish most.

These tell you where mitigation buys the most time: shortening a highly critical, highly sensitive activity is worth more than shortening one that rarely drives the finish.

Common mistakes

• Ranges that are too narrow. People anchor on the plan. Ranges set by experts, checked against history, and reviewed are better than a blanket ±10%. See three-point estimates.
• Ignoring correlation. Activities done by the same contractor, in the same conditions or estimated by the same person tend to run long together. Treating them as independent narrows the result falsely.
• A poor schedule. Open ends, hard constraints and missing logic break the simulation as they break the CPM. Fix schedule quality first.
• Running it once. Risk analysis is most useful repeated at each update, with the trend of the P80 watched like any other metric.

Schedule risk in DeltaSys

The DeltaSys Planner runs Monte Carlo or Latin hypercube simulation on the live schedule, with triangle, BetaPERT and uniform distributions, quick-risk ranges for many activities at once, correlation, probabilistic branches and links, risk factors, weather calendars and a risk register mapped to activities before and after responses. It reports P-dates, criticality, sensitivity and the drivers, shows the bands on the Gantt chart, and keeps each result with the project, flagging it out of date when the schedule changes. The demo carries a complete analysis to explore.

Questions

Next: cost risk and contingency.

Primavera and P6 are trademarks of Oracle Corporation; Microsoft Project is a trademark of Microsoft Corporation; PMBOK is a trademark of the Project Management Institute; AACE is a trademark of AACE International; Last Planner is a registered trademark of the Lean Construction Institute. DeltaSys is not affiliated with or endorsed by them. Standards are described in our own words; see the publications themselves for their text.