Your Training Partner
Techniques Toolbox
Histogram of project durations over 10'000 iterations, from 39 to 69 working days, with its cumulative S-curve. The deterministic schedule, 45 days, is marked at 7%; the 80% line meets the curve at 54.2 days; the committed date, 55 days, is marked at 85%; a bracket between 45 and 55 days shows a contingency reserve of 10 days.

Monte Carlo Simulation

Monte Carlo simulation calculates the probability that a project meets a finish date or a budget. Each uncertain duration or cost receives a range, and each risk in the register a probability and an impact. The tool draws a value for each element, recalculates the schedule or the budget, records the result and starts again a few thousand times. The output is an S-curve: for each date or amount, the probability of not exceeding it.

Goal

The PMBOK Guide names Monte Carlo simulation as the most common simulation technique in quantitative risk analysis. This analysis measures the combined effect of the identified risks and the other sources of uncertainty on the project's finish date and cost.

A schedule built with the critical path method adds single durations and returns one date. That date does not say what chance the project has of meeting it. In the example below, the calculated date falls at the 7th percentile: 93 draws out of 100 finish later.

The technique supports these decisions: the date or budget that the sponsor commits to, with its confidence level; the size of the contingency reserve; the activities and risks to watch closely. Its deliverables are the S-curve of the finish date or the cost and the criticality index of each activity.

Usage

When to use it

  • Date or budget to commit to in front of a sponsor: state a confidence level with the figure.
  • Network with several converging paths: only sampling measures the delay that the merge adds.
  • Contingency reserve to size: read it at a chosen percentile rather than set it as a percentage.
  • Register of quantifiable risks: measure their combined effect on the finish date, which risk-by-risk rating does not give.
  • Milestone gate: rerun the simulation on the remaining work before confirming or moving the date.
  • High stakes against the cost of the analysis: a few days of preparation against a fixed-price contract or a regulatory deadline.

When not to use it

Description

Three techniques carry the name simulation

Project Monte Carlo simulation, business simulation and process simulation answer three different questions. All three draw at random from distributions. They differ in the object they model: the network of a schedule or the breakdown of a budget, a business formula, an executable process with its queues.

 Monte Carlo simulationBusiness simulationProcess simulation
QuestionHow likely is the project to finish by a given date or within a given budget?What range of results can this business decision produce?If the process is designed this way, what happens and by how much?
ModelThe schedule network or the budget's breakdown structureA formula: margin, net present value, revenueAn executable process, with its resources and queues
InputsDuration or cost ranges, risks from the risk registerRanges of the uncertain business quantitiesDurations, arrival distributions, capacities
OutputS-curve of the finish date or cost, criticality indexDistribution of the result, read in percentilesThroughput, cycle time, utilisation, with their intervals
Reference standardPMBOK Guide (PMI)Guide to Business Data Analytics (IIBA)BABOK Guide (IIBA), under prototyping
Three simulation techniques: the question, model, inputs, output and reference standard of each.

The model: a network, ranges, risks

The schedule model is the network of the critical path method. Every activity in it has at least one predecessor and one successor, and no date constraint replaces a dependency. An activity without a successor absorbs any delay without passing it on; a date constraint pins the activity whatever delay is drawn for its predecessors.

Each uncertain activity receives a probability distribution: the durations it can take and the likelihood of each. PMI's Practice Standard for Scheduling sets its width by the estimator's confidence: the surer the estimator, the narrower the distribution. In practice, the analyst asks for three values per activity, the minimum, the most likely and the maximum, then chooses a triangular or beta-PERT distribution, the one used in three-point estimation. The analyst asks for the extremes before the most likely value, so that the expert does not tighten the bounds around it; business simulation details this elicitation.

Risks from the risk register enter separately. A duration range applies in every draw. A risk occurs in only some of the draws: the analyst gives it a probability of occurrence and an impact range and attaches it to the activity it delays. Risk analysis and management maintains this register; a risk rated only "high" needs numbers first.

By default, the tools draw each element independently. Two activities that depend on the same team or the same supplier slip together; the analyst enters this link in the model as a correlation. On a budget, ignoring it makes the distribution too narrow; the GAO, the audit office of the US Congress, writes that this produces a false sense of confidence in the estimate. On a schedule, the effect depends on where the activities sit: on a chain in series, independence narrows the distribution; on parallel branches that depend on the same cause, it exaggerates the merge bias described below.

One iteration, then ten thousand

An iteration draws a duration for each activity and decides for each risk whether it occurs. The tool then redoes the forward pass of the critical path method, which calculates the early dates. It records the finish date and the critical activities. The Practice Standard describes each iteration as one possible instance of the schedule, with its own critical path.

