What is project contingency? No, not the Halo Fan Game (Google that). No, we’re talking about a key staple of the project management planning process.

Essentially if you’re the lead manager on a project you’ll have likely costed the work in terms of both money and time to create an estimate or forecast. Project contingency is simply the process by which you account for uncertainty in that estimation by factoring in any risk. This is then added to the original estimate to ensure the company is prepped for a worst-case scenario that could otherwise derail a project.


A good project plan should therefore have contingency built-in, but building an accurate forecast should be more science than art and calculating contingency is no different.

Part of a good project plan is to scope the critical success factors and it’s unlikely that this will be in a single area, it’ll be an amalgamation of the moving parts of your typical delivery cycle. Part of that are deadlines and budget - essentially things that can be missed if planned poorly or the client moves the goalposts. Project contingency should evaluate these parts of the plan and ask the estimator: how could this go wrong and what will it cost the business if it does?


Taking the above into account, view a Project Contingency Plan as ‘Plan B’, pre-planning what resource(s) it will take to move back towards achieving the critical success factors should a risk become a reality. It goes even further in that you’ll also know the likelihood of it happening in the first place. Please note that it only works for identified risks so there is so pre-work in understanding the classic risks to your delivery. Also don’t confuse with mitigation; the hope is these risks don’t occur and mitigation aids there - contingency is the sandbag in the plan should the risk actually happen, so you're not meeting unprepared costs.


Well, how long is a piece of string? Given the varying project management methods, demands and planning, plus the variety of industries and services being delivered it kinda depends on you. But here are some methods you can adopt:

  1. Percentage of Project Base | In this simple method you take a fixed percentage of the project estimate to calculate contingency, normally based on some predetermined factors or historical data, i.e. you can be relatively sure that X% is right most of the time as you’ve never exceeded this amount in the past. This can further be influenced by:

  2. Expert Judgement: This is where the predetermined factors have been backed by experts with experience of such risk management in the given field.

  3. Guidelines: This is where the classic features of your potentially varying delivery methods (still contained within the parameters of your typical delivery) are classed and the contingency percentage is based on a single class or an amalgamation of classes i.e. class 3 delivery always has a 20% contingency.

  4. Expected Value | This method uses statistics to quantify the impact of pre-identified risks to calculate contingency, whereby the probability of the risk is multiplied by the impact (cost) if it does in fact occur. This means you can add up the number of risks and discover the overall bottom line.

  5. Range Estimating | This is a little more complex in that the impact of the risks identified are given a cost range, rather than a simple stagnant figure. This means you can see a minimum impact and a maximum impact, akin to a worst case and/or best case scenario. It means correlations in various cost elements can be incorporated, and then the probability of each outcome measured with statistical analysis - i.e. there is a 12% chance of hitting the lower threshold of contingency so you’ll need the amount to be increased. It provides a confidence level in the project contingency figure.

1a. and 1b. are deterministic methods that are often described as simplistic as often no formal and detailed risk assessment has actually taken place and therefore specific projects with niche requirements may be underserved by these techniques. Smaller projects, or those that are repeatable in nature often use this form.

2. and 3. are probability methods and aid if multiple risks to the project have been identified - more likely to be adopted on large scale projects. Both techniques use probability of outcome so are more accurate forms of project contingency estimation, but they require simulation programs (or someone very good at maths) to figure out. Range estimating is also a strength as it provides a baseline where the probability of over and under estimating the contingency are in fact equal, making it more risk neutral - when the project is undertaken any risk should balance out.


Where does Precursive fit in? Well, above I mentioned some pre-planning in order to know what risks you typically encounter. Contingency needs to be estimated for when there is need for a requirement or resource change so when viewing project management through the triangle of scope-cost-time, each of these areas may become impacted. The project sponsor or steering committee will also need to know the agreed upon contingency plan.

Precursive aids in both forward-looking and retrospective views of project management data, and in that retrospective view you can highlight the trends of not only what factors made your former projects successful (and profitable) but also highlight why the activations where deadlines were missed went off-course. Be it capacity crunches, poor collaboration, not knowing what resource it would take to deliver, Precursive can inform what contingency levels should look like by highlighting who will be involved, what do they need to do and when to execute - should risk become reality. It will provide the agility to react to risk and ensure the impact is minimised. This means the guidelines for Project Contingency Estimation can be created from data, not from guesswork.

Click here to view product videos or