New to this topic?
We recommend reading these guides first to get the most out of this one:
1,000+
Simulation Iterations
P80
80th Percentile Target
All
Paths Considered
Fix
PERT's Merge Bias

What Is Monte Carlo Simulation?

Monte Carlo simulation is a technique that models uncertainty by running thousands of random scenarios. For project scheduling, it works by assigning probability distributions to each task duration, then simulating the entire project thousands of times — each time randomly sampling a duration for each task from its distribution. The result is not one answer but a probability distribution of project completion dates.

Where PERT gives you a single expected duration with a standard deviation, Monte Carlo gives you a full picture: "There is a 50% chance of finishing by June 15, an 80% chance by July 2, and a 95% chance by July 18." This is far more useful for setting realistic commitments.

Why Not Just Use PERT?

PERT has two fundamental limitations that Monte Carlo solves. First, PERT only considers variance on the critical path — but in a real project with many parallel paths, near-critical paths can become critical in specific scenarios, adding risk that PERT ignores. Second, PERT underestimates duration at merge points where multiple paths converge. Monte Carlo naturally handles both by simulating every possible outcome across all paths.

How It Works

Build the project networkCreate the CPM network with all tasks and dependencies. This is the same DAG you would build for any scheduling method.
Assign probability distributionsFor each task, define a probability distribution for its duration. Most commonly: triangular (optimistic, most likely, pessimistic — same inputs as PERT), beta, or lognormal. Different tasks can use different distributions.
Run thousands of simulationsFor each iteration (typically 1,000-10,000): randomly sample a duration for every task from its distribution, then calculate the project duration using CPM logic. Record the result.
Analyze the resultsPlot the histogram of project durations. Calculate percentiles: P50 (50% chance), P80 (80% chance), P90 (90% chance). Identify which tasks appear on the critical path most frequently (criticality index).
Set commitments based on confidenceChoose a confidence level appropriate to the situation. Internal targets: P50-P60. Customer commitments: P80-P90. Contractual deadlines: P90-P95.

Key Outputs

OutputWhat It ShowsHow to Use It
Completion Date HistogramDistribution of possible finish datesVisualize the range of outcomes. Narrow = low risk. Wide = high risk.
S-Curve (Cumulative)Probability of finishing by any given dateRead off the confidence level for any proposed deadline.
P50, P80, P90 DatesDates at specific confidence levelsP50 for planning, P80 for customer commitments, P90 for contracts.
Criticality Index% of iterations where each task is on the critical pathTasks with high criticality index (even if not always critical) need management attention.
Sensitivity AnalysisWhich task uncertainties most affect the project outcomeFocus estimation improvement and risk mitigation on the most sensitive tasks.

Common Probability Distributions

DistributionInputsBest For
TriangularMin, Most Likely, MaxSimple, intuitive. Good for tasks where you can estimate three points. Most commonly used.
Beta (PERT)Min, Most Likely, MaxSame inputs as triangular but with smoother tails. More realistic for task durations.
LognormalMean, Std DevTasks that can take much longer than expected but not much shorter (right-skewed). Common in construction and software.
UniformMin, MaxWhen you have no idea about the most likely duration — equal probability across the range.

Worked Example

A 4-task project with two parallel paths merging at the end:

Path 1: Task A (5-8-14 days) → Task B (3-5-10 days)
Path 2: Task C (4-6-12 days) → Task D (2-4-8 days)
Both paths merge at: Task E (1-2-3 days)
PERT expected: Path 1 = 8.5 + 5.5 = 14 days. Path 2 = 6.7 + 4.3 = 11 days. PERT says: 14 + 2 = 16 days.
MethodResultNotes
PERT Expected16.0 daysOnly considers Path 1 (critical path) variance. Ignores Path 2.
Monte Carlo P5016.8 daysAccounts for scenarios where Path 2 becomes critical (merge bias).
Monte Carlo P8019.5 days80% confident: allows for things going somewhat wrong.
Monte Carlo P9523.1 days95% confident: covers most bad scenarios.

PERT Underestimates by ~5% at the Merge

In this simple 2-path example, PERT underestimates P50 by about 5%. In real projects with 5-10 parallel paths merging, the underestimation can be 10-20% or more. This is the "merge bias" problem, and it is why Monte Carlo is valuable for any project with significant parallelism.

PERT answers a different question The path PERT ignores runs to 23 days — seven past PERT's whole answer. A merge waits for whichever path finishes last, and PERT only ever carried the critical one.

Both ranges are the page's own task estimates: the minimum of a sum is the sum of the minimums, so Path 1 plus the merge runs 5+3+1 to 14+10+3 days and Path 2 plus the merge runs 4+2+1 to 12+8+3. Adding the merge task to both puts them on one axis of project duration, and PERT's 16.0 days is then just the top bar's mean. Everything to the right of it on the second bar is a run in which the merge is waiting on Path 2 while PERT has stopped looking — it carries only the critical path's variance. That is the whole of the 5% underestimate the page reports, and the page's own note that it reaches 10–20% with five to ten parallel paths follows from the same shape. No distribution is drawn inside the bars; the four percentiles underneath are the page's own simulation output and carry that.

