The Contingency Line and How to Size It

Why this matters

Most shops carry contingency without knowing it. It lives as the half hour an estimator quietly adds because the last one of these was ugly, and it varies with mood, with how busy the shop is, and with who built the quote. It is never measured, so nobody can say whether it is too big, too small, or aimed at the right risk.

A sized contingency is a different thing entirely. It is a specific number, derived from your own measured spread on that job type, aimed at a stated probability of being wrong, and reconciled after the job against what it actually absorbed. It shrinks as your data improves. The mood version never shrinks, because it was never attached to anything that could improve.

Contingency covers spread. Correction covers bias. Never swap them.

This is the whole card in one line, and getting it backwards is the most expensive mistake in the topic.

Bias is the amount your estimate is systematically wrong by. If a job type's median actual is consistently above its estimate, the estimate is wrong and the fix is to change the estimate. Covering bias with contingency means you are carrying a permanent buffer to fund a permanent error, and the buffer gets consumed every single job, so it is never there for the job that actually needs it.

Spread is how much individual instances scatter around the median even when the median is right. That scatter is real and it does not go away with better estimating, because sites differ. Spread is what contingency is for.

The practical consequence: fix the bias first, then size the contingency on the corrected base. Bolt a contingency percentage onto a base that is already light and you will not reach the coverage you think you bought, and you will not find out until you look at the ledger.

Size it from your own distribution

You need at least 15 to 20 completed instances of the job type with usable actuals. Below that, you do not have a distribution, you have anecdotes, and any percentile you compute from them is noise. If you are below the gate, use the structured approach for unfamiliar work instead, which brackets from outside sources rather than pretending you have data.

With the instances in hand:

1. Sort the actual hours smallest to largest.
2. Find the median - the middle value. This is your honest base estimate for the type. If it differs from your current template, that gap is bias and it gets corrected in the template, not covered here.
3. Find the value at your chosen coverage percentile.
4. Contingency = percentile value minus median, expressed as a percentage of the median.

Use the median rather than the mean as the base. Estimate variance is always skewed - a job can run three times its estimate but it cannot take less than zero hours - so a single blowout drags the mean well above the middle of the distribution. Basing the estimate on a dragged mean means overbidding every ordinary instance to fund a rare one, which is what contingency is supposed to do instead, and doing it twice is how a shop prices itself out of its own market.

The percentile is a business decision, and it has a price

The percentile you pick is a direct statement about how often you are willing to be wrong.

The 80th is the right default for most residential service work and it is where to start. Each step up buys protection against fewer and fewer instances while raising the price on every bid you submit, so the cost of moving from the 80th to the 95th is paid on all of your work to protect against one job in twenty. On a job type you run weekly that is a bad trade. On a job type you run four times a year with a liquidated-damages clause it is cheap.

Attach contingency to named operations, not to the whole job

A flat percentage across the whole estimate charges the customer for uncertainty on the parts you are certain about. Access, cleanup, testing and paperwork are usually your tightest operations, and adding 12% to them is pure padding.

Size contingency on the operations that actually carry the spread. In practice that is a short list per job type: whatever is behind a wall, whatever is old, whatever depends on the customer being ready, and whatever needs a part you do not stock. Naming them has a second benefit - it tells the field where to look at the mid-job checkpoint, and it gives you something concrete to say if a customer asks what the line is for.

An estimator who cannot name what a contingency line is for has written padding, whatever it is labelled.

Keep a contingency ledger

Two numbers per job, on the job record: contingency added at bid, and contingency consumed, meaning actual hours above the base estimate, floored at zero.

Roll it up quarterly per job type and compute the consumption ratio: total consumed divided by total added.

• Between about 50% and 80%: healthy. You are covering most of the spread most of the time and not carrying much dead weight.
• Below 50%: over-contingent. You are losing bids to carry insurance you are not using. Drop a percentile band or re-size from a fresher window.
• Between 80% and 100%: the warning band, and the one shops skip past. You are still technically covered, but you are consuming nearly everything you add, which means the next small drift in the base estimate tips you into funding bias. Treat this as the signal to re-check the template, not as a pass.
• Above 100%: the contingency is funding bias, not spread. Stop adjusting the contingency and go fix the base estimate, because raising the contingency here just hides a broken template more expensively.

The ledger is what makes contingency a managed number rather than a habit. Without it, the number set two years ago on a job type that has since become routine is still riding on every quote.

A worked example, carried through

A shop pulls 20 completed instances of one job type, currently templated at 8.0 hours. Sorted actual hours:

7.2, 7.5, 7.6, 7.8, 7.9, 8.0, 8.1, 8.2, 8.3, 8.4, 8.5, 8.6, 8.8, 9.0, 9.2, 9.5, 9.8, 10.4, 11.2, 13.0

• Median (average of the 10th and 11th values, 8.4 and 8.5): 8.45 hours
• Mean (total 177.0 hours across 20 instances): 8.85 hours
• 80th percentile (16th value): 9.5 hours
• 90th percentile (18th value): 10.4 hours
• 95th percentile (19th value): 11.2 hours

