Contingency Using Parametric Estimating

What parametric contingency estimating is

The insight behind it is simple and powerful: projects that share certain features tend to overrun by similar amounts. A vaguely-scoped, first-of-a-kind, highly complex project will, on average, need far more contingency than a well-defined repeat of a proven design — regardless of what specific risks anyone listed. Parametric estimating measures those features and reads the contingency straight off a model fitted to history.

What drives the model

Parametric models are built by analysing many finished projects and finding which characteristics best predict overrun. The recurring winners:

Contingency % = f ( level of definition, complexity, technology, … )

coefficients fitted to a historical project database via regression

The single strongest predictor is almost always the level of project definition — how complete the scope, engineering, and planning are when the estimate is made. This is the same idea as the estimate classes from Cost Estimating: a Class 5 screening estimate (little definition) carries huge uncertainty; a Class 1 (fully defined) carries little. Complexity, novelty of technology, and project size typically come next.

Parametric contingency calculator

A simplified illustrative model: contingency rises as definition falls and as complexity grows. Adjust the two main drivers and watch the predicted contingency on a $10M base estimate:

Using parametric estimating well

Use a parametric model that was built from projects genuinely like yours, and feed it honest measures of definition and complexity. It's especially valuable early, when the scope is too immature to list specific risks but you still need a credible contingency number. Treat the result as the systemic-risk baseline, and combine it with line-item methods (expected value, ranging) for project-specific risks — the two approaches catch different things.

Nine things to remember

1. Parametric estimating predicts contingency from project characteristics.
2. It uses a regression model built from a historical project database.
3. It captures systemic risk — the overrun built into how a project is set up.
4. It sees risk that line-item methods miss (the unknown unknowns).
5. Level of definition is the strongest predictor — the estimate-class idea again.
6. Complexity, novelty, and size are common additional drivers.
7. Default: 50% defined, complexity 3 → 30% ($3.0M on $10M).
8. A model is only valid for projects like its database — match the domain.
9. Best used early — and combined with line-item methods for discrete risks.