Your schedule produces one completion date. That date is not wrong so much as incomplete — and on a programme with any real parallelism, it is optimistic by construction rather than by accident.
Deterministic: one duration per activity, one completion date. Simple, universally understood, and silent about how likely that date is.
Probabilistic: a range per activity, the network recalculated hundreds or thousands of times, and a distribution of dates out the other end. You read confidence off it — P50, P80 — instead of guessing.
The catch that matters: a single date is systematically optimistic wherever paths converge, because a milestone waits for the last path to arrive, not the average one. That is merge bias, and it gets worse the more complex the programme.
Take a milestone with four chains of work feeding it. Each is forecast to take twelve weeks, and each has a genuine chance of running over.
Deterministic calculation says twelve weeks. The milestone starts when all four are done.
But the milestone does not wait for the average path — it waits for the slowest one. If each chain independently has a reasonable chance of finishing on time, the chance that all four do is much lower, because they all have to come good together. The more chains merging, the lower it gets.
This is merge bias, and it is not a modelling nicety. It is why complex programmes are late in a way simple ones are not — and why the deterministic date sails past unchallenged right up until it does not.
Every construction programme is full of these convergences: services rough-in waiting on multiple trades, commissioning waiting on every system, practical completion waiting on everything. A deterministic critical path finds the longest chain today. It does not tell you how many other chains are one bad week from becoming the longest one.
| Deterministic | Probabilistic | |
|---|---|---|
| Input per activity | One duration | A range — optimistic, likely, pessimistic |
| Output | One completion date | A distribution of completion dates |
| Answers | When will we finish? | How likely is any given finish date? |
| Merge bias | Ignored entirely | Captured — it emerges from the simulation |
| Contingency | A judgement call, usually a round number | Measured — the gap between P50 and P80 |
| Effort to set up | None beyond the schedule | Duration ranges on the activities that matter |
| Understood by | Everyone | Needs explaining once, then it sticks |
| Fails when | Paths converge, which is always | The underlying schedule is unsound |
Both are read straight off the distribution, and the difference between them is the most useful number in the exercise.
The date you have a 50 per cent chance of meeting. As likely to be late as early. It is roughly what a deterministic forecast gives you, and it is not a commitment — it is the midpoint of a spread, presented as though it were a plan.
An 80 per cent chance of meeting it. This is the number to give a client, a financier or a board, because it is the one where being wrong is the exception rather than the coin landing the other way.
If P50 is late October and P80 is mid-January, that eleven-week gap is the time contingency the programme needs. Not a round number someone added at the end. This is the single most valuable output, and it is the one people skip past on the way to the date.
The same logic applies to cost. A P80 cost forecast is what the contingency line should be sized against, rather than a percentage inherited from the last job.
I ran a schedule risk analysis by Monte Carlo on a programme where the deterministic dates for Critical Design Review and the Acceptance events looked settled. The simulation put both materially later.
The driver was the non-recurring engineering approaching the review — that was the riskiest work in the network, and it fed a convergent milestone, so its variability dominated an outcome the single-date view showed as comfortable.
Two things changed as a result. Additional float was placed into the schedule approaching that review, and early funding for the non-recurring engineering was approved to pull the risk forward rather than carry it into the review.
That is the point of the exercise. Not a more pessimistic date — a decision about float and funding that the deterministic schedule gave nobody a reason to make.
Less mysterious than it sounds, and worth understanding before trusting it.
One refinement worth knowing about: if two activities share a cause — the same weather, the same subcontractor, the same approval authority — they should be correlated, or the simulation assumes their bad luck cancels out and returns a distribution that is too narrow. Uncorrelated simulation is the most common way this technique flatters a programme.
The most important caveat on this page. Simulation propagates uncertainty through the network's logic — so open ends, hard constraints and missing links produce a confident-looking distribution built on a broken model. That is worse than a single date, because it borrows the authority of statistics. Run the quality checks first.
Little convergence means little merge bias, and the deterministic date is close enough. Save the effort.
If the completion date is contractually fixed and there is no contingency conversation to be had, a distribution is information without a decision attached. Worth knowing; not worth building.
Garbage ranges produce a precise-looking distribution of nothing. If nobody can give you a credible pessimistic case, that is a conversation to have before it is a model to build.
Aegis runs a Monte Carlo simulation on your live schedule and reports completion at P50 and P80 alongside the deterministic date, so the gap between "the date on the programme" and "the date you could commit to" is visible every month rather than at the end.
The numbers are computed, not generated. The critical path, the earned value and the simulation all come from an engine you can audit — the AI in the product writes the assessment of what those numbers mean, and cannot invent a figure or be talked into a friendlier one. That distinction is worth applying to every vendor in this category, including us.
It reads the schedule you already maintain in P6, MS Project, Excel or CSV. Nothing is written back, and your planners keep working exactly as they do now.
Deterministic takes one duration per activity and gives one date. Probabilistic takes ranges, runs the network many times, and gives a distribution you can read confidence off.
The dates you have a 50% and 80% chance of meeting. The gap between them is your real time contingency — usually wider than teams expect.
Merge bias. Where paths converge, the milestone waits for the slowest one, not the average. Deterministic calculation ignores this, and the effect grows with complexity.
Enough that the answer stops moving between runs. Hundreds gets you close on most construction networks; thousands is cheap insurance. Precision beyond that is false comfort given the input ranges are estimates.
When the schedule underneath is unsound — that produces confident nonsense. Also on short sequential work with little convergence, and when nobody will act on the answer.
Aegis runs the simulation on the schedule you already maintain and reports P50 and P80 beside the deterministic date every period — so contingency is measured rather than inherited.
Start your 14-day trial →