Step 10: Add Contingency

A schedule with no contingency allowance has a greater risk of running late. Contingency must always be included — for inherent risks and for unplanned events (contingent risks) that might cause delays.

Factors to Consider

Project complexity and location, industry experience, historical information, and common sense all influence how much contingency is needed.
Heavy civil projects will be subject to wet weather delays; building fit-outs may not be — consider what contingency types are genuinely relevant.
Are productivity rates and contingency based on historical data? Consider the era of historical data — the recent pandemic has resulted in distinct 'before' and 'after' production rates and supply chain conditions.
The base case schedule needs careful consideration — how aggressive is it, and can it be reasonably achieved? The contingency period must reflect the base case.

The Basis of Schedule should clearly outline the schedule strategy, whether conservative or aggressive.

High-Level Contingency Allowances

External Works

10–15% of net schedule duration for wet weather allowance.

All Other Works

10–15% of net schedule duration (design, procurement, internal works).

* The project's geographic location and local weather conditions must be analysed to confirm whether these percentages are appropriate.

Methods for Including Contingency

Option 1: Discrete Contingency Activities (Recommended)

Contingency should be included as one or more discrete activities — as predecessors to each contract completion milestone, key interface milestones, and the completion of project stages or Separable Portions. Separate contingency activities can also be added for different phases (Design, Procurement, Construction, Commissioning) or different construction phases (bulk excavation, structural elements, internal works).

Why this is best practice: Discrete contingency activities make it clear to all stakeholders how much contingency has been included, allow contingency to be managed and drawn down as required, and enable accurate reporting of how much contingency has been consumed as the project progresses.

Option 2: Calendar Non-Working Days

For simpler projects, inclement weather can be added as non-working days in a calendar, or dry/wet seasons can be modelled using different calendars. However, this approach effectively hides contingency — making it difficult to draw down, track, and communicate the remaining contingency to the project team.

Rail Possession Example — the cost of hidden contingency:

Works leading up to a track possession could be delayed by 3 days (e.g. insufficient productivity), causing the possession to be cancelled. The next available possession could be 3 months away. A project calendar modelling track possession windows explicitly would model this risk far better than a simple lag or duration padding.

Contingency in Activity Durations — Avoid

Contingency built into individual activity durations and calendars is harder to manage. It hides the true contingency allowance and makes it difficult to draw down and communicate how much contingency remains as the project progresses.

Quantitative Schedule Risk Analysis (QSRA)

A more rigorous approach to estimating schedule contingency is to perform a Quantitative Schedule Risk Analysis (QSRA). This estimates a range of likely schedule durations and completion dates using probabilistic methods.

Inherent risks are modelled as a range of durations for key activities (e.g. piles per day per rig).
Contingent risk events are included as discrete activities with a likelihood of occurring and a time impact when they do occur (e.g. equipment failure).
The risk model is run using a suitable tool (e.g. Safran Risk, Acumen Risk, OPRA, or similar), and contingency is selected based on the required probabilistic confidence level (e.g. P90).
QSRA provides closer alignment between the schedule, the cost estimate, and the risk register.
Schedule quality is essential — open ends and hard constraints will considerably devalue the QSRA output.

Mega Projects

Schedule risks on mega projects fall into a class of their own. A mega project is often not a single project but a program of multiple sub-projects, each with its own schedule. Risks such as scope creep, client changes, technology shifts, commissioning failures, and lack of schedule integration have been identified on numerous large/mega projects as major contributors to cost and schedule overruns. Even the PERT method of estimating durations results in a conservative schedule — QSRA is the recommended approach for mega projects.

← Step 9: Define Project Calendars Step 11: Reschedule & Review →