Analogous Estimating vs Parametric Estimating

What is analogous estimating?

analogous vs parametric estimating is a key topic in modern project management and teamwork. Analogous estimating compares the new project with one or more completed projects that resemble it, then adjusts the historical cost or duration for the differences you can name. If the last customer portal took 1,200 hours and this one has two extra integrations, you scale up and state why.

The method’s strength is that it is grounded in something that actually happened. Its weakness is that “something” is often a single data point plus a series of judgment-based adjustments. NASA’s cost estimating handbook lists exactly this trade-off: analogy is based on actual historical data, but in some cases relies on a single historical data point and depends on extrapolation or expert judgment for the adjustment factors.

Analogous estimating works best when the reference project is genuinely similar in size, technology, team, and constraints, and when someone who worked on it can explain what went wrong. It works badly when the reference is a decade old, used a different stack, or is remembered as “it went fine” by someone who has since left.

What is parametric estimating?

Parametric estimating calculates cost from a rate or a cost-estimating relationship (CER) applied to a measurable driver: square metres, lines of code, transactions per second, screens, API endpoints, pallets shipped, or hours per audit.

At its simplest it is one multiplication. At its most rigorous it is a regression across a database of completed work, with a coefficient of determination (R²) telling you how much of the cost variation the driver explains. The US Government Accountability Office and NASA both treat regression-based CERs as the backbone of parametric estimating, and both stress the same precondition: the driver must be measured consistently across the historical projects, or the relationship is noise dressed as mathematics.

Three properties separate a real parametric estimate from a rate someone made up:

1. The driver is countable before the work starts. You can count screens from a wireframe; you cannot count “complexity”.
2. The rate comes from your own history, normalized for inflation, scope, and productivity. A rate from another company in another decade is a hypothesis.
3. The new project sits inside the range of the historical data. A CER built on projects between 5 and 40 releases does not automatically apply to 400.

The best-known public example is COCOMO II, the software cost model calibrated on 161 projects. Its effort equation is PM = A × Size^E × Π(EM), with A = 2.94 and E typically just above 1. A 100 KSLOC system of average difficulty (E = 1.15, all multipliers at 1.0) comes out at 2.94 × 100^1.15 = 586.6 person-months. The exponent above 1 encodes a real finding: larger systems cost disproportionately more per unit of size, because communication and integration overhead grow with headcount.

How do the two methods compare?

They differ in evidence, speed, and failure mode more than in accuracy. The table below is the practical version.

A useful way to hold the difference: analogous estimating asks “what did something like this cost?”, while parametric estimating asks “what does this kind of thing cost per unit, and how many units are there?” The first is a comparison. The second is a model.

Which one is more accurate?

Neither, in the abstract. Accuracy comes from how much of the project is defined and how good the data is, not from the label on the method. The familiar ±20% and ±50% figures come from estimate classification systems such as AACE International’s 18R-97, which maps classes to project definition and to typical methods. For process-industry projects:

Two things follow from that table. First, an analogous estimate is not inherently worse than a parametric one; both appear in Class 5, where the project is barely defined. Second, a wide range at concept stage is correct, not sloppy.

Software has its own version of the same idea: the cone of uncertainty. Barry Boehm’s 1981 data, popularized by Steve McConnell, puts an initial-concept estimate at 0.25× to 4× the eventual actual — a 16-fold spread — narrowing to roughly 0.5×–2× at approved product definition. Moving from analogous to parametric does not move you down the cone. Only defining more of the project does.

There is one genuine accuracy argument in favour of parametrics: because a CER is built from more than one data point, it is generally less risky than estimating by analogy. That advantage disappears the moment the CER is applied outside its data range.

How do you build an analogous estimate that survives scrutiny?

Start from a real project, then make every adjustment explicit and signed. An adjustment nobody can inspect is a preference.

Worked example: the customer portal

Last year’s portal took 1,200 hours and cost $96,000 at a blended rate of $80/hour. The new one has two extra integrations, roughly 15% more scope, and reuses an existing design system, which should cut about 8% of the effort.

1,200 × 1.15 × 0.92 = 1,269.6 hours, call it 1,270 hours.

At $80/hour that is $101,568. But the honest output is not the point estimate; it is a range. At Class 5, using the AACE process-industry band, that becomes roughly $71,000 to $203,000. For a software project, the more useful framing is to apply the cone: 0.5× to 2× at product-definition stage gives $51,000 to $203,000. Either way, the useful sentence is “between $70k and $200k until the integrations are specified”, not “$101,568”.

Two disciplines make this defensible. Write down each adjustment with a one-line reason, and record the reference project’s actual outcome, not its original estimate. Comparing a new project to a reference project’s *estimate* compounds two optimism biases at once.

