Chapter 2 – Merge bias: the arithmetic of being late
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
Here is the whole chapter in three sentences. Two parallel paths, each 90% likely to finish by March, give the point where they merge an 81% chance of holding March. Add a third parallel path and it drops to 73%. Nobody decided to be late – the network structure did it.
The arithmetic
For a milestone to start on time, every path feeding it must finish on time. If the paths are independent, the probability that all of them hold is the product of their individual probabilities:
- Two paths at 90%: 0.9 × 0.9 = 81%
- Three paths at 90%: 0.9 × 0.9 × 0.9 = 73%
- Five paths at 90%: 59%
Each path, examined alone, is green. The merge point is quietly amber. This effect – [merge bias](/guide.html#merge-bias), sometimes called merge-node bias – appears at every point where parallel work converges: integration events, design reviews, test readiness gates. Which is to say: at exactly the moments programs care about most.
Why deterministic schedules cannot see it
A deterministic schedule computes each merge point's date as the maximum of its predecessors' single dates. If all three paths "finish 15 March," the merge holds 15 March, with no hint that the probability of that date just fell to 73%. The critical path method is blind to merge bias by construction: it operates on one realization of the schedule, and merge bias only exists across realizations.
This is the honest answer to a question every program office has asked: how can every subsystem report green while the program is late? Both statements are true simultaneously. Subsystem status is a statement about individual paths; program lateness is a statement about their product.
Why simulation catches it for free
A Monte Carlo schedule simulation does not average paths – it lives them. In each iteration, every task draws a duration from its distribution, the network is computed, and the merge point lands wherever that particular future puts it. Across thousands of iterations, the merge point's distribution emerges, and merge bias is simply present in it – not modeled specially, just no longer ignored. The gap between the deterministic merge date and the simulated P50 at that node is merge bias, measured.
Two practical consequences follow. First, merge bias grows with parallelism – so accelerating a program by parallelizing work (the standard recovery move) silently increases the very effect that makes programs late. There may be good reasons to parallelize anyway; the point is to price it. Second, the tasks feeding a merge deserve scrutiny proportional to the merge's fan-in, not to their individual risk scores – a modest task on the fifth parallel path can matter more than a risky task on a chain of one.
--- In practice: count the predecessors of your next major integration milestone. Raise 0.9 to that power. If the result is uncomfortable, that discomfort is information no status meeting has given you.