Chapter 1 – Why single dates lie
The Quantitative Schedule Risk Analysis Handbook · Edition 1, August 2026 · by the team behind [Epoch SRA](https://epochsra.com), an Excel add-in for schedule risk analysis · corrections welcome at contact@epochsra.com
Every program we have worked on had two schedules.
The first is the official one: a network of tasks with single dates, reviewed, baselined, and signed. It says the payload integrates in May and the program finishes on 02 December. Full stop.
The second schedule lives in the project manager's head. It says: "if the optics slip again, May is gone." It says: "the test chamber is oversubscribed – we might wait six weeks for a slot." It says, when asked privately: "realistically? February."
The second schedule is usually closer to the truth, and it is stored in exactly one place: one person's intuition. It cannot be reviewed, cannot be handed over, cannot be argued with, and leaves the building when that person does.
Quantitative Schedule Risk Analysis is, at its core, the act of moving the second schedule out of someone's head and into arithmetic. Everything else – Monte Carlo simulation, percentiles, tornado charts – is mechanism. The point is honesty about what you do not know, made precise enough to plan with.
Where the single date comes from
A deterministic schedule assigns each task one duration. Where does that number come from? Usually from an engineer who was asked "how long will this take?" – a question that quietly means "what number can you commit to?" Human beings answer that question in two well-documented ways: with optimism (the plan assumes the design review passes the first time), or with hidden padding (the estimate protects its owner against being blamed). Both distortions are invisible in the final plan, because a single number carries no record of the uncertainty it summarizes.
The result is a schedule that is precise – dates to the day – and systematically inaccurate. Precision without accuracy is worse than useless: it invites confidence.
Tasks finish late more than they finish early
Duration uncertainty is not symmetric. A task estimated at 30 days can plausibly take 45 or 60 – a failed test, a late delivery, a requirement change – but it can rarely take 10. The distribution of real outcomes has a short left side and a long right tail.
A single-point estimate silently averages that distribution, or worse, reports its most optimistic defensible value. When many such estimates are chained into a network, the errors do not cancel – they compound, and always in the same direction. This is why programs are late far more often than they are early, even when every individual estimate seemed reasonable.
What this chapter asks you to accept
Only two things. First: your official schedule is a set of point estimates drawn from distributions nobody wrote down. Second: the information needed to write those distributions down already exists in your organization – in the risk register, in engineers' hedged answers, in the last program's actuals. QSRA is the discipline of connecting them.
The next chapter shows why chaining even good estimates into a network produces systematic lateness – an arithmetic effect called [merge bias](/guide.html#merge-bias) that no deterministic schedule can see.
--- In practice: a useful first exercise on any program is to ask, for the three most uncertain tasks, "what would this duration be if it went badly – and how likely is that?" If the answers surprise the official schedule, the second schedule exists, and it is worth formalizing.