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.

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.

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.

That is the whole argument for tracking it. Float is the only leading indicator a schedule contains. Everything else in a schedule update is a report on what has already happened.