Skip to content

Contingency

Last reviewed:
An amount included in an estimate or budget to cover costs that are expected to occur within the defined scope but cannot yet be itemised — the known-unknowns of the project.

Contingency exists because an estimate built only from what is currently drawn will be exceeded by a project that is still being designed. It covers estimating inaccuracy, design development within scope, normal quantity growth, and pricing variability. It explicitly does not cover scope changes, major risk events or escalation — those have their own provisions — and it is not a management reserve for the unknown-unknowns outside the defined scope.

Contingency is set either deterministically, as a percentage keyed to the estimate class — wide at order-of-magnitude, narrow at definitive — or probabilistically, by risk analysis that produces a distribution of outcomes and lets the organisation choose its confidence level.

Two failure patterns dominate. The first is double-counting: allowances buried in quantities, padding in rates, and a percentage on top, producing an estimate nobody can defend. The second is the opposite: contingency treated as fat and cut to make a number acceptable, which does not change the project's cost — only the date on which it is discovered. Well-run projects manage contingency drawdown explicitly, logging what consumed it, so that the remaining amount is a live measure of remaining risk.

See this workflow in practice.

Book a demo to see how Armeta applies this concept across the drawings, standards, specifications, and project data that define the work.