Monte Carlo in Manufacturing Operations

ApplicationValue
Plant turnaround planningHundreds of parallel activities merging at startup. Monte Carlo gives a realistic go-live date distribution.
NPI launch datesSet customer launch commitments at P80 instead of the "expected" date that only has 50% chance.
Capital project approvalPresent the board with a range: "90% confident within $X and Y weeks" rather than a single point estimate.
Bid/proposal estimationPrice and schedule bids at a confidence level that balances competitiveness with risk.
Contingency sizingInstead of adding an arbitrary 10% contingency, calculate the difference between P50 and P80 as a data-driven reserve.

Implementation

✅ Best Practices
  • Run at least 1,000 iterations (5,000-10,000 for stable results)
  • Use three-point estimates from the team — do not invent numbers
  • Model correlations between related tasks when possible (bad weather delays all outdoor work)
  • Present results as a range with confidence levels, not a single number
  • Focus sensitivity analysis on the top 5-10 most influential tasks
❌ Common Pitfalls
  • Garbage in, garbage out — simulation cannot fix bad estimates or missing dependencies
  • Overcomplicating distributions when triangular works fine for most tasks
  • Using results without explaining confidence levels — "it will take 19 days" vs. "80% chance of 19 days"
  • Ignoring the criticality index — it tells you where to focus risk mitigation
  • Running simulation on an incomplete or incorrect network diagram

🎯 Key Takeaway

Monte Carlo simulation is the most honest way to answer "When will this project finish?" It replaces single-point estimates with probability distributions that account for uncertainty on every task and across every path in the network. Use it whenever the stakes are high (customer commitments, capital approvals, turnaround planning), present results as confidence levels not point estimates, and focus your risk mitigation on the tasks with the highest criticality index. It is not complicated — it is just running CPM thousands of times with randomized inputs. The insight it provides is worth orders of magnitude more than the effort.

Interactive Demo

Run hundreds of Monte Carlo iterations and watch the completion time histogram build in real time. See how P50, P80, and P95 estimates compare to single-point guesses.

⚡
Try It Yourself
Monte Carlo Schedule Simulator
▼
Run hundreds of simulations to see the probability distribution of project completion time. Each iteration samples random durations for each task using PERT distributions.
TaskOptimisticMost LikelyPessimistic
Design3d5d10d
Build8d12d20d
Test2d4d8d
Deploy1d2d5d
500
1002000
Ready for the full knowledge check? Test your understanding with guided scenarios and data export.
PROTake the Pro Knowledge Check →
Free forever · Every feature included

Stop reading, start modeling

Model your process flow, run simulations, optimize staffing with TOC math, and test your knowledge with 107 interactive checks — all in one platform.

Open Workbench →

Take this to a room

The running order

For schedulers with high-stakes commitments. They should leave able to explain P50 versus P80 and to pick a confidence level deliberately.

7 beats · 11 min
  1. 1

    Run the schedule a thousand times

    That is the whole method. Sample every task's duration, compute the project, record it, repeat.

    • Same network you would build for CPM.
    • Each task gets a distribution instead of a number.
    • One thousand to ten thousand iterations gives a stable answer.

    Ask the room How many possible outcomes does our current schedule show?

  2. 2

    The output is a distribution

    Not a date. A histogram, and from it any confidence level you want.

    • P50: half the time you finish by then.
    • P80: eight times in ten.
    • P90, P95 for contractual commitments.
    • The spread is as informative as the middle.
  3. 3

    Match the confidence to the stake

    There is a sensible convention, and using it makes the commitment conversation straightforward.

    • Internal targets: P50 to P60.
    • Customer commitments: P80 to P90.
    • Contractual deadlines: P90 to P95.
    • Committing at P50 to a customer means a coin flip, said out loud.

    Ask the room What confidence are our external commitments made at?

  4. 4

    It fixes PERT's merge bias

    This is the technical reason to reach for simulation on a complex network.

    • PERT computes variance on the critical path only.
    • When many paths merge, the merge waits for the slowest, not the average.
    • Simulation considers every path in every iteration, so it captures that naturally.
  5. 5

    The criticality index

    An output people miss, and it is arguably more useful than the date.

    • It tells you how often each task lands on the critical path across all iterations.
    • A task critical 80 per cent of the time deserves attention even if today's schedule says it has float.
    • That is where risk mitigation should go.
  6. 6

    Triangular is usually enough

    Do not overcomplicate the distributions. Three-point estimates from the team beat invented sophistication.

    • Optimistic, most likely, pessimistic - the same inputs as PERT.
    • Beta or lognormal when there is a reason, not by default.
    • Model correlation where it is real: bad weather delays all outdoor work at once.
  7. 7

    Garbage in, garbage out

    Simulation cannot repair bad estimates or missing dependencies. It just gives them a distribution.

    • The network has to be right first.
    • Estimates come from the team, not from the analyst.
    • And always present the result with its confidence level, never as a bare number.

    Ask the room Which upcoming commitment is worth simulating?