Monte Carlo schedule risk analysis: how likely you are to finish on time

A payroll switch has two parallel branches of 10 working days each, then a 3-day parallel payroll, so the plan says go-live on day 13. Recalculate it 5,000 times with honest ranges on the two branches and day 13 is met in about 17% of the iterations.

The guide to estimating task durations introduces P50 and P80 dates. This guide explains where the gap between the plan and the P50 comes from, and on which plans a Monte Carlo schedule risk analysis is worth running. The example is small enough to recompute by hand; only the rank correlations come from a 5,000-iteration run.

What Monte Carlo schedule risk analysis is#

Monte Carlo schedule risk analysis is a method that recalculates a schedule thousands of times with randomly drawn task durations and reports the finish as a distribution of dates, each with a probability of being met. It exists because a single finish date carries no information about how likely it is, and the Government Accountability Office (GAO) notes in its Schedule Assessment Guide that, unless a statistical simulation is run, a completion date calculated from schedule logic and duration estimates tends to underestimate the critical path duration^[1]. In the payroll example below the planned day 13 is met in 17% of iterations, and missing the day-14 cut-off means another month on the old payroll system.

Each iteration is an ordinary schedule calculation. Only the durations change; links and calendars stay as in the plan. After 5,000 iterations the finish dates are sorted, and the date that 80% of them meet is the P80, while half of them meet the P50. The probability of meeting a deadline is the share of iterations that finish by it.

Probabilistic duration estimates go back to the Program Evaluation and Review Technique (PERT), described in 1959 for the US Navy's Polaris Fleet Ballistic Missile programme, with activity times supplied by technical staff in probabilistic terms^[2]. In 1966 Klingel showed on a real network that the PERT calculation overstated the chance of finishing on time, worst of all where several parallel branches had similar mean durations and large variances, and proposed simulation to estimate the completion-time distribution^[3].

Who needs a schedule simulation, and when#

A schedule simulation is for the project manager or planner who must commit to a finish date on a plan where two or more uncertain branches merge before the end. The planner builds it, and what reaches the sponsor or the client is usually one number (the P80) and one chart.

Our threshold, a rule of thumb: a plan of about 15 tasks or more with at least one merge point where two branches carrying three-point estimates meet. Below 15 tasks, the arithmetic in this article fits on one sheet of paper. Team size changes little. The four-person payroll team in the example needs the simulation as much as a 30-person programme would, because the drop from 42% per branch to 17% for both comes from the shape of the network alone. The example is cut down to four lines so that every probability can be checked, and the method is the same on a plan of several hundred tasks.

Run it once the first complete plan has links and three-point estimates on the uncertain tasks, before any finish date leaves the team. Run it again when you save a baseline, and whenever the estimate of a driving task changes by more than a day. Each run takes seconds.

A single chain with no merge point can do without the simulation, because a shorter calculation gives the same answer. Add up the PERT means and the variances along the chain, take the square root of the summed variance, and the normal approximation gives the percentiles. Six tasks in a row, each estimated at 8, 10 and 14 days, show how it works: the plan says 60 days, the means add up to 62.0, the classic PERT standard deviation is (14 − 8) / 6 = 1 day per task, so the chain's standard deviation is √6 ≈ 2.4 days and the P80 is about 62.0 + 0.84 × 2.4 ≈ 64 working days. The planned 60 days is met about one time in five. Simulate the chain anyway when it carries date constraints or tasks on different calendars, or when fewer than about five tasks hold all the uncertainty with ranges as lopsided as these, since the normal approximation is poor there. A timeboxed sprint gives the simulation nothing to forecast: the date is fixed and the scope flexes.

What the simulation needs from you#

The simulation needs a three-point estimate (optimistic, most likely, pessimistic) for every task whose duration is uncertain; the most likely value is the duration already in the plan.

The pessimistic value deserves the most care. In a PERT or triangular distribution it is the upper bound: no iteration ever draws a longer duration, so whatever lies beyond it is missing from every percentile.

Our recommendation: ask the person who does the work for the duration they would exceed only in an exceptional case, about one time in a hundred, and enter that as the pessimistic value. A value they expect to exceed one time in ten is a P90. Entered as the bound, it cuts off the tail and brings the P80 and P95 forward. Ask without a manager in the room, so the answer is not shaded towards the date the manager wants.

Past actuals set a floor. Our rule of thumb: with actual durations from five or more past tasks of the same kind, done with the same supplier, the pessimistic value should be no shorter than the longest of them. The reason for five is arithmetic, since a new task takes longer than all n past ones about one time in n + 1, so the longest of five actuals is exceeded about one time in six, still far more often than the one time in a hundred the pessimistic value stands for. With two actuals it would be one time in three, too thin to anchor anything. Actuals from a different supplier do not count.

