Armenian AI Company

The bowl only holds what it received: critical chain scheduling

Critical chain project management prescribes rules that look arbitrary — one pooled buffer, a ban on multitasking, no fixed formula for the schedule. Five results from probability, queueing theory, and computational complexity say otherwise.

Read first: what this does and doesn’t establish

  • Critical chain project management’s overall track record is contested, not settled. A widely-cited assessment found it “sporadically taught” in business schools and best used to build critical thinking about scheduling rather than treated as a formally validated methodology (Millhiser & Szmerekovsky, 2012); a 2025 review of 62 studies published since 2014 found most CCPM research still consists of modeling and simulation rather than large-scale field validation.
  • The five results below are independent mathematics and statistics — order statistics, queueing theory, computational complexity, variance under summation. Each is true regardless of whether critical chain is the right methodology for any given project. The claim here is narrower: that several specific, odd-looking CCPM rules are direct responses to these results, not arbitrary process taste.
  • The buffer formula in the closing section is itself known to undersize buffers on long chains (Tukel, Rom & Eksioglu, 2006). It is presented because it is the clearest place to see the underlying math, not as the last word on buffer sizing.

We recently spent an hour walking a room of prospective vendors through how a lab we are building plans to run production: one pooled buffer instead of padding every task, a flat rule against assigning a specialist to two projects at once, a single reported number in place of status meetings, and no promise about which tasks will run late — only about which delays will not compound. The rules are critical chain project management, inherited nearly whole from Eliyahu Goldratt’s 1997 book of the same name. An hour is not enough time to justify five of those rules properly, and a talk aimed at vendors is the wrong place to try. This is that justification: five independent results, each with its own history and its own citation, each showing that a specific rule from that hour is a consequence of what happens, mathematically, to work that is dependent, uncertain, and shared — not a preference.

A bowl can only pass on what it received

Take two independent stations in sequence, each capable of an average of μ units of work per period, with some randomness around that average — a good day, a bad day. If neither station can output more than what it actually has on hand, the second station’s realized output in any given period is the smaller of the two random draws that period, not their average. And the expectation of the smaller of two non-identical random draws is provably less than the expectation of either one alone:

E[min(X,Y)]<E[X]=E[Y]=μ

for independent, non-degenerate X, Y — that is, for any two stations whose output actually varies at all.

This is not subtle once stated, but it is easy to build a schedule that ignores it. If station A does 3.5 units on average and station B does 3.5 units on average, and B’s output each period is capped at whatever A actually handed it, the chain’s expected output falls strictly below 3.5 — not because either station is slow, but because a below-average day at A cannot be undone by an above-average day at B. The two don’t average out, because a shortfall carries forward and a surplus, once wasted, cannot be banked for later.

This is exactly the mechanism behind a demonstration Goldratt built for a Boy Scout hike and later wrote into The Goal (Goldratt & Cox, 1984, ch. 13–14): bowls stand in for workstations, matches for units of inventory, and a single six-sided die — average roll 3.5 — for a period’s random capacity at each station. Every station has identical average capacity: a textbook “balanced plant.” The rule that makes the game bite is asymmetric: a station can pass forward at most what is actually sitting in its bowl, even when that round’s roll is higher — a good roll against an empty bowl produces nothing, and the unused capacity is gone, not saved. A bad roll leaves the bowl short, and the shortfall is exactly what the next station finds waiting for it (maaw.info). Run the line, and total system output settles below 3.5 per station per period, inventory piles up unevenly between stations, and the position of the slowest step drifts from run to run — Goldratt’s “floating bottleneck.” A schedule built by simply summing each task’s average duration is implicitly assuming the surpluses and shortfalls along the chain cancel out. They don’t, systematically, in the direction that makes projects late.

The date at the merge point

A single chain of dependent tasks is the easy case. Most real schedules are networks: several parallel streams of work converge on one shared task — art, code, and audio all landing on the same integration build, say. Classical critical path method treats a convergence point’s start date as fixed by whichever path was identified, once, as “the” critical path. But when every task’s duration is a distribution rather than a fixed number, the convergence point’s actual completion time is the maximum of several random variables, not the value of one path chosen in advance — and the expectation of a maximum of several non-identical random draws is provably at least as large as any one of them, and typically larger than all of them. The effect has a name, merge bias, and a long history: it was first analyzed rigorously by MacCrimmon & Ryavec (1964), as part of a RAND-funded study of exactly where PERT’s assumptions break down.

