← Blog
Schedule Quality·5 Feb 2026·11 min read

Float: the most misunderstood number in project controls

Everyone on a project says "float" several times a day. Rather fewer could tell you how it is calculated, why total and free float differ, what a negative value actually asserts, or who is entitled to spend it. Since float decides who pays for delay, that gap is expensive.

The word everyone uses and few can define

Sit in any progress meeting and count how often float gets invoked: "we've got float on that", "the float will absorb it", "don't worry, it's not critical". Now ask the room to write down the formula. In our experience perhaps one person in five gets it right, and the proportion does not improve much among people whose signature appears on extension of time submissions.

That matters because float is not a vibe. It is the arithmetic output of a specific calculation, and every claim made about it — including the claim that consuming it is free — can be checked against the network. This article is the check.

Where float comes from: the two passes

A CPM engine schedules a network in two sweeps. The forward pass starts at the project start and works left to right: each activity's earliest start (ES) is the latest early finish of its predecessors, and its earliest finish (EF) is ES plus duration. The forward pass answers one question — how soon could each activity happen?

The backward pass then starts at the project completion date and works right to left: each activity's latest finish (LF) is the earliest late start of its successors, and its latest start (LS) is LF minus duration. It answers the mirror question — how late could each activity happen without moving completion?

Float is simply the daylight between the two answers:

On the critical path the two passes give the same dates, so float is zero. Everywhere else, the gap is the schedule's measure of slack — and the two kinds of slack behave very differently.

Forward pass, backward pass, and where the float lives (durations indicative) day 0 day 5 day 10 day 15 day 20 A · Mobilise (5d) B · Main works (10d) C · Procure pumps (4d) E · Install pumps (3d) D · Commission (5d) TF 3 · FF 0 TF 3 · FF 3 Critical path A → B → D: total float 0. Side path C → E carries one shared pot of 3 days. C has FF 0 — if C slips one day, E moves. Only E, at the end of the path, has free float. Dashed boxes = float (gap between early and late dates). Indicative durations.
Fig 1. A five-activity network after both passes. C and E each report TF of 3 days — but it is the same 3 days. If C spends it, E's float is gone before E has started.

Total vs free float: why the distinction earns its keep

The practical difference is ownership of consequences. Free float is genuinely private: spend it and nobody else notices. Total float is shared along the whole path. In Fig 1, procurement (C) and installation (E) both show 3 days of total float, but there are not 6 days available — there are 3, and whoever slips first takes them.

This is the tragedy of the commons rendered in CPM form. Every activity owner on the path looks at their own TF column, sees a comfortable number, and treats it as theirs. The first to slip grazes the common; everyone downstream discovers their "spare time" has already been eaten. By the third or fourth update the path is critical and the meeting is asking how a path with "three days of float everywhere" became the problem.

Hence a habit worth stealing: when someone says an activity "has float", ask which kind, and if the answer is total float, ask who else is on the path. The TF column is a statement about a path; only the FF column is a statement about an activity.

Float typeFormulaWhat it tells youTypical misuse
Total floatLF − EF (or LS − ES)Slip available before project completion moves — shared along the pathTreated as private slack by every activity owner on the path simultaneously
Free floatmin(ES of successors) − EFSlip available before any successor is disturbed — genuinely localIgnored entirely; most reports never show it
Negative floatTF < 0The logic cannot meet a committed date — quantified shortfallSuppressed with constraint changes instead of reported and explained
Project (terminal) floatContract date − planned finishBuffer between planned completion and the contractual deadlineClaimed as belonging exclusively to one party — see ownership, below

Negative float: a delay notice in numeric form

Float can only go negative when something other than pure logic enters the calculation — a date that has been promised. The backward pass normally starts from the logic-driven completion date, which guarantees TF ≥ 0 somewhere. Anchor the backward pass to an earlier committed date instead, and activities whose late dates now fall before their early dates report negative float. The arithmetic is asserting something precise: as the logic stands, this commitment cannot be met, and the number tells you by how much.

In practice negative float arrives by three routes:

Anatomy of negative float (indicative) Remaining critical path, driven by logic and progress Data date Contract completion (Must-Finish) late dates anchor here Forecast completion early dates end here total float = −12 working days
Fig 2. Negative float is the measured overlap between where the early dates end and where the late dates are anchored. It is not a warning that the date is at risk — it is a calculation that the date has already been lost unless the plan changes.