Two distributions are in common use. The PERT (Beta) distribution gives little weight to the extremes, while the triangular one gives them more, so with the same three numbers the triangular distribution returns later percentiles. GAO's house-construction example uses triangular distributions and notes that others are available^[1]. Tasks with no estimate of their own get a default range, a percentage of the planned duration such as −10% and +30%; keep that default for tasks that carry little risk.

Why parallel branches finish later than the plan says#

A merge point finishes later than its branches suggest because the task after it starts only when the last branch finishes, and the latest of several uncertain dates is, on average, later than any one of them. GAO calls this added risk at merge points merge bias: with two branches at a 60% chance each of finishing on time, the merge milestone is on time only when both are, 36% of the time, and a third branch at 60% brings it down to 22%^[1].

Skew makes it worse. Take one branch planned at 10 days with a range of 8 to 14. The PERT distribution puts about 42% of its probability at or below 10 days, because the long right tail pulls the median above the most likely value, so the planned duration is met fewer than one time in two before any merge happens.

Two independent branches with that shape both finish by day 10 with probability 0.417 × 0.417, about 17%. Three bring it down to 7%, four to 3%.

A worked example: switching a payroll system#

A company with 240 employees moves to a new payroll provider, and the plan says go-live on day 13 against a month-end cut-off on day 14, one day of margin on paper.

Two branches run in parallel. Branch A configures the new system's pay codes and tax tables, and its pessimistic case is the provider delivering this year's tax tables late. Branch B cleans and loads the employee data; what can stretch it is the month's new starters, whose bank details tend to arrive in the last week. Both feed a parallel payroll, where old and new systems process the same month and the payslips are compared line by line. The provider runs it in a booked 3-day service window, so its duration is fixed here.

The working plan has 26 tasks: 14 in branch A, ending with the finance director's sign-off on the payslip template, and 12 in branch B, among them a test import of 20 employee records. The table collapses each branch into one line. Branch A's estimate came from the payroll lead and the provider's implementation consultant, branch B's from the HR data owner, each in a 30-minute session that asked for a three-point estimate of the whole branch, with the pessimistic value set at one time in a hundred. Adding up 14 task-level pessimistic values would have described a branch where every task goes wrong at once.

Durations are in working days. All links are finish-to-start.

The plan is the most likely column. Both branches end on day 10, the parallel payroll takes days 11 to 13 and go-live comes at the end of day 13. A and B both have zero float, so both are on the critical path.

Branch B looks safer, with a range of 9 to 12 against A's 8 to 14, yet it meets 10 days just as often. Both ranges put the most likely value one third of the way from optimistic to pessimistic (2 of 6 days for A, 1 of 3 for B), so the two PERT distributions have the same shape and B is A at half the width. B's tail is shorter in days, and that difference shows up in the risk drivers.

The figures below are exact values for the PERT distribution; a 5,000-iteration simulation lands within about one percentage point of them.

Reaching 80% confidence takes about 14.4 working days, which rounds up to day 15, one day after the cut-off. A missed cut-off means one more month on the old system and a second reconciliation of 240 payslips. The cut-off cannot move, so the plan must change: either the project starts a day earlier, or the tail of the branch that drives the risk gets shorter.

The same iterations rank the branches. Branch A is on the path that drives the finish in 53% of iterations, B in the other 47%. In a 5,000-iteration run the rank correlation between each branch's drawn duration and the go-live date came out at about 0.78 for A and 0.39 for B, because A's range is twice as wide.

Cutting the pessimistic value of A from 14 to 12 days, for instance by getting the tax tables from the provider before configuration starts, lifts the chance of day 14 from 66% to 82%. The same 2-day cut on B, from 12 to 10, gives 72%. If the provider's window could slip, with a range of 3 to 5 days, every percentile would move later, while the merge effect between A and B would stay as computed above.

Reading the percentiles and the contingency

Quote the P80, rounded up to the next whole day, outside the team; in the example that is day 15. GAO measures schedule contingency as the gap between the 80th-percentile date and the deterministic finish, and notes that some programmes treat the 80th percentile as a conservative promise date while others use the 65th or 55th, which leave more exposure to overrun because schedule distributions tend to be skewed to the right^[1].

In the example the contingency is 14.4 − 13 = 1.4 working days. Keep it as one visible reserve in front of the go-live milestone, where everyone can see it being used up.

