Project Time Estimator (PERT)
Three-point PERT estimation: optimistic, most-likely, pessimistic → expected time + standard deviation. Multi-task project totals. Free, no signup.
Project Time Estimator (PERT)
Three-point estimation: for each task, enter optimistic (O), most-likely (M), and pessimistic (P) durations. The tool returns expected duration per the PERT formula (O + 4M + P) ÷ 6, plus project-level standard deviation and 68/95/99% confidence intervals. Works in days, weeks, or hours — pick one unit.
| Task | Optimistic (O) | Most likely (M) | Pessimistic (P) | Expected |
|---|
How to Use the PERT Estimator
Pick a unit and stick with it
Hours, days, weeks — pick one and use it across all rows. The tool doesn't care which unit; it just sums and shows results in the same unit.
For each task, fill three numbers
O = best case if everything goes perfectly (rare). M = the value you'd quote to a colleague who asked. P = realistic worst case (not a panic worst case). Most people set P ≈ 2× to 3× O.
Read the expected value column
Each row's "Expected" column is (O + 4M + P) ÷ 6 — the weighted average that gives most weight to the most-likely estimate but lets the tails matter.
Use the CI bands for commitments
Quote the 95% CI high (or 99% safe) to stakeholders, not the expected value. The expected is a 50/50 bet to finish on time. The 95% high gives you breathing room on the long tail.
PERT — Why Three Numbers Beat One
Where PERT Came From
PERT — Program Evaluation and Review Technique — was developed by the US Navy's Special Projects Office in 1958 for the Polaris submarine missile program, where 9,000 contractors had to coordinate a multi-billion-dollar effort with severe technical uncertainty. The single-number estimate (just "M") was failing badly: contractors were anchoring on best-case numbers, optimism compounded across the network, and the program kept missing deadlines. The PERT statisticians realised the missing ingredient was an explicit measure of uncertainty per task — so they asked for three numbers (O, M, P) and used the beta distribution's mean: (O + 4M + P) ÷ 6.
The trick is the 4× weight on M. The beta distribution is right-skewed (tasks more often run long than short), and weighting M heavily anchors the expected near the most-likely while letting O and P pull the result if they're extreme. The standard deviation, (P − O) ÷ 6, falls out of the same beta-distribution assumption: PERT assumes the 6-sigma range of a task spans from O to P, so SD = range ÷ 6. This is approximate (true beta SDs depend on the distribution shape), but the approximation is good enough for project planning and survives in PMI's PMBOK to today.
Why Project SD Is Lower Than the Sum of Task SDs
A counterintuitive PERT result: project SD is not the sum of task SDs — it's the square root of the sum of task variances. So a 4-task project where every task has SD = 1 day has project SD = √4 = 2 days, not 4 days. The intuition: some tasks run long, some run short, and they partially cancel out at the project level. This is why adding more sub-tasks to a long project actually tightens the relative uncertainty (CV = SD ÷ expected falls as task count rises) — assuming task durations are independent.
When tasks are NOT independent (e.g. one team handles three tasks, so all three are correlated by team capacity), the project SD grows faster than √n. Real-world PMs adjust by inflating P estimates for correlated tasks or by adding explicit "team-bandwidth" buffer rows. Critical-chain method (Goldratt's TOC adaptation) handles this more rigorously by buffering at the project level, not per-task.
"Quote expected to peers, quote P95 to stakeholders. The expected is the value you'd hit on a coin-flip — half the time you finish early, half the time you finish late. The P95 is the value you'd bet your job on."
PERT vs Agile Story-Point Estimation
Agile teams typically estimate in unitless story points (Fibonacci: 1, 2, 3, 5, 8, 13) using planning poker rather than three-point PERT. The two approaches are not mutually exclusive — Fibonacci forces a coarse, relative-size estimate that's resilient to small errors; PERT gives a calibrated absolute estimate with a known confidence interval. Many teams use Fibonacci within a sprint and PERT-style estimates for quarter-level commitments to stakeholders. The Fibonacci-vs-PERT debate is mostly about audience: engineers debugging together want Fibonacci's relative-size frame; executives chasing a launch date want PERT's calibrated days-from-now answer.
Where PERT Breaks Down
PERT assumes task durations are independent, that O / M / P are honest assessments, and that the beta distribution is a reasonable model. Three failure modes in practice: (1) estimators game the numbers — quoting wide P values to protect themselves rather than to communicate real uncertainty; (2) tasks are correlated through shared people or shared infrastructure, so a bad week on one drags down others; (3) very long tasks have fat-tailed distributions that the beta approximation underweights. The mitigations: blind-quote estimates separately and reconcile, decompose long tasks into 1-2 week chunks, and add an explicit unallocated risk reserve at the project level rather than burying buffer inside each task estimate.
10 Facts About Project Time Estimation
PERT was created in 1958 by the US Navy for the Polaris missile program — coordinating 9,000+ contractors.
Expected = (O + 4M + P) ÷ 6. The 4× weight on M reflects the beta-distribution mean.
Task SD = (P − O) ÷ 6 under the PERT 6-sigma-range assumption.
Project SD = sqrt(sum of variances), NOT sum of SDs. Independence assumption.
68/95/99 rule: ~68% within 1 SD, ~95% within 2 SD, ~99% within 3 SD of expected.
Planning fallacy (Kahneman): people consistently estimate too short. Use P95 for external commitments.
Hofstadter's Law: "It always takes longer than you expect, even when you take Hofstadter's Law into account."
Critical path method (CPM) is PERT's deterministic cousin — single-point estimates only. Often paired with PERT for risk.
PMI PMBOK 7th ed. still recommends three-point estimation for tasks with meaningful uncertainty.
Story points (Agile) and PERT solve different problems — relative sizing for sprints vs absolute commits for stakeholders.
Frequently Asked Questions
- PERT (Program Evaluation and Review Technique) is a three-point estimation method developed by the US Navy in 1958. You provide optimistic (O), most-likely (M), and pessimistic (P) durations per task. The formula (O + 4M + P) ÷ 6 returns the expected duration. The three numbers force you to think explicitly about uncertainty — one of the most underdone parts of project planning.
- O = the duration if everything you can't control goes your way — fast vendor responses, no blockers, no scope creep. NOT a fantasy number. P = realistic worst case where some predictable things go wrong (one sick day, one tool issue, one dependency slip) but not catastrophic. P is typically 2-3× O for routine tasks, 4-5× O for tasks with significant unknowns.
- Project SD = sqrt(sum of variances), not sum of SDs. For 4 tasks each with SD = 1 day, project SD is √4 = 2 days, not 4. The intuition: some tasks finish early, some finish late, and they partially cancel out. This only holds when task durations are independent. If one team handles multiple tasks, durations are correlated and project SD grows faster — adjust by inflating P estimates on correlated tasks.
- Quote the 95% CI high (expected + 1.96 SD) for external commitments. The expected value is a 50/50 bet — half the time you'll miss. The 95% number gives you breathing room on the long tail. For board-level launch dates or fixed-price contracts, use 99% (expected + 2.58 SD). For internal estimates among technical peers, the expected value is fine.
- They solve different problems. Story points (Fibonacci: 1, 2, 3, 5, 8, 13) are unitless relative sizing — fast to estimate, resilient to small errors, designed for sprint capacity planning. PERT gives absolute time with explicit uncertainty — designed for cross-functional commits to stakeholders. Many teams use Fibonacci for sprint work and PERT-style estimates for quarter or release-level commitments. They're complementary, not competing.
- Don't double-buffer. If P estimates already include realistic worst-case effects, the resulting CI bands give you the buffer naturally. Critical Chain Project Management (Goldratt) moves the buffer to the project level rather than embedding it in each task — same total time, different framing. Don't add a 20% padding on top of P95 numbers; that's the planning fallacy in reverse.
- Pick one based on the smallest task granularity in your project. Sub-day tasks → hours. Multi-week tasks → days or weeks. Stay consistent within a single estimate. Mixing units (some rows in hours, some in days) breaks the SD math. If your project spans truly different granularities (some 4-hour tasks and some 6-week tasks), convert everything to the smaller unit before entering values.
- This tool sums sequential durations — it assumes tasks run back-to-back. For parallel work or complex dependency networks, you need a critical-path tool (Microsoft Project, Gantt charts in Jira / Asana, free OpenProject). The PERT formula still applies per task; the project total is the critical-path sum, not the total of all tasks. For ~85% of small projects (5-15 tasks, mostly sequential), this tool is sufficient.
- Yes for traditional / waterfall projects with clear scope and stakeholder commits. PMI's PMBOK 7th edition (2021) still includes three-point estimation as a core technique. For pure Agile teams that don't commit on dates ("we deliver every two weeks, scope flexes"), PERT is less central. Hybrid teams (Agile delivery, waterfall commitment) often need both. The PERT math is timeless; the question is whether your project shape calls for it.
- US clients (especially in tech) tend to expect aggressive expected-value estimates and treat slippage as a process failure. EU clients (Germany, Netherlands) are typically more comfortable with explicit P95 commitments and view P95 quotes as professional honesty. ASEAN clients vary — Singapore + Hong Kong skew US-style; Indonesia + Philippines more relationship-driven and tolerant of slippage if you communicate early. When estimating for US clients, quote P75 to peers and P95 to stakeholders; for EU, quote P95 to both; for relationship-driven ASEAN clients, quote expected with explicit risk callouts.
Related News
You may be interested in these recent stories from our newsroom.
-
Snowflake jumps 36 per cent in a day on an earnings beat and a US$6 billion AWS chip deal
Snowflake had its best day as a public company on 28 May, closing up 36 per cent after a clean first-quarter beat and a five-year, US$6 bill...
-
MAS Scraps Mandatory Financial Advice for Most Complex Product Buyers in Retail Shake-Up
Singapore retail investors buying structured notes, derivatives and investment-linked policies will no longer need mandatory financial advic...
-
SEC Rewrites Float Rules, PSE Moves to Implement Them — Clearing the Path for GCash's USD 1B Philippine IPO
The SEC lowered the public float floor for large Philippine issuers in February 2026. The PSE followed with a consultation paper in April. T...
75 more free tools
Calculators, converters, security tools — no signup.