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.
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 real prior experience of 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.
From a percentile to a number in the budget
This is the step most explanations skip, and it is worth being concrete about it, because everything that follows depends on it.
You start with a base estimate: the cost of the work as scoped, carrying no allowance for things going wrong. The simulation tells you what the risks might add on top of that. You choose a percentile, and the contingency is the amount sitting at that point in the distribution. Base estimate plus contingency is the number you ask to have funded.
Infrastructure Australia puts it in a single sentence. A P50 cost estimate is the project cost with sufficient contingency to provide 50 per cent likelihood that this cost would not be exceeded, and P90 is the same sentence with ninety in it.
The Commonwealth's cost estimation guidance carries a worked example that shows the arithmetic. On a $100M base estimate it sets out a P50 contingency allowance of 15%, giving a risk-adjusted estimate of $115M, and a P90 allowance of 40%, giving $140M. Escalation is then applied on top of whichever figure you funded, to get to an outturn cost.
Two things fall out of that example that are worth sitting with.
The P50 allowance in that table is 15% of the base estimate, which is roughly what the ten teams at the top of this article would have told you off the top of their heads. The percentage heuristic is not arbitrary. On an ordinary project it lands somewhere near P50. What it cannot do is tell you where it landed, or move when the project is not ordinary.
The step from P50 to P90 is 15% to 40%. Nearly three times the contingency for exactly the same scope. That is not a technical refinement, it is a materially different ask, which is why the next question is the one that actually matters.
So which percentile?
A common reference point worth challenging is P80 as the default marker. For some projects that will be the right level. It is not the standard, though, and the guidance most often cited in support of it does not actually say that.
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 same paragraph goes on to say that large contingencies across a portfolio sequester money that could have funded other projects.
The UK Green Book treats a P90 as a way of expressing uncertainty around a central estimate rather than as a funding rule, and the example it works through is a reference-class exercise rather than a simulation: line up comparable projects by cost and take the ninetieth percentile of that list (paragraph 6.72). It separately requires an explicit adjustment for optimism bias (paragraph 2.25). Neither is a mandated percentile.
Closer to home, Australian public infrastructure does not work in P80 at all. It works in P50 and P90. Infrastructure Australia presents cost estimates at expected value, P50 and P90. 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, unless Cabinet has approved a different level.
Which means the line I have heard many times, that funding to P50 is a coin flip nobody would knowingly authorise, is not right either. Funding at P50 is frequently deliberate, and the P50 to P90 increment is held somewhere else rather than not held at all. Queensland Transport and Main Roads says it plainly: project managers are provided with a contingency reserve of up to P50 levels, with the difference between P90 and P50 contingency provisions being kept at portfolio levels. Infrastructure NSW does the same, giving the project director delegation to draw down against the P50 contingency and holding the P90 minus P50 delta at agency senior executive level. What is not defensible is funding at P50, calling it prudent, and holding nothing behind it.
Setting the risk appetite level is an organisational decision, not something an analyst should do in isolation.
ISO Guide 73 defines risk appetite as the amount and type of risk that an organization is willing to pursue or retain. ISO 31000:2018 puts the establishing of it with top management, whose responsibilities include setting the amount and type of risk that may or may not be taken to guide the development of risk criteria (clause 5.2). AACE reaches the same place from a different tradition: the selection of desired probability depends upon the risk attitude of management.
Computing a percentile is technical work, and it should be reproducible by anyone holding the same inputs. Choosing which one the organisation funds is governance. Conflating the two is how analysts end up quietly setting appetite for people who never delegated it to them.
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. PMI's Lexicon separates a contingency reserve, time or money allocated in the schedule or cost baseline for known risks with active response strategies, from a management reserve, time or money that management sets aside in addition to the schedule or cost baseline and releases for unforeseen work that is within the scope of the project. Contingency covers the risks you found. Management reserve covers the fact that your register is incomplete. Carry only the first and 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 together to get a portfolio P80. Percentiles do not sum.
The aggregation one is worth dwelling on
It would be normal to assume this works as a diversification benefit: the portfolio figure comes in below the sum, because five projects are unlikely to all have a bad day at once, so adding them up is the conservative move. That is true sometimes. It is not a rule, and it is very easy to carry it as one.
Take five independent projects, each carrying a handful of moderate risks plus one low-probability, high-impact item at 12% and $4M. Each project's own P80 lands at about $299k, comfortably below its own tail risk, because there is an 88% chance that item does not fire. Across five projects, though, there is only a 53% chance that none of them fires.
So add the five P80s and you get $1.5M. Simulate the portfolio properly and P80 is $4.8M. Adding up understates what you need by more than three times, and it understates in the direction that leaves you short.
Make the five projects move perfectly together instead, so that a bad day on one is a bad day on all of them, and the two figures land exactly equal. That is the single case in which adding percentiles up is correct, and it is not the case anyone is actually in.
You do not have to take the simulation's word for it either. AS/NZS IEC 31010:2020, the risk assessment techniques standard in the ISO 31000 family, says it outright in its clause on aggregating measures of risk (6.3.7.2):
If correlation is not taken into account appropriately the outcomes will be inaccurate and may be grossly misleading. Consolidating risks by simply adding them up is not a reliable basis for decision making and could lead to undesired results.
None of this needs expensive software. A Monte Carlo over a risk register is not a difficult model: a probability and an impact range per risk, a few thousand iterations, and a sort. I have built plenty of these in Excel over the years and they were perfectly defensible.
The reason to reach for a tool is time, not capability. If you want to test any of this against your own register, what the tail does to P90, what correlation does to the shape, what happens when you aggregate, Project Risk Quantification runs in the browser, is free, and will get you there faster than rebuilding the spreadsheet. One thing to know if you do: it reports the percentile as the contingency figure itself, sitting on top of your base estimate, rather than as a total with the base estimate already inside it.
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, do you simulate it at portfolio level, or add the percentiles up and assume it errs on the safe side?