Our recommendation is P80 by default, because a cut-off like this one turns a late finish into a month's delay. Quote the P50 only when lateness is cheap, and say plainly that it is missed half the time. What goes to the sponsor here is the day-14 figure from the table, together with the two ways to raise it from the test on each branch.

Risk drivers and the criticality index

A risk driver is a task whose drawn duration moves the project finish the most, measured here as the Spearman rank correlation between that duration and the finish date across all iterations. The criticality index is the share of iterations in which a task lies on the path that drives the finish; GAO's guide calls the same measure risk criticality^[1].

The two answer different questions. Criticality counts how often a task sits on that path, and the driver ranking also weighs the width of its range, so a task that is critical in 60% of iterations with a narrow range can rank below one that is critical in 40% with a wide range. In the payroll switch the branches are almost level on criticality, 53% against 47%, while A's correlation is twice B's. The parallel payroll and the go-live milestone are critical in 100% of iterations, since both branches run into them. To decide where the next hour of estimating goes, sort by correlation and read criticality second.

How to run a schedule risk analysis, step by step#

Seven steps take a plan from a single date to a committed P80, and most of the time goes into step 2.

1. Check the links. Every task except the first needs a predecessor, and only the last may have no successor. A task with no predecessor starts on day one in every iteration, so the delays of the work it really depends on never reach it and the simulation finishes too early. The guide to task dependencies covers the link types.
2. Estimate the risky tasks. Pick the 5 to 10 tasks most likely to overrun and get a three-point estimate for each from the person who will do the work. Each estimate is a conversation, and the pessimistic value may need a second question once the first answer turns out to be a P90. The rest keeps the default range.
3. Pick the distribution. Choose PERT or triangular once, and keep it for every version of the plan.
4. Run 5,000 iterations and read the histogram, the S-curve, the percentiles and the probability of the deadline.
5. Rank the drivers. Take the top three tasks by rank correlation and put their criticality index next to them.
6. Test one change on the top driver with the same seed, so the difference comes from the change alone, as with the cut to branch A's tail in the example.
7. Save the P80 and the contingency with the baseline.

Common mistakes#

The mistake with the biggest effect on the result is a flat range on every task, which turns the output into the plan plus a fixed margin. A flat −10% / +30% hides the tasks that really are uncertain and lends the rest a risk they do not have; in the example it would give A and B the same range when A's is twice as wide.

• A P90 entered as the pessimistic value. The tail is cut and the P80 comes out early.
• Quoting the P50 as the forecast. Half the iterations finish later.
• Two versions of the plan compared with different seeds, so part of the difference is sampling noise.
• Trimming estimates until the date fits. GAO warns that changing durations simply because an earlier finish date is preferred is likely to increase the risk of delaying a project^[1]. When the date does not fit, change the logic or the scope, and touch an estimate only when there is new evidence about that task.
• A simulation run before the links are right (step 1).

The limits of Monte Carlo simulation#

A simulation is only as good as its ranges and its independence assumption. Pessimistic values cut to please a sponsor give a P80 earlier than the project can deliver.

Standard simulations draw each duration independently. When one cause slows several tasks together, the real tail is longer than the simulated one. GAO's house-construction example shows the size of the effect: with 90% correlation added between activities of related trades, the P50 barely moved (25 February without correlation, 24 February with it), while the P80 went from 4 to 9 March, one workweek later^[1]. In the payroll switch, a provider that configures branch A and also supplies the import template for branch B ties the two branches together, and the 82% from the test is then too generous.

Duration ranges also miss risk events. A risk that may or may not happen, such as the tax authority rejecting the new employer registration, either adds weeks or adds nothing, and a three-point estimate smears it into a smooth range that matches neither case. When one event can add weeks, put it in a separate task with those weeks in its pessimistic value, or discuss it apart from the percentiles.

How to do it in Planitude#

Open the Risk tab and turn the simulation on. Planitude recalculates the plan 5,000 times by default, with PERT or triangular durations, following the plan's links and constraints; on very large plans the number of iterations is reduced, never below 1,000. Enter optimistic and pessimistic durations in the details of the tasks that need them. To hold a task fixed, like the parallel payroll, give it the planned duration in both fields; tasks left empty use the project's default range.

The tab shows the P50, P80 and P95 dates, the probability of meeting the deadline or any date you choose, a histogram, an S-curve, the risk drivers and the criticality index. The same seed on the same plan gives the same figures, so a test like the one on branch A compares cleanly. Completed tasks stay fixed and tasks in progress simulate only their remaining work, which makes a rerun halfway through the project start from where the plan stands.

Durations are drawn independently, so a risk shared by many tasks widens the tails more than the tab shows. Risk events and cost are not modelled.

Frequently asked questions#