The PERT calculator takes the three numbers a good estimator can actually produce — a best case, a realistic case and a bad case — and turns them into a single expected duration, a measure of how uncertain that duration is, and the probability of hitting a given deadline. It is the standard alternative to asking someone for one number and then quietly adding 20% because you do not trust it.
Arb Digital uses three-point estimating when scoping build work, because a range carries information a point estimate destroys. Two tasks can both be estimated at twelve days and be nothing alike: one might run between eleven and thirteen, the other between four and thirty. This page makes that difference visible and puts a number on it.
What This PERT Calculator Does
Enter your optimistic, most likely and pessimistic estimates and the calculator returns the PERT expected duration — a weighted average that leans heavily on the most likely case while still letting the extremes pull it. It also returns the standard deviation and variance of that estimate, which quantify how wide the range is, and the probability of completing within any target duration you enter.
The last figure is the one project managers tend to want most: the duration you would have to commit to in order to reach a stated confidence level. Setting that to 85% answers a very different question from "how long will it take" — it answers "what date can I promise and still expect to be right five times out of six".
Two extra controls change the model rather than just the inputs. The weight box sets how much emphasis the most likely estimate carries; 4 is the classic PERT value, while 1 produces the simple triangular average of the three points. The tasks-in-series box repeats the estimate along a path so you can see how uncertainty accumulates across a sequence.
How to Use It
- Estimate optimistic (a). How long the work takes if nothing goes wrong. Not the fastest imaginable outcome — the fastest plausible one, roughly a one-in-twenty best case.
- Estimate most likely (m). The duration you would bet on if you had to name one number. This is the mode, not the average.
- Estimate pessimistic (b). A realistic bad run: the usual problems all happening. Exclude genuine catastrophes, or the spread will swamp everything else.
- Set the weight and task count. Leave the weight at 4 unless you have a reason to change it, and raise the task count to model a path of comparable tasks in sequence.
- Enter a target and a confidence level. The target gives you the odds of hitting a date you already have; the confidence level gives you the date to ask for instead.
The Formula / How It's Calculated
The expected duration is a weighted mean: TE = (a + 4m + b) ÷ 6. The most likely estimate carries four of the six units of weight, and the two extremes carry one each, which is why a long pessimistic tail pulls the answer upward but does not dominate it. The general form used here is (a + w·m + b) ÷ (w + 2), so a weight of 4 reproduces the standard formula exactly and a weight of 1 gives the plain triangular average (a + m + b) ÷ 3.
Spread comes from the range alone: SD = (b − a) ÷ 6, and variance is that squared. The six in the denominator comes from treating the optimistic-to-pessimistic range as covering roughly six standard deviations, the same span that holds about 99.7% of a normal distribution.
Work the defaults through. With a = 8, m = 12 and b = 22, the expected duration is (8 + 48 + 22) ÷ 6 = 78 ÷ 6 = 13.00 days — a full day longer than the most likely estimate, because the tail runs further above the mode than below it. The standard deviation is (22 − 8) ÷ 6 = 2.33 days, giving a variance of 5.44. Testing a 14-day target gives a z-score of (14 − 13) ÷ 2.33 = 0.43, and the normal distribution puts about 66.6% of the probability below that point. To reach 85% confidence you would need 13 + 1.036 × 2.33 = 15.42 days.
The Assumptions This Model Rests On
PERT is not assumption-free arithmetic, and the assumptions are where estimates go wrong. Two matter most.
It assumes a beta distribution for each task. The (a + 4m + b) ÷ 6 formula is an approximation to the mean of a beta distribution bounded by the optimistic and pessimistic values, chosen because a beta can be skewed and bounded in a way a normal distribution cannot. The NIST/SEMATECH e-Handbook entry on the beta distribution sets out the underlying family and its shape parameters. The approximation is reasonable for moderately skewed estimates and drifts from the true beta mean when the mode sits very close to either bound.
It assumes tasks are independent. Summing variances across a path is only valid when a delay on one task tells you nothing about the next. Real projects violate this constantly: the same overstretched specialist works on three tasks, one vendor supplies two deliverables, one architectural decision affects everything downstream. Correlated tasks make the true path variance larger than the sum of the individual variances, so the probability of hitting a date is overstated — sometimes badly. The US Government Accountability Office's Schedule Assessment Guide (GAO-16-89G) treats schedule risk analysis as a discipline in its own right for precisely this reason, and recommends simulation over a single closed-form calculation on programmes where the stakes justify it.
A third, quieter assumption sits behind the probability figure: the path total is treated as approximately normal. That follows from the central limit theorem when a path has many independent tasks, and it is shakiest exactly where people most want an answer — a single task, or a short path of two or three.
Why the Expected Duration Beats the Most Likely Estimate
Ask for one number and you will almost always get the mode: the duration that occurs most often. The trouble is that task durations are asymmetric. They have a hard floor — work cannot take negative time, and there is a limit to how fast it can go — but no ceiling. That asymmetry means the average outcome sits above the most common outcome, systematically.
The defaults show it. The most likely estimate is 12 days, but the expected duration is 13. Repeat that gap across twenty tasks in a plan and a schedule built from modes is roughly twenty days optimistic before anyone has done anything wrong. This is one of the most reliable structural biases in project planning, and three-point estimating removes it almost for free.
How Uncertainty Behaves Across a Path
Set the tasks-in-series box to 4 and watch what happens. The expected duration quadruples, as you would expect. The standard deviation does not — it only doubles, because variances add and standard deviations therefore grow with the square root of the number of tasks. Uncertainty accumulates more slowly than duration does.
This has a genuinely useful consequence: longer paths are proportionally more predictable than short ones. A four-task path at 52 days expected has a standard deviation of 4.67 days, which is 9% of the total, against 18% for the single task. Individual tasks are wildly uncertain and long sequences of them average out. It is also why padding every single task with its own buffer overshoots so badly — the buffers are being added as if the worst case happened everywhere at once, which is exactly what the variance arithmetic says will not happen.
Reading the Probability Figure Honestly
A 66.6% chance of finishing within 14 days is not a promise and not a forecast of any particular project. It is what the model returns given three estimates a human produced, and the estimates dominate the output. Garbage optimism in, confident-sounding percentage out.
The practical use is comparative rather than absolute. Running the same calculation across several tasks tells you which ones carry the most schedule risk, and that ranking is far more robust than any individual percentage. If you want to see the underlying distribution mechanics, our normal distribution calculator and z-score calculator compute the same tail areas directly, and the standard deviation calculator works out spread from a real sample rather than from a three-point guess.
One more caution: a confidence-based commitment only works if the buffer survives contact with the organisation. Quoting 15.42 days for 85% confidence and then having that trimmed back to 13 in a planning meeting leaves you committed to a coin flip. The number is a negotiation input, not a decoration.
Where PERT Fits Beside Other Estimating Tools
PERT sizes a duration and its uncertainty. It does not tell you which tasks determine the finish date — that is critical path analysis, and the two are usually used together, with PERT supplying durations and the network supplying sequence. It also says nothing about cost or margin; once a duration is agreed, the project profitability calculator turns it into a fee and an hourly yield. For repetitive production work rather than one-off projects, the pace question is answered by a takt time calculator and the process rate by a cycle time calculator, both of which measure throughput rather than estimating an unknown.
Arb Digital scopes builds with ranged estimates and a stated confidence level, so the timeline you are given is one we expect to hit rather than a best case with the risk left out.
Web Design Services Talk to Arb DigitalCommon Mistakes to Avoid
- Using a catastrophe as the pessimistic estimate — a hurricane-scenario b value inflates the range and destroys the standard deviation's meaning.
- Treating the expected duration as a commitment date — it is roughly a coin flip by construction; commit to a confidence level instead.
- Summing standard deviations across a path — variances add, not standard deviations, so the correct path figure is the square root of the summed variances.
- Ignoring dependence between tasks — shared people, shared vendors and shared decisions correlate delays, and the model assumes they do not.
- Letting one person produce all three estimates in ten seconds — if a and b are just m ± 20%, the calculation adds arithmetic but no information.
Related Free Tools From Arb Digital
For the statistics behind the probability figure, use the normal distribution calculator, the z-score calculator or the confidence interval calculator. For spread measured from real data, the standard deviation calculator is the right starting point, and the probability calculator covers simpler event questions. On the delivery side, see the project profitability calculator and the percent to goal calculator, or browse the full free online tools hub.
Frequently Asked Questions
Expected duration equals (optimistic + 4 × most likely + pessimistic) divided by 6. The standard deviation is (pessimistic − optimistic) divided by 6, and variance is that value squared.
The weighting approximates the mean of a beta distribution bounded by the optimistic and pessimistic values. It keeps the answer close to the mode while still allowing an asymmetric tail to pull the average in the direction the range leans.
Each task is modelled as a beta distribution bounded by the optimistic and pessimistic estimates, and the total along a path is treated as approximately normal so that probabilities can be read off. Both are approximations, and the normal step is weakest for very short paths.
Because variances add and standard deviations do not. For four independent tasks the variance is four times a single task's, so the standard deviation is only twice as large. Uncertainty grows with the square root of the number of tasks.
Yes, and that is its most frequently violated assumption. Shared staff, shared suppliers and shared design decisions correlate delays, which makes real path variance larger than the model shows and the probability of hitting a date lower than it reports.
That is an organisational decision rather than a mathematical one. Many schedule practices quote a level in the 80–90% range for external commitments, but the point is to state which level you used so the buffer is explicit rather than hidden.
No. PERT estimates how long an individual task takes and how uncertain that is. Critical path method works out which sequence of tasks determines the project finish date. They are complementary, and most plans use both.
This tool applies the published PERT formulas to the estimates you enter. The output reflects those estimates and the model's assumptions, not a prediction of any real project's outcome.