Note the mean of 8.85 sits 0.4 hours above the median of 8.45, dragged by the single 13.0-hour instance. Using the mean as the base would build that one job into every future quote.

Step one is bias, not contingency. The template says 8.0 hours; the median says 8.45. That 0.45-hour gap, about 5% above the 8.0-hour template, is bias, and it gets corrected in the template. Contingency is sized on 8.45, not on 8.0.

Step two, size to the 80th percentile. 9.5 minus 8.45 is 1.05 hours, which against the 8.45-hour median is about 12%. So the job type carries a base of 8.45 hours plus 12% contingency, quoted at about 9.5 hours, and by construction roughly 1 instance in 5 will exceed it.

What the two higher bands would cost. The 90th percentile needs 10.4 minus 8.45, or 1.95 hours, about 23% of the 8.45-hour median - roughly double the contingency to cover 2 more instances in 20. The 95th needs 11.2 minus 8.45, or 2.75 hours, about 33% of the median, to cover 1 more instance beyond that. The return per point of price gets worse fast, which is the whole argument for starting at the 80th.

The mistake this example exists to prevent. Take the 12% contingency and bolt it onto the original 8.0-hour template without correcting the bias first: 8.0 times 1.12 is 8.96 hours. That is 0.54 hours short of the 9.5-hour 80th percentile it was supposed to reach. The shop believes it is covered to 1-in-5 and is actually covered to the 65th percentile: 13 of the 20 instances sit below 8.96, so roughly 7 instances in 20 blow through it rather than 4. Every job then quietly consumes the contingency to pay for the bias, the ledger shows a consumption ratio over 100%, and the natural but wrong response is to raise the contingency again.

Reading the ledger after a year. At 12% on an 8.45-hour base, contingency added per instance is about 1.05 hours, so across 20 instances the shop added about 21.0 hours. Consumed is the sum of hours above 8.45 on the instances that exceeded it: 0.05, 0.15, 0.35, 0.55, 0.75, 1.05, 1.35, 1.95, 2.75 and 4.55, totalling 13.5 hours.

Consumption ratio is 13.5 of 21.0, or 64% - inside the healthy 50% to 80% band. The sizing is right.

But look at where the consumption came from. The single 13.0-hour instance consumed 4.55 hours by itself, which is 34% of the 13.5 hours consumed, from 1 of 20 instances. That is a tail, and it should be investigated as an event with the people who were there rather than left sitting in the distribution. If it turns out to be a genuine one-off - a site condition that will not recur - recompute the percentiles without it and the contingency drops. If it turns out to be a sub-type of the job that will recur, it belongs in its own job type with its own base and its own contingency, and both types get more accurate.

Showing it, folding it, or holding it

Three legitimate ways to present contingency, and the choice is about the customer, not about hiding anything.

A separate line, named. Best for commercial and project work where the customer is sophisticated, and required on most cost-plus and public work. It invites scrutiny, and it should - you can defend a number derived from your own history. Say what it covers and what happens to it if unused.

Folded into the labor line. Standard for residential service and flat-rate work, where the customer is buying an outcome at a price and an itemized risk line reads as hedging. The contingency still exists in your ledger; it just is not a customer-facing line. This is not deception, and the test is whether you would give the same total if asked to justify it.

Held internally as a reserve. The quote goes out at the base and the contingency lives in your planning rather than the price. Only appropriate when you have a conditions clause that lets you bill discovered work, so the reserve is a schedule buffer rather than a money buffer.

What is not legitimate: a separate contingency line that is unused and then invoiced anyway. If you show it, you owe the customer either the work or the credit.

Re-size it on a schedule, or it becomes padding

Contingency is supposed to shrink. As instances accumulate, as the crew learns the job type, as intake questions get sharper, the spread narrows and the percentile gap closes.

Re-size quarterly from the most recent 20 instances of each tracked job type, and treat an unchanged contingency percentage across four consecutive quarters as a flag rather than as stability. Either the type genuinely has irreducible spread, which is worth knowing and worth saying out loud, or nobody has looked at it and the number has quietly become a habit again.

How to verify you got this right

Recompute your median from the raw rows rather than trusting a report, and check that the actual-hours field means the same thing on every row. Drive time counted on some jobs and not others will move a median by more than most contingency lines are worth.

Check the base and the percentile share one base and one unit. Contingency as a percentage of the median in hours, from the same job type, from the same window - a percentage quoted against the old template while the percentile came off the corrected median is the exact error the worked example above walks through, and it is easy to make twice.

Then check the consumption ratio against the win rate on the same job type. A consumption ratio in band with a falling win rate means you are correctly sized and losing on total price, which is a rate or overhead conversation, not a contingency one. A consumption ratio over 100% with a healthy win rate means you are buying work with a template that is still light.

References

• See related: Padding the Estimate: The Temptation for the line between contingency and padding.
• See related: Estimating the Unknown: The Conditions Clause for the contract mechanism that reduces how much contingency you need to carry.
• See related: How to Estimate a Job Type You Have Never Done for pricing risk below the 15-instance data gate.
• See related: How to Read Your Own Job Costing Data for percentile and sample-size reading.