IterationABCDRisk R1 on DECritical pathFinish (days)
111242521occurs, +712A-D-E11 + (21 + 7) + 12 = 51
412252024does not occur12A-B-E12 + 25 + 12 = 49
1411303123does not occur11A-C-E11 + 31 + 11 = 53
Three iterations of the example model, values rounded to the day: the critical path runs through D, then B, then C.

A few thousand iterations give the distribution of finish dates. The criticality index of an activity is the share of iterations in which it was critical. An activity off the deterministic critical path can reach a higher index than those on the path; monitoring that follows the deterministic path overlooks it. The analyst fixes the seed of the random number generator so that every run gives the same results.

Merge bias

Where several parallel paths merge, the next activity waits for the last one to arrive. If three branches each have an 80% chance of finishing on time and are independent, the probability that all three finish on time is 0.8 × 0.8 × 0.8, or 51%. This is merge bias.

Branch 1

80% on time

PERT: this path alone, 80%

Branch 2

80% on time

Branch 3

80% on time

Next activity

0.8 × 0.8 × 0.8 = 51% on time
Three branches that each have an 80% chance of finishing on time leave the next activity only a 51% chance of starting on time. Three-point estimation sees only one branch.

Three-point estimation calculates the range of a single path, the critical path. According to the Practice Standard, PERT does not recognise that parallel paths add risk at merge points, and only a simulation measures how much. On the example network, without risk R1, PERT on A-B-E gives a mean of 47.8 days and a standard deviation of 3.8 days; the normal distribution places 45 days at 23%. The simulation, on the same ranges, places it at 9%. The PERT mean already exceeds the sum of the most likely values, 45 days, because the ranges stretch to the right.

Reading the S-curve

The histogram counts the iterations by finish date. Its cumulative curve is the S-curve: at each date, the share of iterations that finish on that day or earlier. The percentile P80 is the date that 80% of iterations do not exceed. The PMBOK Guide gives the example of a project with a 10% chance of finishing by 13 May 2027 and a 90% chance of finishing by 28 May 2027.

The first reading places the deterministic schedule date on the curve. The second gives the date at each confidence level: P50, P80, P90. The sponsor chooses the level according to the risk of overrun they accept. The analyst supplies the curve but does not choose the percentile.

Sizing the contingency reserve

The contingency reserve is the time or money included in the schedule or cost baseline for known risks. For cost, the PMBOK Guide allows it to be set as a percentage, as a fixed amount or by a quantitative analysis method. Simulation supplies the third route: the reserve is the gap between the value at the chosen percentile and the value of the deterministic plan.

The management reserve stays out of this calculation. It covers the unknowns that nobody has identified, sits outside the baseline and is usually released by a management decision.

The budget: the same mechanics on the breakdown structure

The GAO's cost estimating guide applies the same procedure to the budget. Each element of the project's work breakdown structure (WBS) receives a cost distribution. Each iteration draws a cost per element and adds them up. The repeated draws give an S-curve of the total cost, read as a confidence level against an amount. In the GAO's example, the median is USD 908'000; a programme manager who wants 70% confidence budgets USD 1'096'000. About USD 271'000 separates this budget from the point estimate, which is close to USD 825'000. That gap is the contingency reserve for cost.

Repeating the analysis

According to the PMBOK Guide, quantitative analysis runs throughout the project, whenever the project calls for it. At each milestone, actual durations replace the ranges of completed activities, and the analyst simulates the remaining work. The curve narrows as the project advances. A P80 that moves later from one simulation to the next signals that the project is consuming its reserve faster than it is progressing.

Pitfalls

The schedule that is not a network

Simulating a schedule with date constraints or activities without successors returns a steep and reassuring curve. Before the first simulation, the analyst checks that every activity, apart from the start and finish milestones, has a predecessor and a successor. Each date constraint becomes a milestone, linked to the network by its own dependency. The risk modules of scheduling tools produce this check as a report before the draw.

Ranges that are too narrow

An expert who gives 20, 22 and 24 days for an activity they have never done claims a confidence they do not have. Narrow ranges produce a narrow curve, which passes for a solid result. The analyst records where each range comes from and tests it against the actual durations of comparable projects, where such data exist.

The P80 taken for a promise

The P80 holds for the model: this network, these ranges, these risks. It covers neither a change of scope nor a risk that nobody has identified. The report states the percentile with its assumptions, and the management reserve stays a separate line.

The forgotten correlation

