Skip to content

Schedule Float Stack Review

A project review — instantiates Tolerance Stack Management

Treats the slack along a chain of dependent tasks as one shared buffer being consumed by each handoff's slip, and rebalances it before the accumulated delay eats the delivery date.

On a project, every task carries some slack — float — and each is often judged in isolation: "we're only two days late, and we had three days of float." Schedule Float Stack Review refuses that local framing. It treats the float along a dependency chain as a shared, depletable buffer that every task's slip draws from in sequence, and it reviews the running consumption against the one deadline that matters. Its defining move is temporal accumulation: a string of small, individually-absorbed slips can consume the whole chain's float so that the final task inherits a deadline it cannot meet, even though no single task was ever "late." The review turns float from a private comfort each task thinks it owns into a common reserve that is metered, protected, and reallocated across the chain.

Example

A building fit-out runs a dependent chain: design sign-off → long-lead procurement → mechanical rough-in → inspection → finishes → handover, with a fixed handover date and about three weeks of total float distributed along the path. Design sign-off slips four days — "fine, procurement had slack." Procurement then slips a week absorbing a supplier delay — "still okay, rough-in had a buffer." Each manager, looking only at their own task, sees float remaining. The Schedule Float Stack Review pulls the whole critical path together and shows the shared reserve has fallen from three weeks to two days with finishes not yet started — the accumulated slip, not any one delay, has nearly exhausted the buffer. It responds not by blaming a task but by rebalancing: crashing the inspection step, resequencing two finishes to run in parallel, and ring-fencing the remaining float as a protected project buffer no single task may quietly spend.

How it works

The review reads the dependency network as a stack whose "fit limit" is the delivery date and whose "budget" is the total float along the critical path. It tracks how much float each completed handoff has consumed, rolls it into a running total, and compares that against the reserve remaining — monitoring the accumulated schedule error rather than per-task lateness. When consumption crosses a threshold, it rebalances: resequencing, crashing, or moving buffer to where the risk now sits. What distinguishes it from the calculating siblings is that its contributors are tasks in time and its compensating element is float itself — a buffer to be positioned and defended, not a dimension to be measured.

Tuning parameters

  • Buffer placement — whether float is left scattered task-by-task or aggregated into a protected buffer at the end of the chain. Aggregation resists local squandering but demands central discipline.
  • Review cadence — how often consumption is re-read against remaining reserve. Frequent review catches the erosion early; sparse review discovers it when finishes are already boxed in.
  • Trigger threshold — how depleted the shared float must get before rebalancing fires. Early triggers act while options are cheap; late ones wait until only crashing (expensive) remains.
  • Rebalancing levers — which responses are on the table — resequencing, crashing, fast-tracking, de-scoping — and their cost order.
  • Path scope — whether the review watches only the critical path or also near-critical paths that a few slips could promote into the binding one.

When it helps, and when it misleads

Its strength is catching the project version of the archetype's core failure: a delivery date missed by the accumulation of slips that were each locally absorbed, seen coming while there is still float to move rather than at the end when there is none. Managing float as a shared, positioned buffer rather than private per-task slack is the core insight of critical-chain scheduling.[1]

It misleads when the float ledger is fiction: padded task estimates hide phantom buffer, and Parkinson's law means aggregated float quietly gets consumed to zero regardless of need unless it is actively protected. It can also fixate on today's critical path while a near-critical path, fed by its own slips, becomes the real binding chain unnoticed. And it is easily run backwards — convened to assign blame for a slip rather than to reallocate the remaining buffer. The discipline is to strip padding so the float number is real, protect the aggregated buffer from casual draw-down, and watch near-critical paths, not just the current one.

How it implements the components

  • adjustability_or_compensation_element — schedule float is the compensating buffer that absorbs upstream slip; the review positions and defends it as the stack's adjustable element.
  • rebalancing_rule — it fires resequencing, crashing, or buffer-relocation when accumulated slip drives the remaining reserve past a threshold.
  • integration_error_monitor — it observes the accumulated schedule deviation against the delivery date, the time-domain analogue of monitoring integrated error rather than per-task conformance.

It does not set the delivery commitment itself, nor allocate the original float across tasks — the initial budget split is the job of Variation Budget Allocation Sheet, and the accountable ownership of the aggregate belongs with Cumulative Discretion Review.

Notes

The tempting mistake is to manage each task's float locally, which is exactly the local-acceptability trap the archetype exists to defeat: every task can be "within its buffer" while the chain runs out of reserve. The review only works if float is treated as one pool, not many private ones.

References

[1] Critical-chain project management (from the theory of constraints) argues that per-task safety time is systematically wasted, and replaces it with a smaller shared project buffer placed at the end of the chain and monitored as it is consumed — the scheduling analogue of a shared variation budget. ↩