PERT Three-Point Project Risk & Critical Path Simulator

Your engineering team committed to a December 15 launch date. Eleven tasks, four of which sit on the critical path. The team gave you optimistic and pessimistic estimates for each task. The question for the steering committee: how confident are you in December 15, and what’s the date you can defend at 90% confidence?

That’s a project-specific schedule-risk problem, not a general simulation problem. PERT three-point estimation, critical-path analysis under stochastic durations, and tornado-chart sensitivity together give you a defensible answer: “There’s a 75% chance we finish by January 8, 90% chance by January 22.” Behind those numbers sit thousands of simulated schedules, each sampling task durations from three-point estimates and respecting the dependency chain.

The common mistake in project planning is quoting the most-likely total as the deadline. That number has roughly a 50% chance of being exceeded because delays compound along the critical path. The gap between P50 and P90 is your risk buffer in concrete units (days, weeks, dollars). If P50 is 14 weeks and P90 is 17 weeks, a three-week buffer covers most downside scenarios. If P90 is 24 weeks, the project has a structural uncertainty problem that no buffer can paper over. You need to re-scope.

For general Monte Carlo simulation across any quantitative model with uncertain inputs (financial models, capacity planning, demand forecasting, lab experiments), see the general Monte Carlo simulation primer. This page is built specifically for the PERT-and-critical-path workflow that PMOs run on schedule and cost risk.

Every task in the project gets three duration estimates. The optimistic value is the fastest you could finish if nothing goes wrong, not a fantasy, a realistic best case. The most likely is the duration you would commit to in a normal sprint. The pessimistic is the duration if a major blocker appears: an external dependency delays, a key person is unavailable, or the spec changes mid-task.

The simulation draws a random duration for each task from a triangular or Beta-PERT distribution defined by these three points. Beta-PERT is what classical PERT (the 1958 Polaris program origin) actually used: a smoother distribution with mean t_E = (O + 4M + P)/6 and variance σ² = ((P − O)/6)². The triangular alternative is computationally simpler but has thicker tails and tends to overstate variance. For most planning purposes the difference is small; choose Beta-PERT when stakeholders expect classical PERT outputs and triangular when speed of computation matters more than the exact distribution shape.

The shape of the triangle (or Beta-PERT) matters: if the pessimistic tail is much longer than the optimistic one (say, 3-5-15 days), the distribution is right-skewed and the mean is pulled above the mode. This is why summing most-likely values understates the total. The right tails compound across tasks even when the modes don’t.

A useful calibration: ask the estimator “would you bet your bonus that the task finishes within your pessimistic estimate?” If they hesitate, the pessimistic number is too tight. Run the calibration question on every task before trusting the inputs.

The deterministic critical path is the longest sequence of dependent tasks through the project network when each task has a single duration. With three-point estimates, every task has a probability distribution over its duration, which means the critical path itself is probabilistic. In some simulation runs, a task that’s technically “off the critical path” under most-likely durations becomes the bottleneck because its pessimistic case dragged its parallel chain longer than the deterministic critical path.

The simulation captures this by recomputing the critical path in every iteration. The criticality index for each task is the percentage of iterations in which the task fell on the critical path. A task with a 40% criticality index is a hidden risk even if it’s not on the deterministic critical path. Two effects worth watching: a near-critical path with one high-variance task can swap into criticality regularly, and a deterministic-critical task with very tight estimates may not actually drive variance even if its mean duration is large.

Output to read: tasks ranked by criticality index. Anything above ~30% deserves attention even if the deterministic CP doesn’t flag it. Anything below ~5% is genuinely off the critical path under all reasonable scenarios and can be ignored from a schedule-risk standpoint.

After running the simulation, a tornado chart ranks each task by its contribution to total timeline variance. Tasks on the critical path with wide estimate ranges dominate the chart. A task estimated at 3-5-7 days contributes little variance. A task estimated at 2-5-20 days dominates it.

The math behind the bars: for each task, the chart shows how much the project completion date shifts when that task’s duration moves from its 10th percentile to its 90th percentile, holding all other tasks at their median. The widest bars are the highest-impact de-risking targets. The usual fix is to prototype the high-variance task first or add a spike to tighten its uncertainty range. Splitting the task into smaller pieces with tighter individual bounds is the heavier-handed alternative when prototyping isn’t an option.