When the model draws ten work packages from the same supplier as independent, their late and early finishes offset each other. The curve comes out too narrow. The analyst models the correlations known to the business or writes the independence assumption into the report.

AI considerations

A language model writes the simulation script: about a hundred lines of Python that read a schedule export, draw the durations, redo the forward pass and count the critical paths. An analyst who does not program gets a reproducible tool: with the same seed, every run gives the same results. Before relying on it, the analyst runs it on networks whose answer they know. On a single chain of activities with triangular distributions, the simulated mean must equal the sum of (min + most likely + max)/3. On two identical, independent branches that merge, the share of iterations that finish before the median of one branch must be 25%, or 0.5 × 0.5. The same language model checks a schedule export and lists the activities without successors and the date constraints.

The model also helps prepare the ranges. From a history of comparable projects, it proposes a minimum, a most likely value and a maximum per activity type, which the activity owner corrects. The range stays marked "proposed" until someone takes ownership of it. Downstream, the model drafts the report from the percentiles and indices that the tool has calculated.

A language model asked for a project's P80 date answers with a plausible figure without having run a single iteration. Budgets, supplier prices and contractual risks stay out of online services whose terms of use the organisation does not control.

Examples

A municipality in the canton of Vaud opens an online services portal. The deterministic schedule, built on the most likely values, gives 45 working days: 10 + 25 + 10 along path A-B-E.

ElementMin, most likely, max (working days)Sequence
A. Scoping and specifications8, 10, 15Project start
B. Portal development20, 25, 40After A
C. Data migration15, 22, 35After A
D. Interface with the cantonal register of persons (RCPers)18, 24, 38After A
R1. The canton delivers its register interface lateProbability 25%, impact of 5 to 10 days, uniform distributionDelays D
E. Acceptance testing and go-live8, 10, 16After B, C and D
SettingsBeta-PERT distribution, 10'000 iterations, fixed seedIndependence assumed between activities
The inputs to the simulation of the online services portal: five activities described by three values, one risk from the risk register and the simulation settings.
ReadingValueWhat it says
Finish in 45 days or fewer7%The date of the deterministic schedule
Finish in 51 days or fewer55%The median, P50, is 50.5 days
Finish in 54 days or fewer79%The P80 is 54.2 days
Finish in 55 days or fewer85%First whole day above 80%
Contingency reserve at 80%10 days55 minus 45
Criticality indexD 47%, B 41%, C 12%Branch D, with R1, is critical more often than B
Reading the S-curve of the online services portal: the probability of finishing by each duration and the criticality index of the three branches.

The sponsor asks for 80% confidence: the municipality commits to 55 working days, 10 of them contingency reserve. The deterministic schedule identified B as critical; the simulation identifies D, because R1 lengthens it in a quarter of the iterations. The municipality therefore tracks D every week and chases the canton.

Visualisations

The histogram and its S-curve show at what confidence level a date or a budget holds. The criticality index, activity by activity, shows which path is the longest most often. The tornado diagram of sensitivity analysis ranks the inputs by their correlation with the finish date and shows which one moves it most. In the PMBOK Guide's example, each bar shows the correlation of one input with project duration.

Criticality and sensitivity are read from the same iterations and answer two questions. For the online services portal, the index points to D, critical in 47% of iterations; the tornado points to R1, whose correlation with project duration is 0.50. Migration C barely moves the date.

A reader checks a simulation report with these questions. Where does the deterministic schedule date fall on the curve? Who chose the confidence level? Does the model contain the risks from the risk register and the known correlations or only duration ranges?

Cost

PhaseLevelRationale
PreparationHighTurning the schedule back into a network, collecting three values per activity from the activity owners and quantifying the risks in the register.
ExecutionLowTen thousand iterations run in a few seconds. The time goes into the session where the sponsor reviews the results and chooses the confidence level.
DocumentationMediumFor each simulation: where the ranges came from, the correlations, the seed, the chosen confidence level and who chose it.

Tools

The risk modules of scheduling tools (Oracle Primavera Risk Analysis, Safran Risk, Deltek Acumen Risk) read the schedule network, attach the ranges and risks to its activities and return the S-curve, the criticality index and the tornado diagram. They suit schedules of several hundred activities.

For budgets, spreadsheet simulation add-ins (Lumivero @RISK, Oracle Crystal Ball) draw the costs of the breakdown structure in the workbook that the finance team already uses.

A Python script with NumPy covers a network of a few dozen activities in about a hundred lines. R offers the same sampling functions. The script goes under version control and documents the model.

Sources

Minimum Viable Product (MVP)
All techniques
Motivation Models