How do you build a parametric estimate?

Pick a driver, prove the rate, then check the boundary conditions.

Worked example: hours per screen

A product team has shipped 22 screens across three releases. After normalizing for the two screens that were pure configuration, the median effort is 38 hours per screen, with a range of 22 to 70. The new release has 14 screens, four of which are variants of existing ones.

14 × 38 = 532 hours. The variants should be cheaper; at 20 hours each, the estimate becomes (10 × 38) + (4 × 20) = 460 hours.

532 hours rests on a median from 22 data points, and the median hides a 3× spread between the cheapest and most expensive screen. A defensible statement is “460–600 hours, most likely 520”, with the range taken from the observed distribution rather than a gut feeling.

Worked example: scaling with the exponent

Parametric models are not always linear, and that is a feature. Doubling size from 100 to 200 KSLOC at E = 1.15 multiplies effort by 2^1.15 = 2.22, so 586.6 person-months becomes about 1,302. A team that assumes linear scaling under-funds every large project it plans.

When should you use each?

Use analogous when detail is thin, speed matters, and a genuinely comparable project exists. Use parametric when you can count a driver and have at least a handful of consistent historical data points.

Decision rules that hold up:

• Concept or screening: analogous, presented as a range.
• Feasibility or budget authorization: parametric if the data supports it, with the rate and its source named.
• Detailed planning: bottom-up, verified against the parametric number.
• Repeated work: parametric, because repetition is what creates a valid rate. Ten similar onboarding builds produce a rate; one does not.
• Novel work: analogous with wide bands, or a spike to generate the missing data before estimating at all.

If the technology has changed fundamentally, neither method is trustworthy. NASA’s guidance is blunt that parametric models assume the historical framework still applies; when it does not, the model is extrapolating into a regime it has never seen.

How do you combine them without creating false confidence?

Use them as three independent reads on the same question, then reconcile the gaps explicitly.

A workable sequence:

1. Analogous for the shape. “This is about 1.3 times the portal we built last year.” That gives an order of magnitude and a sanity check.
2. Parametric for the arithmetic. “14 screens at 38 hours, 4 at 20 hours” gives a number that can be audited line by line.
3. Bottom-up to verify. Estimate the five largest work packages from first principles. If the bottom-up total lands outside the parametric range, one of the two is wrong, and finding out which is the most valuable hour you will spend.
4. Three-point for the range. Take optimistic, most likely, and pessimistic values and use PERT: (O + 4M + P) ÷ 6. For a package at 120 / 180 / 320 hours, that is (120 + 720 + 320) ÷ 6 = 193 hours, with the spread telling you where the risk sits.

When the reads disagree, do not average them. Averaging hides the disagreement that a sponsor needs to see. Present the range, name the driver of the gap, and say what would resolve it.

What mistakes ruin both methods?

• Comparing to a project’s estimate instead of its actual. The reference should be what the work really cost.
• Skipping normalization. Inflation, currency, productivity changes, and scope differences all distort a raw comparison.
• Treating one data point as a rate. “It took 300 hours last time” is an anecdote, not a CER.
• Extrapolating outside the data range. A model built on small projects will mislead on a large one, however good its R².
• Confusing precision with accuracy. Two decimal places on a ±50% estimate is theatre.
• Never updating the model. Rates drift. A parametric model that is not recalibrated annually is an analogous estimate with extra steps.

Where does Doitify fit?

Both methods depend on the same asset: a record of what work actually took. Most teams do not have one, so they estimate from memory, and memory is an optimistic archivist.

Doitify keeps that record next to the work: tasks and sub-tasks with owners, estimates, and dates, timesheets and work reports, and project roll-ups showing planned versus actual. Over a few cycles it becomes the rate table that makes parametric estimating possible, and the honest reference project that makes analogous estimating more than a guess.

A transparency note: Doitify is our product. A disciplined spreadsheet can do the same job if someone maintains it. Keeping the record next to the tasks just means it gets captured without a separate reporting ritual.

Conclusion

The choice between analogous and parametric estimating is really a question about evidence. Do you have a comparable case, or do you have a rate? Neither answer is better; both are more honest than a number produced because someone senior wanted one.

Three habits make either method work. Anchor on actuals, never on old estimates. State the range and the estimate class, so nobody mistakes a concept number for a commitment. Write down the adjustments, because the audit trail is what turns a plausible figure into a defensible one.

Then reconcile. The gap between the two methods is not a nuisance to be averaged away — it is the most useful piece of information in the exercise.

If this post on analogous vs parametric estimating was helpful, you might also enjoy How to Reduce Context Switching at Work (2026 Guide) and Project Management Software for Design Teams.