Contractually, a programme submitted with negative float on a contractual path is a delay notice in numeric form, whatever the covering email says. Treating it as a modelling nuisance — or worse, quietly relaxing the constraint so the column turns black again — converts a clear early warning into a later argument about concealment. This is exactly why the DCMA 14-point assessment gives negative float a tolerance of zero: not because committed dates are never missed, but because every day of it must be visible, explained and actioned.

The constraint-and-pray pattern. A Must-Finish constraint holding the completion date while negative float accumulates behind it produces a programme that displays the contract date and forecasts a later one. Reviewers who read only the bar chart see the first; the float column carries the second. Always read the column.

Who owns the float?

The classic dispute. The contractor finishes designing a path 20 days early, banks the float — then an employer variation lands on that path and consumes it. Has the employer delayed the contractor? The dates haven't moved. Or the reverse: the employer's free-issue equipment is late but arrives within float, and the contractor objects that its contingency has been spent by someone else.

Unless the contract says otherwise, the mainstream answer — reflected in the SCL Delay & Disruption Protocol (2nd edition, February 2017) — is that float is generally a project resource rather than the property of either party. The practical consequence is first come, first served: an employer delay that lands within available total float and does not push completion past the contractual date generally generates no entitlement to an extension of time, because the completion date is not — yet — being delayed. Entitlement crystallises when the float runs out.

The Protocol's position is guidance, not law, and it remains genuinely debated — contractors argue with some force that float is created by their means and methods and priced into their risk allowance, and a contract can expressly allocate it either way. But if your contract is silent, "the project owns it" is the position a tribunal is most likely to start from, and your programme narrative should assume so.

Float ownership is also where pacing lives: a contractor that deliberately slows its own work to match an employer delay is spending float in a way that later looks indistinguishable from contractor culpability — unless it was declared at the time. Pacing claimed retrospectively, with no contemporaneous record, is one of the hardest sells in concurrent delay disputes.

Float abuse: the two ways the column lies

Float is an output, so corrupting the inputs corrupts it — in either direction.

High-float pockets are usually missing logic. An activity showing 120 days of total float is rarely a relaxed activity; it is usually a disconnected one. With no successor tying it to the delivery strategy, the backward pass gives it late dates near project completion and the float balloons. This is precisely what DCMA check 6 exists to catch: no more than 5% of incomplete activities with total float above 44 working days. Pockets of enormous float are where scope drifts, because nothing in the dates creates urgency — and they are the first place we look when a network's logic density seems too thin.

Float suppression runs the same trick in reverse. Scatter enough hard constraints through a network and the backward pass is anchored everywhere: float collapses toward zero, half the programme reports as "critical", and the genuinely critical path is camouflaged among the artificially urgent. A schedule where 40% of activities show zero float is not a tight programme — it is an unreadable one. Both abuses are reasons to look at the distribution of float, not just its extremes.

Total float distribution: healthy vs broken (indicative, % of activities) Healthy programme 18% 34% 26% 16% 4% 0 1–10 11–22 23–44 >44d Broken logic + constraints 30% 8% 6% 10% 46% 0 1–10 11–22 23–44 >44d Bimodal shape on the right: constraints suppress float to zero on one side; open ends inflate it past 44 days on the other. DCMA tolerance for the >44d bucket: ≤5%.
Fig 3. Indicative float histograms. A healthy network tapers smoothly; the broken one piles up at both ends — suppressed by constraints at zero, inflated by missing logic above 44 days. The shape diagnoses the disease.
One number worth adding to your dashboard. Median total float, trended update by update. A programme whose median TF erodes steadily is consuming its commons faster than it is earning progress — months before any individual path turns red. It is also the quantity your QSRA quietly depends on: risk simulations run on a network with fictional float produce fictional confidence levels.

Reading float like an analyst

Three habits, in increasing order of rarity. First, always establish against what a float value is calculated — project completion, a sectional milestone, or a constraint — because the same activity can carry a different TF against each, and P6's multiple float paths confuse this further. Second, read total float as a property of paths and free float as a property of activities, and refuse to let anyone average the two. Third, treat any sudden change in the float profile between updates as a logic change until proven otherwise: float does not move on its own, and the question "what did you change to make this number go green?" has rescued more than one of our forensic reviews. When the answer matters in anger — when float consumption becomes an entitlement question — you are into forensic delay analysis territory, and the quality of your float arithmetic becomes evidence.

Key takeaways

See your programme's float honestly

Drop a P6 XER or MS Project file in your browser and get the full float distribution, negative float register and constraint audit in seconds. Nothing is uploaded.

← PreviousLeads, lags and logic density: the hidden mechanics of your network