A concrete illustration, described by David Hulett — a contributor to PMI’s risk-management guidance — makes the size of the effect vivid. Take a schedule whose classical CPM calculation puts a milestone 130 days out, on April 2. Add one additional, statistically identical parallel path feeding that same milestone, with no change to the critical path’s own tasks. The CPM date does not move; it is still April 2, because CPM only ever looks at the length of the one path it has named critical. But a Monte Carlo simulation of the same network shows the probability of actually hitting April 2 collapse, from 13% to 1%; the simulated mean completion date shifts about five calendar weeks later, to May 6, and the date by which the project has a genuine 80% chance of finishing moves out by nine days, from May 14 to May 23. Nothing about any individual task changed. Only the number of parallel things that had to converge did.

The fix is nearly as old as the problem. Van Slyke (1963) introduced Monte Carlo simulation for PERT networks specifically to escape this blind spot, and along with it a quantity classical CPM cannot define at all: the criticality index, the fraction of simulated runs in which a given task actually lands on the longest path. In a network with real parallel structure, different simulation runs can produce different critical paths — “the” critical path is itself a random variable, and only simulation, not one deterministic pass, can say which tasks are actually dangerous, and how often.

This is the rigorous version of why critical chain treats feeding buffers as seriously as the project buffer itself: every point where a parallel path rejoins the chain is a small merge-bias event, and skipping a feeding buffer at a rejoin quietly reintroduces a blind spot scheduling theory has known about since the early 1960s.

Why idle beats busy: Kingman’s formula

Queueing theory has a precise name for what happens when a shared resource is pushed toward full utilization, and it is considerably more dramatic than “a bit slower.” For a single server whose arrivals and service times are each irregular rather than perfectly clockwork — the general G/G/1 case, which describes a specialist fielding requests from several projects about as well as anything does — Kingman’s (1961) approximation gives the expected wait in queue as:

E[Wq]≈ρ1−ρ×ca2+cs22×τ

where ρ is utilization — the fraction of available time the server is actually busy — τ is the mean time to serve one arrival, and ca, cs are the coefficients of variation of arrivals and service respectively, a measure of how ragged each is. The approximation is known to be most accurate exactly where it matters: close to saturation.

The term doing the damage is ρ/(1−ρ). It does not rise in proportion to how busy the server is — it explodes as ρ approaches 1:

ρ = 0.8 → 4  ·  ρ = 0.9 → 9  ·  ρ = 0.95 → 19  ·  ρ = 0.99 → 99

Pushing a specialist’s utilization from 80% to 90% does not raise this factor by a quarter; it more than doubles it. Pushing it to 99% multiplies it by roughly 25 again. Wait time does not degrade in proportion to how full someone’s schedule is — it explodes, non-linearly, as full approaches complete.

This is the queueing-theory version of the multitasking cost every producer has felt in practice: handing a specialist a second project doesn’t cost the first project a proportional slice of their time, because that specialist’s utilization was probably already high, and a small increase near saturation buys a disproportionate increase in how long everything now queued behind them has to wait. Critical chain’s flat rule against multitasking specialists on the chain, read this way, is not a productivity slogan. It is keeping ρ away from the region where the formula stops being forgiving.

No formula for where to cut the chain

A natural question, watching a project sliced into critical-chain-sized blocks, is why there isn’t a formula for the cut — some optimizer that takes a project’s tasks, their dependencies, and the specialists available, and returns the provably fastest schedule. There isn’t one, and the reason is not a gap in the tooling. Scheduling a set of activities under both precedence constraints (task B needs task A first) and renewable resource constraints (there is one Alex) — the Resource-Constrained Project Scheduling Problem, RCPSP — is NP-hard, a result that has stood since Błażewicz, Lenstra & Rinnooy Kan’s 1983 classification of scheduling problems by computational complexity. Finding the provably optimal schedule doesn’t merely get slower as a project grows; it gets slower in a way no known algorithm escapes short of, in the worst case, checking a number of possibilities that grows exponentially with the number of tasks.

