How likely is that date, really?

Run the whole network thousands of times with uncertain durations. The spread of finish dates is the honest answer — and the criticality index shows which activities a deterministic plan is hiding from you.

HomeProject Management › Monte Carlo

Run the schedule a few thousand times

Sample every duration, recompute the critical path, repeat. The spread of finish dates is the answer — and so is which activities turn critical along the way.

Local tool — your project data stays in your browser
A planning aid, not a commitment. Everything here is calculated from figures you typed. A schedule is only as good as its estimates and its dependencies, and neither of those is something arithmetic can check for you. Treat the output as a way to test a plan, not as a promise to anyone about a date.

Activities

Same predecessor syntax as the critical path calculator: A, B:SS+2, C:FF-1.

The run

Same seed, same answer.

Where the finish date lands

Confidence

Criticality — how often each activity mattered

The proportion of runs in which each activity landed on the critical path. This is the output a deterministic schedule cannot give you.

← Deterministic critical path
Your project stays in this browser. Task names, owners, durations, dates and estimates are calculated on your own device. Nothing is uploaded, stored on a server, or included in analytics — project content is never passed to the advertising or analytics scripts on this page.
How the simulation works

Each iteration draws a duration for every activity from its own three-point estimate, then runs the full CPM forward and backward pass on those sampled durations. The project duration is recorded, and so is which activities came out with zero float.

The critical path is recomputed every run rather than assumed. That is the entire reason this exists. Single-path arithmetic fixes the critical path in advance and cannot see a shorter, more variable chain overtaking it — which happens more often than most plans allow for.

Beta-PERT is sampled properly from the beta distribution its weighting implies, using α = 1 + 4(m−o)/(p−o) and β = 1 + 4(p−m)/(p−o). A common shortcut is to draw from a triangular distribution and call it PERT; the two have visibly different shapes and the beta is less pessimistic in the tails.

The seed is exposed so a forecast can be reproduced exactly. A number nobody else can regenerate is an anecdote, not an analysis.

Percentiles are read from the sorted sample, interpolating between neighbours — not from a normal curve fitted to it. The distribution of a project finish is usually skewed right, and forcing a symmetric curve onto it understates the tail that actually hurts.

Why the average finish date is nearly useless

Add up the most likely durations along the critical path and you get a date. Roughly half of all outcomes land later than it, and it is frequently a good deal worse than half — because parallel paths mean the project waits for the slowest of several chains, and the slowest of several is later than the average of any one.

This is why deterministic schedules are optimistic in a way that feels unfair. Nothing went badly wrong; the plan simply asked for every one of several independent things to go about as well as expected, at once.

The criticality index is the real output

A deterministic schedule sorts work into critical and not-critical. Reality is not that tidy. An activity might be on the critical path in 45% of runs — never critical on the plan, and quite capable of deciding the finish date.

Those activities are invisible to ordinary scheduling and they are precisely where attention pays. A task with a criticality index of 45% and no float in half the futures you might live in deserves the same scrutiny as one marked critical on the plan, and typically gets none.

What the percentiles are conditional on

Everything here rests on your three-point estimates being honest, and on the activities varying independently. That second assumption is almost always optimistic.

Real delays are correlated. The specialist who is unavailable holds up four things. The supplier who is late affects everything downstream of them. A team that estimates optimistically does so consistently, across every task. Correlated delays make the true distribution wider than any independent simulation shows, so the honest reading of a P80 here is a P70-ish in practice.

More iterations do not make it more true

Going from a thousand runs to twenty thousand makes the percentiles more stable — it does not make them more accurate. The limit on accuracy is the quality of the estimates and the independence assumption, and no amount of computation improves either.

Running twenty thousand iterations on numbers somebody guessed in a meeting produces a beautifully smooth histogram of a guess.