Schedule contingency: what it is and how to calculate it

A deterministic schedule assigns one duration to every task and rolls them up into one finish date. That date is, at best, a P50 estimate: a coin flip. Half the plausible outcomes finish later. Yet teams routinely commit to it as if it were a guarantee, which means the plan ships with effectively zero real contingency against a deadline everyone treats as firm.

The usual reaction is to pad individual task estimates for safety. This is worse than it looks. Hidden per-task padding inflates the whole plan without making the deadline measurably safer, and it is silently consumed by the student syndrome (work starts late because there is slack), Parkinson's Law (work expands to fill the time), and the fact that delays propagate while early finishes rarely do. You end up with a longer schedule that still has no defensible reserve — the padding is scattered, invisible, and gone before you notice.

The fix is to separate the median estimate from the protection. Estimate tasks to an honest 50% duration, then hold contingency explicitly at the level where it can absorb variation across the whole network — not buried inside each task where it leaks away.

AACE International's recommended practices for risk-driven scheduling — including the RP 132R-23 Level 4 approach — treat contingency as an output of a quantitative model, not a percentage rule of thumb. Instead of adding a flat 15% or 20% "because that's what we always do," you build a probabilistic model of the schedule and read the contingency off the resulting distribution of finish dates.

The mechanism is Monte Carlo simulation. Each uncertain task gets a three-point estimate (optimistic, most likely, pessimistic), usually fitted to a PERT-Beta or triangular distribution. Discrete risk events can be injected with their own probability and impact. The model then runs thousands of iterations, sampling a duration for every task each time, and records the project finish date for each run. The spread of those finishes is your uncertainty made explicit.

Contingency is the distance between two points on that cumulative distribution. Pick the deterministic baseline (typically the P50, the median) and the confidence level you must commit to (commonly P80 or P90 for high-stakes programs), and the contingency is simply the later date minus the earlier one.

Suppose a biotech program models its path to an IND filing. The deterministic Gantt shows a finish on March 15. After Monte Carlo simulation with three-point estimates on every task and two injected risk events (a CMC vendor slip and an assay re-run), the distribution of finishes shows a P50 of March 22, a P80 of May 4, and a P90 of June 1.

Notice the deterministic March 15 date is actually below the P50 — it was optimistic, as single-date plans usually are. If the board needs 80% confidence, the committed date is May 4 and the schedule contingency relative to the median is about six weeks (P80 − P50). If the milestone is contractual and demands 90% confidence, contingency grows to roughly ten weeks (P90 − P50). The number is no longer an argument; it falls out of the model, and you can show exactly which tasks and risk events drive it with a tornado chart and criticality index.

Contingency is not a one-time calculation; it is a balance you draw down. As tasks complete and uncertainty resolves, the distribution tightens and the required reserve shrinks. The job of program management is to track whether you are consuming contingency faster than you are retiring risk — the same logic that powers a CCPM fever chart, where buffer consumption is plotted against project completion in green/yellow/red zones.

This reframes status reporting. Instead of debating whether a particular task is "on track," you watch a single signal: how much of the protective reserve remains versus how much work is done. Green means you are ahead of your risk burn-down; red means the contingency is eroding faster than the program is de-risking, and the committed date is genuinely threatened. That early warning is the entire point of sizing contingency honestly in the first place.

CritPath AI derives schedule contingency the AACE-aligned way, end to end. You enter three-point estimates and optional discrete risk events; its Monte Carlo engine (PERT-Beta distributions, risk injection, optional duration correlation) runs the simulation and reports the full P50/P80/P90 distribution. The contingency for any milestone is shown directly as the gap between your chosen confidence level and the deterministic/median date — no spreadsheet, no manual percentage.

Because the same engine drives CCPM buffer sizing, the contingency you compute flows straight into project and feeding buffers and onto a live fever chart, so you can watch it consume in real time. Tornado charts and the criticality index show which tasks and risks own your contingency, and a schedule-aware AI copilot — grounded in your actual dependency graph, not a generic chatbot — explains what is eating the reserve and what a proposed change does to your P80. It is $10 per user per month, with AI usage billed separately by metered usage, in a modern web app rather than a desktop risk tool.