Last updated October 2026
Monte Carlo simulation runs a project’s schedule or budget thousands of times. Each run draws every duration, cost and risk event from its range and works out the finish date and the total cost. Together the runs show how likely each date and cost is: an S-curve, P50 and P80 values, and a ranked list of what drives them.
A small project: six tasks on two paths, each with an optimistic, most likely and pessimistic duration in days. Switch the risk and the shared contractor on and off, and choose how sure you want to be. Each change reruns 50,000 simulations in your browser.
You can be 80% sure of finishing within 106 days, 18 days later than the plan’s 88. The plan itself has a 13% chance. The permit objection drives the finish date more than any single task.
Tornado diagram: how closely each item moves with the finish date (rank correlation, 0 to 1)
Criticality: the share of runs in which each path sets the date
Tamara runs this simulation on your own Primavera P6, Microsoft Project or Microsoft Planner Premium schedule.
Durations are PERT distributions from each task’s three values. 50,000 runs from a fixed seed, so the page shows the same numbers every time. The shared contractor is a correlation of about 0.8 between the three tasks.
Turn on JavaScript to change the settings. The numbers shown include the permit risk, with the tasks independent.
In this example, the plan built from the most likely durations finishes on day 88. The simulation gives that date a 13% chance. You can be 80% sure only of day 106, 18 days later. That gap is the schedule contingency the plan needs, and nothing in the plan itself shows it.
Monte Carlo simulation is the main tool of quantitative risk analysis. The PMBOK Guide lists it under Perform Quantitative Risk Analysis, so it also comes up in the PMP exam. The three numbers behind each task come from three-point estimating.
It replaces each fixed duration with a range, then recalculates the schedule many times. Every iteration picks a value for each task and each risk, pushes the dates through the network as the scheduling tool would, and records the finish. After a few thousand iterations, the recorded finish dates show the spread of possible outcomes and how likely each one is.
Six steps of a schedule risk analysis
Every task needs its logic links, with no open ends, and constraints only where they are real. A broken network gives a confident answer that means nothing.
Use three-point estimates, or a few uncertainty levels that each task takes one of. Ask for the pessimistic value first.
A risk event has a chance of happening and an impact if it does, on the tasks it affects. Keep it out of the ranges, so it is not counted twice.
Tasks done by one crew, or priced from one rate, run late together. Model that shared cause, or the total looks more certain than it is.
Each iteration draws every duration, cost and risk, works the dates through the network and records the finish date and total cost.
The S-curve gives the chance of every date. The tornado diagram and the criticality index show what drives it.
The network matters. A simulation that only adds durations up, as a spreadsheet does, misses what happens where paths meet. The step that most often goes wrong is the fourth: treating every task as independent when several share a cause. Our three-point estimating guide shows how far that alone can move a P80.
How many iterations? Enough that the number you report stops moving when you run again. A few thousand settle a P80; a P95 or a small chance needs more. Our article on how many Monte Carlo iterations you need shows how to check.
The S-curve shows, for every date, the chance of finishing by then. Read across from a confidence level to the curve and down to the date. The P50 is the date with an even chance; the P80 is the date you have an 80% chance of meeting. The same reading works for cost, with the total cost on the axis instead of the date.
In the simulator, with the permit risk on, the P50 is day 96 and the P80 is day 106. Move the slider to 90% and the date goes out to day 112. Each extra step of confidence costs more time than the one before, because the curve flattens towards the top.
One schedule, four answers
Finish date of the six-task example. The dashed line is the plan: day 88, from the most likely durations.
Each step adds something real projects have, and each one moves the P80 later. Simulations of 2 million runs.
Which confidence level to commit to is a business decision, not a statistical one. Many teams plan to the P80. Some owners set the budget at the P50 and hold the gap to the P90 as contingency they control. Either way, say which one you used. Our guide to calculating cost contingency works through the cost side.
In earned value management, “S-curve” means something else: the cumulative cost or progress planned over time. It has the same shape for a different reason. In risk analysis, the S-curve is the cumulative probability of the finish date or the total cost.
For three reasons that the plan cannot show. Most task ranges are skewed towards running late. Where paths meet, the later one sets the date, which is called merge bias. And risk events add delays that are not in any task’s duration. Each one moves the date later, so the plan date is rarely the likely one.
Three reasons the simulated date is later than the plan
Plan to expected
88 to 92 days
Most tasks have more room to run late than to finish early, so each task’s expected duration is above its most likely one.
Day-100 chance
94% to 86%
Where two paths meet, the later one sets the date. The shorter equipment path still finishes last in 29% of runs.
86% to 63%
A 30% chance of a permit objection on site preparation adds 10 to 30 days when it happens, and the plan never shows it.
Classic PERT handles the first reason only. It adds up the expected durations along the critical path and treats the total as a normal curve, which gives a 94% chance of finishing by day 100. The simulation of the same estimates gives 86%, because in 29% of runs the equipment path finishes last. Add the permit risk and the chance falls to 63%.
The criticality index puts a number on this. It is the share of runs in which a task is on the critical path. A task with a high index but a narrow range rarely matters; one with a wide range and a fair index can. The simulator shows both paths’ indexes as you change the settings.
A tornado diagram ranks the tasks and risks by how strongly each one drives the finish date or the total cost. The biggest driver is the longest bar at the top, so the chart narrows like a tornado. It tells you where reducing uncertainty, or managing a risk, would do most for the date.
Tornado diagram: what drives the finish date
The six-task example with the permit risk. Longer bars move more closely with the finish date.
Spearman rank correlation between each item and the finish date, from the simulation. Equipment delivery has the widest range but sets the date in only one run in five, so it ranks last.
Here the permit objection dominates, with a rank correlation of 0.73. Design and installation come next, at about 0.3, because every run passes through them. Equipment delivery has the widest range of any task but ranks last: it sets the date in only about one run in five. A wide range is not the same thing as a big driver.
Tornado diagrams come in two kinds. The one above comes from the simulation and uses correlation. The other moves one input at a time from its low to its high value and plots the swing in the result. Our guides to tornado charts and sensitivity analysis in Excel cover both.
Tamara gives you this ranked list of drivers for the dates and costs of your own schedule. Try it free for 15 days.
In the PMBOK Guide’s Perform Quantitative Risk Analysis process. The sixth edition lists four data analysis techniques there: simulation, sensitivity analysis, decision tree analysis and influence diagrams. A question asking for the chance of meeting a date or budget points to Monte Carlo simulation. A question about which risk matters most points to a tornado diagram.
Expected monetary value (EMV) is the formula behind decision trees: probability × impact. The permit objection has a 30% chance and an average impact of 16.7 days, the PERT estimate of 10, 15 and 30 days. Its EMV is 5 days.
In the simulation, the risk adds 4.6 days to the expected finish. That is a little less than 5, because in some runs the site path has slack that absorbs part of the delay.
A decision tree, worked as expected values
Suppose each day of delay costs €8,000. An objection then costs about €133,000 on average (16.7 days). The meeting costs more up front and less in expectation.
Cost of the option
€0
Chance of an objection
30%
Expected monetary value
0.30 × €133,000 = €40,000
€12,000
10%
€12,000 + 0.10 × €133,000 = €25,300
Expected monetary value (EMV) = probability × impact. Choose the branch with the lower expected cost: the meeting, by about €14,700.
A decision tree compares options by their expected values. In a drawn tree, a square marks the decision and circles mark the chance events, each with its probability and cost. Work back from the outcomes, and pick the branch with the best expected value. The formulas for three-point estimates, standard deviations and path variances are in our three-point estimating guide.
Most bad results come from the inputs, not the simulation. Ranges that are too narrow, tasks treated as independent when they share a cause, and a schedule whose logic is broken all give an answer that looks precise and is too optimistic.
Five common mistakes
People anchor on the plan. Ask for the pessimistic value first, and check each range against what happened on past projects.
Tasks that share a crew, a supplier or a rate run late together. Leaving that out makes the P80 too early.
Open ends and hard constraints stop delays from flowing through. Check the logic before you simulate.
A one-off risk belongs in a risk event, not also in the task’s pessimistic value.
The plan in our example has a 13% chance of being met. Choose a confidence level for the commitment, and say which one.
The fix for most of these is in how the model is built. Tamara checks the schedule with its Schedule Audit before it simulates. It describes uncertainty by kind of work, so when one kind of work runs slow, every task of that kind runs slow, and it keeps risk events separate from the ranges.
You need a tool that follows the schedule’s logic, not one that only adds durations up. Spreadsheet add-ins such as ModelRisk suit cost models and simple sequences; our Monte Carlo simulation in Excel guide shows how. For a schedule with parallel paths, simulate the schedule itself.
Tamara, our schedule risk software, simulates the schedule you already have. It has been tested on schedules of 80,000 tasks.
What Tamara does with a whole schedule
Imports from Primavera P6, Microsoft Project or Microsoft Planner Premium. Your file is never changed.
Define a few uncertainty levels once and give each task a level. Tamara turns them into ranges.
One productivity factor per kind of work moves every task of that kind. Risk events, weather included, get their own chance and impact.
P50 and P80 dates and costs, and a ranked list of what drives them.
Try Tamara on your own schedule with the free 15-day trial. For the method on a P6 schedule step by step, see our guide to schedule risk analysis on a Primavera P6 schedule. Our review of project risk analysis tools compares the main options.
No. PERT uses three-point estimates and simple arithmetic along one critical path. Monte Carlo simulation uses the same kind of estimates but recalculates the whole network thousands of times, so it captures merge bias, risk events and tasks that move together. On the same schedule it usually gives a later P80.
The date the project has an 80% chance of meeting, read from the S-curve of the simulated finish dates. It is a common choice for a committed date, because it leaves a one-in-five chance of running later.
For costs and simple sequences of tasks, yes. Our free three-point estimating template simulates up to 20 tasks in a row. A schedule with parallel paths needs the network logic, which a spreadsheet does not have.
They show the same simulated results. The histogram shows how often each finish date came up; the S-curve adds them up from the left, so you can read the chance of finishing by any date. For commitments, the S-curve is the one to read.
Import your Primavera P6 or Microsoft Project schedule, describe its uncertainty and risks, and commit to dates and budgets at a confidence level you choose.