Three-point estimating: the PERT method

What three-point estimating is, and why a weighted average

Three-point estimating asks for three numbers instead of one: the best realistic case (Optimistic, O), the most probable case (Most Likely, M), and the worst realistic case (Pessimistic, P). PERT combines them with a weighted average rather than a simple one, because the underlying assumption is that outcomes cluster around the most-likely value more than around either extreme — the classic PERT formula approximates a beta distribution where M is far more probable than O or P individually. A simple average of the same three numbers, (O + M + P) ÷ 3, gives O and P equal influence with M, which overstates how likely the extremes actually are.

Why this matters for a services estimate

A single most-likely-only estimate hides risk by presenting a guess as if it were a certainty. A weighted three-point estimate does two useful things at once: it produces a number that is defensible when negotiating with a client who wants "your best guess," and it makes the uncertainty itself visible and reviewable, rather than buried inside one unlabeled figure that looks precise but isn't.

When to use PERT — and when it's the wrong tool

Use PERT when a task or role genuinely has independently reasoned optimistic and pessimistic bounds — not padding, but a real best case and a real worst case someone can articulate. It is the wrong tool in two common situations: when no real uncertainty exists, because the task is routine and well-precedented, in which case a historical parametric rate is faster and just as sound (see parametric estimating for services); and when a full work breakdown structure with well-understood, tightly bounded tasks already exists, in which case plain bottom-up point estimates are more appropriate than manufacturing an artificial range around numbers that are already known with confidence.

How to gather good O/M/P inputs

1. Ask the person who would actually do the work, not a manager estimating on their behalf.
2. Anchor the optimistic figure to "nothing goes wrong," not to an impossible best case that nobody believes.
3. Anchor the pessimistic figure to a realistic bad day — a dependency slips, a defect surfaces — not a worst-case catastrophe that would also derail every other task.
4. Sanity-check that P is greater than M and M is greater than O, and that the gap between them is proportionate to genuine uncertainty, not an arbitrary percentage padded on top of M.

Worked instance: a senior consultant's uncertain task

A senior consultant is estimating an integration-script task. Optimistic (O) = 30 hours, Most Likely (M) = 45 hours, Pessimistic (P) = 90 hours.

PERT hours = (30 + 4 × 45 + 90) ÷ 6 = (30 + 180 + 90) ÷ 6 = 300 ÷ 6 = 50 hours.

At the role's cost rate of $110/hour: 50 × $110 = $5,500.

Compare this to a naive simple average of the same three inputs: (30 + 45 + 90) ÷ 3 = 55 hours, costing 55 × $110 = $6,050. The naive average is higher because it gives the 90-hour worst case the same weight as the 45-hour most-likely case; PERT's weighting produces a lower, better-supported number precisely because it treats the most-likely figure as more probable, not because it is being optimistic.

The spread also matters: standard deviation = (90 − 30) ÷ 6 = 10 hours, meaning the 50-hour estimate carries roughly a ±10-hour band of normal variation — information a single point estimate would have discarded entirely.

Second instance: wide uncertainty vs tight uncertainty

Two tasks assigned to the same role can produce a similar expected value while carrying very different risk. Compare a well-understood task against a genuinely novel one.

Task A and Task B both center around 40-50 hours, but the implied spread tells a completely different story: Task A's estimate is trustworthy to within about an hour and a half, while Task B's carries a band of nearly 17 hours in either direction. A reviewer looking only at the expected-value column would treat these as similarly confident numbers; the spread is what reveals that Task B needs a contingency buffer, closer client communication about the range, or possibly a Delphi-style expert check (see project estimation methods guide) that Task A never required.

How this plays out on a real project

Consider an illustrative case: a consultancy is building a data-platform project with several tasks of very different character.

• A well-precedented ETL task: the team runs the full PERT ritual anyway, out of habit, spending time gathering three numbers for a task with almost no real uncertainty. Handling: skip PERT when uncertainty is genuinely low and use a historical parametric rate instead — running PERT everywhere is not more rigorous, just slower.
• A genuinely uncertain integration task: the engineer's "pessimistic" number turns out to be just the most-likely figure plus ten percent, collapsing the technique into a fake range. Handling: push back explicitly — ask "what would actually make this take twice as long" — until the pessimistic figure reflects a real scenario, not a rounding habit.
• Mid-project, the pessimistic scenario starts to materialize: a dependency delay hits the wide-uncertainty task from the table above. Handling: this is exactly where the earlier spread earns its keep — the team already flagged the risk and reserved contingency, rather than being surprised by an outcome the estimate had already priced in.
• Rollup reporting: someone presents the PERT number to leadership as if it were a certainty, dropping the spread entirely. Handling: always report the implied spread or range alongside the expected value, not just the single weighted number, so reviewers don't place more trust in the figure than the method ever claimed to support.

For a similar worked example built around a full pricing scenario rather than a single task, see the resource-loading pricing example, which uses roles, allocation, and cost rates the same way this article uses O/M/P inputs.

Sources and methodology

• Project Management Institute, Lexicon of Project Management Terms, Version 5.0. Used for the three-point estimating and PERT weighting definitions.
• Project Management Institute, PM101: Estimating. Used for the estimating-technique framing applied throughout.
• The worked consultant-hours figures and both task comparisons are original and illustrative, not a customer result.