Parametric Estimating

Schedule technique · See it on the map

Runnable here

Estimating by multiplying a known amount of work by a rate drawn from past data.

When to use it

Use it when the work is genuinely unit-based and you have a trustworthy rate for that unit: lines of code per hour for a well-understood codebase, square feet of drywall per crew-day, records migrated per hour for a data conversion. It scales cleanly and is fast once the rate is established.

When to avoid it

Don't use it where the rate itself is shaky — one data point dressed up as a calibrated statistic — or where the work doesn't actually scale linearly with the unit you're counting (the last 10% of a migration is rarely the same per-record cost as the first 10%, because it's the exceptions and edge cases). A parametric estimate is only as good as the rate behind it.

Steps

1. Identify the quantifiable unit that drives the work's size (units of production, lines of code, drawings, test cases, square footage).
2. Establish a rate — duration or cost per unit — from historical data covering enough past instances to be a real average, not a single anecdote.
3. Count or estimate the quantity of units the current task involves.
4. Multiply quantity by rate, and separately flag any part of the task that won't scale linearly (setup time, one-time integration work) to be estimated on its own rather than folded into the rate.

What it produces

• A duration or cost estimate derived from quantity times a stated, sourced rate — reproducible by anyone who has the same rate and the same count.

Common pitfalls

• The rate is calibrated on a different context (a different team's throughput, a different codebase's complexity) and applied here without adjustment.
• Nonlinear cost — setup, integration, exception handling — gets folded into the per-unit rate anyway, which understates estimates for small tasks and overstates them for large ones.
• The rate is never revisited once established, so it silently drifts out of date as tooling, team composition or the nature of the work changes.

Worked example

A data-migration task involves porting 40,000 customer records. The team's historical rate for this record type, averaged across three prior migrations, is 1,150 records per hour. They estimate roughly 35 hours for the transfer itself, and separately estimate eight hours of one-time schema-mapping setup that the rate doesn't cover.

Source

• PMBOK-6 §6.4.2.3

Where it comes from: this technique is named by the PMBOK Guide, 6th edition.