Float belongs to the project, not to whoever reaches it first

Every schedule contains time that is not on the critical path. Some of it is deliberate contingency; most of it is a byproduct of the logic. Together it is the project's capacity to absorb the things that will go wrong.

Almost no project decides who owns it. The contract is silent, the schedule does not report it, and the result is that float is consumed by whoever needs it first, without a decision being taken and often without anyone noticing until it is gone.

Total float and free float are different questions

The argument about who owns float is usually conducted without either party saying which float they mean, and the two answers are not the same.

Total float is how long an activity can slip before it delays the project's completion date. It is shared: a chain of activities on the same path draws on one pool, so the first party to use it reduces what is left for everyone behind it.

Free float is how long an activity can slip before it delays the next activity in the chain. It belongs to one activity alone, and consuming it disturbs nobody.

The distinction decides what a claim is actually about. A delay that eats free float has harmed no one and should be uncontroversial. A delay that eats total float has quietly taken resilience from every party downstream while the completion date still reads as unchanged — which is precisely why it passes unremarked. When a contract says float is owned by the project, it means total float; a provision that does not say which it means will be read by each party as whichever reading helps it.

What float is doing in the program

Float is the reason a schedule can survive contact with reality. A path with fifteen days of float can absorb a fifteen-day supplier delay without moving the completion date. Once that float is spent, the same delay moves the end date directly.

This means the project's exposure is not described by its completion date. It is described by how much float remains and where it sits. A program reporting on schedule with no float left on three parallel paths is in a materially worse position than one reporting two weeks late with float intact everywhere else — and the reporting almost never says so.

How it disappears without a decision

Float is consumed in four ordinary ways, none of which register as an event.

Sequence changes. A contractor reorders work for its own efficiency, which is generally reasonable and often beneficial. The reordering can also convert a path with float into a near-critical one, and the schedule update shows the new logic without highlighting what was given up.

Early consumption of shared buffer. Where a program holds a period of contingency before a fixed milestone, the first party to run late uses it. That party is not misbehaving; it is responding rationally to available slack. But the buffer was there for the whole program, and the parties who need it later find it spent.

Progressive re-baselining. Each update accepts the current status as the new starting point. Small slippages absorbed one at a time never appear as a delay, and the float that absorbed them is never reported as consumed.

Unstated compression in the original plan. Some programs are issued with little float in the first place, having been built backwards from a committed date. Here the float was never there, and the schedule's apparent health is a function of optimistic durations rather than of real slack.

The date a project reports is the least informative number in the schedule. What matters is how much of its ability to absorb bad news it has left.

Allocating it in the contract

Float ownership is a contractual question and it should be answered explicitly. Three positions are common and each has consequences.

Float is owned by the project. Neither party may consume it without agreement, and a party whose delay eats into it may be liable for the reduced resilience even if the completion date has not moved. This is the strongest owner position and the hardest to administer.

Float is available to the party that needs it, first come. The default in the absence of any provision. Simple, and it systematically favors whoever is early in the sequence.

Float is owned by the contractor. Common in contractor-drafted programs. It means owner-caused delays that consume only float may still attract an entitlement claim, because the contractor's own buffer has been taken.

None of these is wrong in every case. What is wrong is not choosing, because the default choice is the second one, and the second one gives the owner the least visibility and the least control.

Terminal float is the version of the question that carries the most money

A contractor's program frequently shows completion earlier than the date the contract requires. The gap between the two is terminal float, and it is the sharpest form of the ownership question because it is the float most likely to be argued about after the fact.

The contractor's position is that the early finish is its own plan, achieved by its own sequencing, and that an owner-caused delay eating into it has taken something of value even though the contract date is untouched. The owner's position is that it contracted for a date, has received that date, and owes nothing for the loss of a margin it never asked for.

Both readings are arguable, which is the problem. An owner that accepts a program showing an early finish without saying anything about it has accepted the ambiguity. The moment to resolve it is when the baseline is approved, in writing, and the resolution can go either way — what it cannot do is stay open until there is a claim attached to it.

Float is easy to hide, and the hiding is rarely deliberate

A program can show a comfortable float position that does not exist. Four mechanisms account for most of it, and none of them requires bad faith.

Preferential logic. Links that encode how the contractor prefers to work rather than what the work actually requires. They are indistinguishable from physical constraints in the file, and they move float from where it really sits to where the logic says it sits.

Date constraints. A constraint pinned to an activity can mask float or manufacture it, and a "start no earlier than" applied broadly will flatter a program's resilience considerably.

Inflated durations. Float hidden inside activities rather than between them. The path shows no slack, but each task carries private contingency the schedule cannot see and the owner cannot reallocate.

Long-lead activities modeled as single bars. A procurement item shown as one activity conceals the real sequence — award, submittal, fabrication, shipping, delivery — and with it the float and the true constraint. The order date, not the installation date, is usually what governs.

The test is not whether the program reports float. It is whether the float survives inspection of the logic underneath it. How to tell whether a project schedule is credible sets out the checks that separate a derived schedule from a target with activities arranged to reach it.

Negative float is a reporting artifact, not a diagnosis

When a constrained date sits earlier than the logic can deliver, the calculation returns negative float, and every activity on that path is reported as behind before any work has slipped.

It is worth reading as a question rather than a status. Negative float says the program as modeled cannot meet a date it has been told to meet. That is sometimes a genuine delay; it is just as often a constraint applied to a date that was aspirational, or logic that was never correct. Treating it as a delay invites acceleration spending against a problem that acceleration cannot solve, because the obstacle is in the model rather than in the field.

Making it visible

The reporting change is small and unusually high-value. Alongside the completion date, a schedule update should state the float remaining on each significant path, the change in that float since the previous update, and the cause of any reduction.

Three consecutive updates showing declining float on a path that is not yet critical describe a problem that will become a delay in about two months. The same three updates reported only as dates show a project on schedule.

Two additions make the report harder to argue with. A count of activities whose logic or constraints changed since the last update, which is where silent float transfers happen. And the float position on the paths that are not critical, since the critical path is already watched and the next delay will come from somewhere that is not yet on it.

That is the whole argument for tracking it. Float is the only leading indicator a schedule contains — the change pipeline is the other one, and it sits in the commercial reporting rather than the schedule. Everything else in a schedule update is a report on what has already happened.