Float is a significant, finite, shared resource with no owner, no allocation rule and no record of consumption, and the first person to touch a non-critical activity spends it on behalf of everyone downstream.
The discipline that trains delivery professionals issues two instructions about float, and both are live. The first says float is a buffer against uncertainty rather than a budget to spend. The second says that when a schedule needs compressing, one available move is to reduce float by tightening the estimates on non-critical activities, deliberately invoking Parkinson's Law — that work expands to fill the time available for its completion. The same body of teaching contains both, in near-identical wording across separate documents, and one of those documents elsewhere presents that law as the enemy a rival scheduling method exists to neutralise.
This is not a debating point about pedagogy but a live allocation question inside every enterprise running a schedule. Two competent people, trained on the same material, can reach opposite conclusions about whether one activity's slack is protection or fat, and neither can cite a rule the other has broken, because no rule exists.
The stakes are larger than the argument suggests. Float is the enterprise's real schedule contingency: larger than the declared contingency, never priced, and absorbing the variation that would otherwise move the completion date. When it is gone, every path controls the date, and a delay in an activity nobody was watching becomes a delay to the enterprise. It is also spent without anyone deciding to spend it. A crew reschedules for convenience. A supplier's delivery is accepted a fortnight late because the schedule showed room. A resource moves to a more visible task. None of these is recorded as consumption, because schedules record dates, not entitlements. The days cease to exist, and the next report shows a smaller number in a column few people read.
The Strategic Context
Float is created by the shape of the network: wherever a chain of work is shorter than the chain beside it, the shorter chain acquires slack, and that slack is the difference between a schedule that survives ordinary variation and one that does not. Every other reserve of comparable value has an owner and a rule. Cash contingency has a delegation schedule and a change board; scarce specialist labour has an allocation process; management reserve has a release authority. Float has none, while doing the same job: absorbing the difference between what was planned and what occurs.
The exposure compounds with scale. On a single project the delivery manager can often see where the slack sits and who is eating it. On a programme the chains cross organisational boundaries, and slack created by one project's sequencing is consumed by another's resource decision without either party knowing. At portfolio level, shared specialists, approval authorities and test facilities mean float is traded between delivery units with no sight of each other's schedules and no forum in which the trade could be discussed.
One prior question sits underneath this and is treated elsewhere in this series: whether the dependency creating the float is a genuine constraint or an inherited convention. Slack that exists only because a sequence was never challenged is a different asset from slack that exists because physics requires it.
What the Schedule Appears to Say
Four readings are near-universal, and each costs time the enterprise has already paid for.
The first is that float shown against an activity belongs to it. Total float is a property of the chain the activity sits on. The tool prints the same days against every activity on that chain, and each owner reads them as personal headroom. Five managers can each be told they have a fortnight, and between them they have a fortnight.
The second is that consuming float is free because the completion date does not move. The date does not move; the protection does. Every day of slack consumed is a day of variation the schedule can no longer absorb, and the loss surfaces only when something goes wrong later, where it is attributed to that later event.
The third is that reducing float is efficiency. Tightening a non-critical estimate converts a buffer into a commitment, and does so by invoking a behavioural law the same discipline elsewhere treats as a pathology to design out — the pooled-buffer approach set out by Eliyahu Goldratt exists precisely to stop work expanding into the time it is given. An enterprise following its own training material can justify creating buffers and destroying them, using the same law.
The fourth is that consumption is visible. There is no float account, no transaction record and no notification to the parties whose protection has been reduced. The evidence of a spend is a lower number in a later report, indistinguishable from ordinary progress.
Reframing the Issue
The enterprise holds two contingencies, not one. The first is denominated in money, sits in the budget, and has an owner, a release authority and a record of every drawdown. The second is denominated in days, sits in the network, and has none of those. It is usually the larger, and it is the one being spent right now by someone who does not know they are spending it.
Framed that way, the question stops being whether float should be preserved or harvested — which has no general answer — and becomes who is entitled to decide, on which chain, and against what record. That question has an answer, implementable without new software.
It also reframes compression proposals. Tightening non-critical estimates spends the enterprise's time contingency, and should meet the same test as spending its money. What that time is worth — the duration at which the project costs least, and the overhead rate that fixes it — is not treated here; that is the subject of [Related article: The Cheapest Duration You Only Find When You Are Late]. The concern here is prior to the pricing: who may make the transaction at all.
How Float Is Actually Spent
It belongs to the chain, not the activity
The distinction that matters operationally is between the slack an activity can consume alone and the slack it shares. An activity can usually absorb some delay without disturbing its successor's earliest start; beyond that, any further delay is taken from every activity downstream on the same chain. Almost every schedule reports the shared figure against each activity without qualification, and the result is systematic double-counting: the network holds one reserve and the report distributes a copy to each holder. Nobody is lying and everybody is wrong.
This is why the first mover wins: they work from a number true at the moment they read it and false immediately afterwards, and nothing tells the managers downstream that it changed.
The compression instruction that nobody counter-signs
Consider a municipal water utility running a multi-year mains renewal programme, with trunk works on the critical chain and land access, easement negotiation, community notification and customer connections on chains beside it — hypothetical, but a recognisable shape. The slack on those parallel chains is what makes the programme survivable, because they depend on third parties whose responsiveness the utility does not control.
Now apply the compression instruction: tighten those estimates, on the reasoning that the work will otherwise expand to fill them. The reported schedule improves and nothing about the third parties has changed. The programme has removed the buffer between an external party's unpredictability and its own completion date, as a presentational exercise, since none of the tightened activities was controlling the date.
The instruction is not stupid; slack does invite drift and estimates do inflate. But it arrives without a counterpart. Nothing says who must approve the removal, or how to choose between the two contradictory instructions. In practice the choice falls to whoever prepares the schedule that week.
Consumption without a record
The absence of a ledger is the whole failure. Enterprises can say precisely how much money contingency has been drawn and by whom. Asked how many days of float their largest programme held at baseline and how many remain, few can answer.
That gap also sets the earliest moment anything can be noticed. Consumption cannot be detected faster than the control system's reporting granularity allows, and that granularity is usually an inherited convention. Why it sets both the cost of control and the earliest possible detection of any problem inside it is examined in [Related article: The Rule of Thumb Behind Your Detection Time]; the narrower point here is that a resource with no ledger cannot be reconciled at any frequency.
Consider a touring live-events production, hypothetically, where freight, venue availability, rigging crews and rehearsal sit on separate chains converging on the first performance. An early freight window creates slack; a rehearsal decision consumes it. No transaction is recorded, and the exposure surfaces at the final venue, where a routine load-in has become the activity controlling opening night.
Decision Framework: The Float Consumption Register
The float consumption register is a single ledger, owned by the schedule authority, that turns an unowned reserve into a governed one. It can be built from an existing baseline in a day.
- Record float by chain, not by activity. At baseline approval, list every chain with its total float. This is the opening balance, and it is usually larger than leadership expects.
- Name a chain owner. Each chain's float is owned by the delivery owner accountable for the completion date, never by an activity owner.
- Set the entitlement rule. An activity owner may absorb delay up to the point where a successor's earliest start would move. Beyond that, consumption requires the chain owner's authorisation, because it removes protection from everything downstream.
- Log every transaction. Date, chain, days consumed, consumer, reason — slippage, resequencing, estimate tightening or reallocation — remaining balance, approver. This is not a system project.
- Set two thresholds. When a chain's remaining float falls below one reporting period, reclassify it as critical. When total network float falls by more than a stated fraction from baseline while the date is unchanged, treat the schedule as re-baselined in substance and review it.
- Reconcile monthly. Split consumption into float lost to slippage and float spent deliberately. Deliberate spending that bought no shorter date, lower cost or retired risk is the enterprise selling its protection for nothing.
- Apply the compression test. Any proposal to compress by tightening non-critical estimates states which chains lose float and how many days, and goes to the authority that would approve an equivalent draw on money contingency.
The adoption test is blunt: ask what the opening balance was and what it is now. An enterprise that cannot answer is not managing float; it is discovering it.
From Strategy to Execution
Immediate. Take one live programme, compare the baseline network with the current one, and compute float by chain in both. The difference is what has been spent. Ask who authorised it; the value is not the number but the silence that follows.
Medium term. Put the entitlement rule into the schedule management plan, add remaining float by chain to the standard report, and amend the compression playbook so estimate tightening on non-critical work is a governed transaction rather than a scheduling technique. Where delivery is contracted out, make ownership of float in the joint programme an explicit term: absent one, a contractor's schedule absorbs slack the client paid for, and the client learns this during a claim.
Long term. Treat time contingency as a reserve of the same standing as money contingency, with a declared appetite, an owner and a reporting line. The capability worth building is not a better scheduling tool but the habit of asking, before any resequencing, whose protection this consumes. Whether the risk instrument alongside it can represent the rare events float absorbs is a separate question, addressed in [Related article: The Floor Beneath Your Risk Scale]; the register governs the reserve, not the scale that sizes it.
Signals to Monitor
The clearest indicator is a rising count of activities at or near zero float while the completion date is unchanged. That has one explanation: the network's protection is being consumed and the report presents it as stability.
Watch for activities that were never near the critical chain becoming critical late in delivery, for chains within one reporting period of critical trending upward between baselines, and for compression proposals whose savings come from work that was not controlling the date. Each is the same event from a different angle. Watch also for the absence of an argument: where a proposal to tighten non-critical estimates passes without a discussion of whose protection is being sold, the reserve has no owner.
Questions for the Leadership Team
- How many days of float did our three largest programmes hold at baseline, and how many remain?
- Who authorised the difference, and where is that authorisation recorded?
- What is our rule for who may consume shared slack, and can a delivery manager state it without looking it up?
- In the last four compression decisions, how many days of protection were removed from chains that were not controlling the date?
- Where our schedules are integrated with a supplier's, which party owns the float in the joint network, and what does the contract say?
- How many activities in each major programme now sit within one reporting period of critical, and what was that count at baseline?
Each requires reconstructing something the enterprise does not hold. The reconstruction is the point.
Closing Perspective
None of this is a scheduling problem. The arithmetic of float is settled and the tools compute it correctly. What is missing is the ordinary apparatus of stewardship every other scarce resource already has: an owner, an entitlement rule, a record and a reconciliation.
Until that exists, the enterprise runs a reserve it did not budget, cannot measure and does not control, and the person spending it is whoever opened the schedule first. That would be indefensible for any other asset of comparable value; it survives here only because the consumption is invisible until the moment it matters. The decision in front of leadership is not whether to preserve float or harvest it, but whether to keep allowing that decision to be made, unrecorded, by the first person to reach for it.
About EraNorth Insights
EraNorth Insights publishes practical analysis on strategy, projects, operations, transformation and decision intelligence for professional and organisational use. About EraNorth.