Tornado charts also reveal hidden coupling. If two tasks rank high on the tornado but they’re assigned to the same person, their durations are correlated and the simulation (which assumes independence) understates the true tail risk. The fix is to add explicit resource constraints to the model or rebalance assignments before running the simulation.

Schedule risk and cost risk look related but answer different questions. Schedule risk is “when will this finish?” and depends on the critical path through the dependency network. Cost risk is “what will this cost?” and depends on the sum of all task costs, regardless of dependency. A task that’s off the critical path but expensive contributes nothing to schedule risk and a lot to cost risk.

The decomposition matters because the two distributions usually correlate but not perfectly. Labor costs scale with duration (more days means more wages), so any task that runs long tends to also cost more. But fixed-price materials, equipment-rental contracts with weekly minimums, and overhead allocations break that correlation. The simulator runs both distributions in parallel and reports schedule-cost correlation as a single number (typically r = 0.6 to 0.8 for software projects, lower for capital construction where material costs dominate).

For reporting, the joint distribution matters more than the marginals. A 90% chance of hitting the deadline AND a 90% chance of staying under budget gives a joint probability typically around 80% (if correlation is 0.7) rather than 81% (which would be the independent case). For a contract that includes both schedule and cost penalties, the joint metric is what matters. Always report the joint percentile next to the marginals.

Schedule reserves and cost reserves should be sized separately. A 15% schedule reserve and a 15% cost reserve don’t imply a 15% joint reserve. Run the joint distribution and pick reserve levels from the actual joint quantiles, not the products of marginals.

Does the P50 match your gut? If the simulation says P50 is 22 weeks but your experienced PM says “feels like 14,” either the estimates are padded or the PM is ignoring dependencies. Investigate the gap before presenting results.

Is the P90/P50 ratio reasonable? For a well-estimated project, P90 is typically 1.3 to 1.6 times the P50. Ratios above 2.0 suggest one or more tasks have extremely wide ranges. Tighten the estimates or split the tasks. Ratios below 1.1 suggest the team isn’t acknowledging real uncertainty.

Do the dependency chains make sense? A simulation that allows tasks to start before their predecessors finish will produce optimistic results. Verify the dependency graph before interpreting outputs. Check that parallel tasks are genuinely parallel: if the same person does both, they’re effectively sequential and the simulation overstates how much time the parallelism saves.

Estimates anchored to deadlines instead of work. If the team knows the deadline is week 12, their “most likely” estimates will cluster around values that sum to 12 weeks. The simulation then confirms the deadline with high probability, a circular validation. To break the loop, estimate each task in isolation before revealing the aggregate.

Three-point estimation and critical-path aggregation use these formulas:

Scenario: A sprint has five tasks. Task A (API design: 2/3/5 days) feeds Task B (backend build: 4/7/14 days). Task C (UI design: 1/2/3 days) feeds Task D (frontend build: 3/5/8 days). Task E (integration test: 2/3/6 days) depends on both B and D. Two paths exist: A→B→E and C→D→E.

Deterministic estimate: Path 1 most-likely total = 3+7+3 = 13 days. Path 2 = 2+5+3 = 10 days. Critical path is A→B→E at 13 days.

Simulation (10,000 runs): P50 = 15 days, P80 = 18 days, P90 = 21 days. Task B has a criticality index of 82%, which means it dominates the timeline in most runs. Task D has a criticality index of 31% because its pessimistic case (8 days) can push path 2 past path 1 in some iterations.

Tornado read: Task B contributes ~5 days of P50-to-P90 spread. Task D contributes ~1.5 days. Tasks A, C, and E contribute under 1 day each. De-risk Task B first. Can the backend build be split into two smaller tasks (model design, then API integration) with tighter individual bounds?

Action: The deterministic plan says 13 days. The P90 says 21 days. Quote 18 days (P80) to the stakeholder with a note that 21 days is the downside if Task B hits its pessimistic case. If the contract has a hard deadline, negotiate the 21-day version with explicit acknowledgment that it’s the 90% confidence number, not the typical case.