How much contingency should a project carry?

Most teams answer with a percentage. A percentile is a better answer, but only if you are honest about what it does not cover.

Daniel Atkin6 min read

Ask ten project teams how they set contingency and most will tell you a percentage. Ten percent. Fifteen for something unfamiliar. Five if the sponsor is watching costs closely. I have used those numbers myself and they were usually about right, which is exactly what makes them hard to argue with.

The problem shows up later. When the project overruns by 22%, nobody can point to which assumption failed, because no assumptions were written down. The number was defensible in the room and unexaminable afterwards.

What the percentage is actually telling you

It is not nothing. A practitioner who has delivered thirty projects in one sector has a real prior about how badly they tend to run. What the percentage carries is information about the reference class, not about this register. That distinction matters, because two projects with identical budgets and very different risk profiles get identical contingency, and the number scales with the size of the estimate rather than with the shape of the exposure.

What a percentile says instead

Run a Monte Carlo simulation across a register and you get a distribution of possible outcomes: thousands of versions of the same project. A percentile is a position in that distribution.

P80 means 80% of the simulated outcomes came in at or below this figure.

That is the whole definition, and the looser paraphrases are wrong in ways that matter. P80 is not 80% confident. It is not an 80% chance of coming in under budget. It cannot be, because the distribution is of the risks you modelled, not of the project. It excludes scope change, escalation outside your ranges, and estimating error you did not capture. It is a statement about the simulation, and it inherits every assumption the register was built on.

The useful part is not the number. It is that you can take the number apart in front of someone. The judgement has not gone away, it has moved upstream into the ranges, the probabilities and the scope of the register, where it is visible and can be argued with.

So which percentile?

This is where I had a view that did not survive checking. I had it in my head that P80 was the standard, and that most major-project guidance said so. When I actually went and read the guidance, that is not what it says.

AACE International's Recommended Practice 41R-08 mentions 80% once, and not as advice:

The more conservative, risk-averse attitude used by many profit-making companies, is to specify a probability of 80% or higher that the project will not overrun. This is a safer route but by specifying a high probability, the required contingency will increase and with it the project cost.

It describes the practice, then warns about it. The UK Green Book works in P90 values and optimism-bias uplift rather than a mandated percentile. And closer to home, Australian public infrastructure does not use P80 at all. It works in P50 and P90. Infrastructure Australia presents cost estimates at P50, P90 and expected value. The Infrastructure NSW Cost Control Framework is blunter: agencies must provision contingency at P90 for Tier 1 high-profile high-risk projects and P50 for Tier 2. Queensland Transport and Main Roads requires P90 status for its programme.

Which means the line I have heard many times, that funding to P50 is a coin flip nobody intends to authorise, is not right either. Funding at P50 is often deliberate. The P50-to-P90 increment is held centrally as a reserve, on the reasoning that the portfolio does not need every project funded to its own high percentile. What is not defensible is funding P50 and calling it prudent with nothing held behind it.

Choosing the level is a risk criteria decision, and it is not the analyst's to make. ISO 31000:2018 handles this explicitly. Clause 6.3.4 is titled Defining risk criteria, and the standard puts the source of those criteria with top management, whose job includes establishing the amount and type of risk that may or may not be taken to guide the development of risk criteria. Computing a percentile is technical work and should be reproducible by anyone with the same inputs. Deciding which percentile the organisation funds is governance. Conflating the two is how analysts end up quietly setting risk appetite for people who never delegated it.

What the number still does not cover

Three things, and the third is the one I see go wrong most often.

  • Risks nobody identified. The simulation quantifies the register it was given and says nothing about what is missing from it. That gap has a name and an instrument: management reserve, which PMI defines as money set aside in addition to the cost baseline for unforeseen work within scope. Contingency covers known risks. Management reserve covers the fact that your register is incomplete. If you only carry the first, you have funded the part you could see.

  • Correlation you assumed away. If two risks share a driver, one supplier or one weather window or one scarce skill set, and the model treats them as independent, the tail is understated. Note that it is the tail specifically. The mean is unaffected by dependence and the median can move either way. Independence is an assumption, not a neutral default.

  • Aggregation across projects. You cannot add the P80s of five projects to get a portfolio P80. Percentiles do not sum.

The aggregation one is worth dwelling on

I used to explain this as a diversification benefit: the portfolio figure comes in below the sum, because the projects are unlikely to all have a bad day at once, so adding them up is conservative. That is true sometimes. It is not a rule, and I had it as a rule.

Take five independent projects, each with a handful of moderate risks plus one low-probability, high-impact item at 12% and $4M. Each project's own P80 sits below its tail risk, because there is an 88% chance it does not fire. But across five projects there is only a 53% chance that none of them fires. So the portfolio P80 sits above one of those tails while none of the individual P80s do.

Simulated, that portfolio comes out around $5.4M at P80 against a sum-of-P80s of $2.2M. Adding them up understates it by more than half, and it understates in the direction that leaves you short. Push the projects to perfect correlation instead and the two figures land exactly equal, because quantiles do add under comonotonicity.


None of this needs expensive software. If you want to see the shape of it on a real register, with distributions per risk, correlation between them and the percentile outputs, Project Risk Quantification runs in the browser and is free. Note that it reports the percentile as the contingency figure itself, sitting on top of your base estimate, rather than as a total to subtract from.

The method matters more than the tool though. The number you hand a sponsor should be one you can take apart in front of them, and you should be able to say what it does not cover without being asked.

I would be interested in how others are handling the portfolio question in particular. If you aggregate across a programme, I would like to know whether you simulate it properly or whether, like me for a long time, you have been adding percentiles and assuming it errs on the safe side.

cost riskmonte carlocontingency
ShareLinkedInFeed