PERT Estimate Calculator

Why use three estimates?

A single number hides uncertainty: "15 days" sounds precise, but the real question is how much worse it could get. The Program Evaluation and Review Technique (PERT), developed for the US Navy's Polaris programme in the late 1950s, asks for three estimates and combines them into an expected value and a measure of spread.

The formulas

Expected time E = (O + 4M + P) ÷ 6
Standard deviation σ = (P − O) ÷ 6

The weights come from the beta distribution, which suits tasks that rarely finish far ahead of plan but can overrun badly. The most likely estimate counts four times as much as each extreme.

Worked example

A feature is estimated at 10 days (optimistic), 15 days (most likely) and 26 days (pessimistic).

• E = (10 + 4 × 15 + 26) ÷ 6 = 96 ÷ 6 = 16 days, one day more than the most likely estimate because the pessimistic case is far out.
• σ = (26 − 10) ÷ 6 = 2.67 days.
• About 95% confidence (one-sided): E + 1.645σ = 20.4 days.
• Roughly 95% range (±2σ): 10.7 to 21.3 days.

Adding up a project

For tasks done one after another, add their expected times. Standard deviations do not add directly; add their squares (variances) and take the square root. Three tasks with σ of 1, 1.17 and 0.33 days give a project σ of √(1² + 1.17² + 0.33²) = 1.57 days, smaller than the simple sum of 2.5 days, because overruns and underruns partly cancel out.

This only holds when tasks are independent. Shared risks, such as one key person being ill or an unclear requirement affecting several tasks, make the real spread wider.

Getting good estimates

• Ask the people who will do the work, and estimate each task separately before adding.
• Make the pessimistic estimate realistic, not catastrophic: "everything that usually goes wrong goes wrong".
• Break tasks larger than about two weeks into smaller ones; big tasks are where estimates fail.
• Compare with how long similar past tasks actually took.
• Remember non-development work: testing, review, deployment, meetings and support usually add 20–40%.

From estimate to delivery date

Expected working days are not calendar days. Convert with the add days to date calculator using working days, and subtract public holidays and planned leave. Communicate a range ("most likely 16 days, very likely within 21") rather than a single date.

Common mistakes

• Treating the most likely estimate as the plan. The expected value is usually higher.
• Adding standard deviations instead of variances for a chain of tasks.
• Estimating optimistically for everything, so the pessimistic value is barely above the most likely one.

Worked project example

A small release has three tasks done one after another:

The project's expected duration is the sum of the task expectations, 11.83 days. Its standard deviation is √(1.00² + 1.17² + 0.33²) = 1.57 days, so a 95% one-sided estimate is 11.83 + 1.645 × 1.57 ≈ 14.4 days. Planning on the sum of the "most likely" values (11 days) would have under-estimated even the average outcome.

PERT, story points and other methods

Agile teams often estimate in story points and use their measured velocity instead of days. PERT is still useful for one-off tasks, fixed-scope quotes and dependencies outside the team, where you need a date with a stated level of confidence. Monte Carlo simulation is the next step up: it runs thousands of random scenarios from the same three estimates and can model task dependencies that run in parallel.

Frequently asked questions

Sources

• Malcolm DG, Roseboom JH, Clark CE, Fazar W. Application of a technique for research and development program evaluation. Operations Research, 1959; 7(5): 646–669.
• Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK Guide): three-point estimating.

Last reviewed 5 October 2026. Results are estimates; see our disclaimer.