The state of the art is a reminder of how hard the problem is, not a rebuttal to it: as recently as 2019–2020, a new preprocessing routine paired with a set of cutting-plane techniques — clique, odd-hole, and lifted precedence and cover cuts — finally resolved 754 previously-open benchmark instances from the standard PSPLIB, MMLIB, and MISTA scheduling libraries to proven optimality (Araujo, Santos, Gendron, Jena et al., 2019). That is decades after those instances were first posed, on problem sizes that are toy-scale next to an actual production schedule. Exact optimization of a resource-constrained schedule remains, for anything the size of a real project, out of reach. Priority-rule heuristics and human judgment aren’t a fallback critical chain settles for instead of solving the problem properly — for a problem in this complexity class, at this scale, they are the only approach anyone has.

Two ways to size one pooled buffer

Pooling every task’s individual safety margin into one project buffer, rather than padding each task separately, is easy to justify informally: uncertainties in independent tasks partly cancel, so the chain doesn’t need the sum of everyone’s worst case, only something smaller. Making that precise is where variance comes in. For independent random durations, variances add under summation — the variance of a sum of independent things is the sum of their variances, whatever each one’s own shape — while the standard deviation, which is what actually governs how wide a confidence interval has to be, grows only as the square root of that sum. A chain of many small, independent uncertainties ends up with a standard deviation much smaller, relative to the sum of everyone’s individual padding, than intuition expects. This is the same fact that sits underneath the Central Limit Theorem, stopped one step short of claiming the sum becomes normally distributed.

Newbold’s (1998) Root Squared Error Method (RSEM) turns this into an actual formula. For a chain of n activities, each given a “safe” (heavily padded) duration and an “aggressive” (50%-confidence) duration, the pooled buffer is:

buffer=∑i=1n(safei−aggressivei)2 buffer=2σchain,σchain=∑inσi2

the second line is the same formula read as twice the chain’s overall standard deviation, under the assumption that each activity’s safe-minus-aggressive gap represents two standard deviations of that activity’s own uncertainty.

A short worked example makes the shrinkage concrete. Three activities on a chain, with (safe, aggressive) pairs of (9, 6), (6, 4), and (3, 2) days. Summing each activity’s own padding — the “pad every task” approach this pooled-buffer idea replaces — would add 3 + 2 + 1 = 6 days of buffer. Pooling it via RSEM instead gives √(3² + 2² + 1²) = √14 ≈ 3.7 days — more than a third smaller, for comparable statistical protection, purely from not assuming every task independently hits its worst case on the same run.

RSEM is not the last word. Because it assumes activity durations are independent and roughly symmetric around their aggressive estimate, it has a documented failure mode: on long chains it tends to undersize the buffer, understating how much real variation accumulates (Tukel, Rom & Eksioglu, 2006) — part of why Goldratt’s cruder “cut and paste” rule, halving each task’s safe estimate and handing the other half straight to the pooled buffer, remains in wide use despite being mathematically less refined: it degrades more gracefully when tasks are correlated, biased, or simply mis-estimated, which real tasks usually are.

None of this is a private discovery of critical chain’s. A government agency runs into the identical curve from a completely different direction: the UK Department for Transport requires road-scheme cost estimates to carry a 15% contingency for 50% confidence of staying within budget, rising to 45% for 90% confidence; for rail projects, the same jump in confidence requires uplift to rise from 40% to 68% (Flyvbjerg, 2013). The shape — confidence rising steeply, the buffer needed to match it rising faster still — is the same non-linearity a chain of right-skewed task estimates produces. It shows up wherever uncertain durations get totalled against a promised date, whether or not anyone involved has heard of Goldratt.

Put together, the five results share a shape: work that is dependent, variable, and shared behaves worse than the average of its parts suggests, and the size of the gap is computable, not just felt. A chain drops below its stations’ average because shortfalls carry forward and surpluses don’t. A merge point lands later than its longest named path because it is a maximum, not a sum. A specialist’s queue explodes non-linearly, not proportionally, as their schedule fills. No algorithm can hand back the provably fastest cut of a real project, because finding one is provably hard. A pooled buffer can be smaller than the sum of its parts’ padding for the same statistical protection, because variance adds slower than intuition expects. None of the rules a room of vendors hears in an hour — one buffer, no multitasking, no fixed formula for the cut, a single reported number — are preferences. They are what these five results, independently, force on anyone scheduling work that depends on other work, varies unpredictably, and competes for the same hands.

References