Estimating fundamentals

5 project estimation methods, and when to use each

Analogous, parametric, three-point, Delphi, and bottom-up estimating aren't interchangeable — each is the right tool for a different stage of the deal.

Short answer

Analogous estimating compares a new project to a similar past one — fast but least precise. Parametric applies a measurable historical rate, like cost per role-hour. Three-point (PERT) combines optimistic, most-likely, and pessimistic figures to manage uncertainty explicitly. Delphi uses structured expert consensus with no historical data. Bottom-up builds from a complete work breakdown structure — most accurate, slowest. Each belongs to a different deal stage, not personal preference.

Five estimation methods, defined

MethodWhat it usesSpeedPrecision
Analogous (top-down)One comparable past project, adjusted for scaleFastestLowest
ParametricA measurable historical rate or formula (e.g. cost per role-hour, cost per function point)FastModerate, if the rate data is reliable
Three-point / PERTOptimistic, most-likely, and pessimistic figures, weightedModerateModerate, with explicit uncertainty
Delphi / expert judgmentStructured, anonymous rounds of expert consensusSlowDepends on expert quality; used when nothing else applies
Bottom-upA complete work breakdown structure, estimated task by taskSlowestHighest

The U.S. Government Accountability Office's cost-estimating guidance frames three of these — analogy, parametric, and engineering build-up (bottom-up) — as complementary methods rather than competitors: analogy belongs early when detail is limited, parametric can be used throughout an estimate's life as long as the underlying database is large and consistent enough to support a valid cost-estimating relationship, and build-up estimating requires the detailed information a decomposed scope provides.

Mapping methods to the presales stage

StageRight methodWhy
Feasibility / ROMAnalogous or parametricLittle scope detail exists; speed matters more than precision. See what is a ROM estimate.
Firm fixed-price proposalBottom-upThe number will be contractually committed and needs a traceable basis.
One genuinely uncertain task inside an otherwise-scoped projectThree-point / PERTManages a specific risk explicitly instead of hiding it in a single-point guess.
Genuinely novel or unprecedented scopeDelphi / expert judgmentNo historical data or comparable project exists to anchor any other method.

When each method is the wrong tool

  • Bottom-up for a same-day ballpark wastes presales effort building a work breakdown structure for scope that will likely change before it is ever offered as a fee.
  • Analogous for a firm-fixed-price commitment under-protects margin — the method was never designed to bear contractual weight; see ROM vs definitive estimate.
  • PERT without three independently reasoned inputs is theater, not analysis — if the "pessimistic" figure is just the most-likely figure plus ten percent, the weighting adds false precision to a guess.
  • Delphi when reliable historical data already exists is slower than parametric estimating for no gain in accuracy — expert consensus is for genuine novelty, not a substitute for a rate you already have.

A short decision process

  1. Do you have at least one genuinely comparable past project? If yes and the scope is still undefined, use analogous estimating.
  2. Is there a reliable historical rate or formula that fits this type of work? If yes, use parametric estimating — but verify the rate data first (see parametric estimating for services).
  3. Is a specific task or component genuinely uncertain, with real optimistic and pessimistic bounds, inside a project that is otherwise scoped? Use three-point/PERT for that component (see three-point estimating: the PERT method).
  4. Is the work genuinely unprecedented, with no historical data and no reliable comparator? Use Delphi/expert judgment.
  5. Do you have, or can you build, a full work breakdown structure before the commitment is made? If the number needs to be contractual, use bottom-up regardless of how confident any shortcut method feels.

How this plays out on a real project

Consider an illustrative case: a 50-person IT-services firm is pricing a new AI-integration engagement, moving through its full deal lifecycle.

  • First client call: no work breakdown structure exists and the client wants a same-day ballpark. Handling: use analogous estimating from a roughly similar past integration project, presented as a range, not bottom-up guesswork under time pressure.
  • Qualification stage: the deal looks real enough to invest more effort, and the firm has enough role-hour history from similar engagements to support a sturdier number. Handling: switch to parametric estimating using the historical cost-per-role-hour rate for this type of integration work.
  • Proposal stage, one uncertain work package: a data-quality remediation task has genuinely wide uncertainty because nobody has assessed the client's source data yet. Handling: apply three-point/PERT to that one work package specifically, not the whole proposal.
  • Same proposal, one unprecedented component: the integration pattern the client wants has never been built by this firm before. Handling: convene three senior architects in a structured, anonymous Delphi round for that one component, rather than guessing or forcing a historical rate that doesn't apply.
  • Contract stage: a full work breakdown structure is now assembled from the qualified pieces above. Handling: build the definitive bottom-up total from it — the methods above fed inputs into this WBS, they did not replace the need for it.

The methods above are not mutually exclusive within a single project; they typically combine, each doing the job it is actually suited for at a given point in the deal.

Formula walk-through: the same task priced three ways

Take one work package — a data-migration task for 40 data sources — and price it three different ways to see why method choice changes the output.

Analogous: a comparable past migration task with roughly similar source count cost $18,000. Adjusted lightly upward for slightly more sources here: approximately $19,000, with a wide band attached since no task-level detail was used.

Parametric: historical data shows ETL development for this type of source averages 6 hours per data source at a fully loaded cost rate of $85/hour. Estimated hours = 40 × 6 = 240; cost = 240 × $85 = $20,400 (worked in full in parametric estimating for services).

Three-point / PERT: the lead engineer gives optimistic = 180 hours, most likely = 240 hours, pessimistic = 360 hours for the same task. PERT hours = (180 + 4×240 + 360) / 6 = (180 + 960 + 360) / 6 = 1,500 / 6 = 250 hours; cost = 250 × $85 = $21,250 (the formula is worked in detail in three-point estimating: the PERT method).

Three legitimate methods applied to the identical task produced $19,000, $20,400, and $21,250 — a difference large enough to matter on a proposal, and each number is defensible on its own terms. The point is not that one of these is "correct" and the others wrong; it is that the method chosen determines the answer, which is exactly why matching method to stage, rather than habit or convenience, is the actual skill here.

Sources and methodology