Shared schedule float

Why does one task running late steal slack from tasks that were never late?

The programme says the cladding has three weeks of float. The joiner reads that, sensibly, as three weeks of room. Then the steel comes late by ten days, and at the next progress meeting the joiner is told his three weeks are now four days — although his own work has not slipped by an hour and nothing about his task has changed.

He is entitled to feel robbed. The float was written against his line on the bar chart. So whose was it?

Begin by asking what the number was actually computed from. Float is not a property anybody assigns to a task. It comes out of the network: run the whole logic forwards from the start to get the earliest each task can begin, run it backwards from the completion date to get the latest each can begin without pushing that date, and the gap between those two answers is the float.

Notice what that calculation touches. The backward pass comes from the end date, through every task downstream. The forward pass comes from the start, through every task upstream. So the number on the joiner's bar was never computed from anything about joinery. It was computed from the whole chain his task sits on.

Now do the arithmetic on the chain, because this is the step that resolves the puzzle. Take a path with four tasks running into a fixed milestone. The path has a certain total duration; the milestone is a certain distance away. The difference between them is a single quantity — how much the path as a whole can stretch before it starts pushing the date.

That quantity belongs to the path, not to any task on it. The bar chart shows it drawn against each task in turn, which makes it look as though each task has its own allowance. But it is the same allowance, displayed several times. There is one pot, and the four tasks are all looking at it.

So follow through what happens when the steel takes ten extra days. Nothing has been created or destroyed elsewhere; the milestone has not moved and the remaining tasks have not changed length. The path simply got ten days longer, so the gap between the path and the milestone got ten days smaller. Every downstream task's displayed float falls by ten days at once — not because their situations changed, but because they were all reading the same number, and the number went down.

That is why it feels like theft and is better described as a conservation law. The slack on a path is a conserved pool, drawn down by whoever consumes it first, and consumption is silent because nobody has to ask. The joiner's three weeks were never his; they were the path's three weeks, and the steelworker spent them.

Two consequences fall straight out. First, float goes to whoever is early in the sequence, regardless of who needs it — position, not merit, decides. Second, when the pool reaches zero the path has become critical, which is not a change of status so much as the arithmetic result of the pool running out. A path can turn critical without anyone doing anything wrong on it.

The vocabulary marks the distinction, incidentally. What the joiner thought he had is free float — delay he can absorb without disturbing the very next task, and that genuinely is his. What was written on the chart is total float, the shared pool measured against the end date. Free float is usually much the smaller of the two, and often zero.

Three refinements, and one common error.

The error first: reading a float figure as a permission. "You have three weeks" is a statement about the network at the moment the calculation ran, not an allocation to a party. It is a snapshot of a shared balance, and it is stale the moment anybody upstream slips.

Now the refinements. First, tasks on different paths do not share a pool — the conservation holds within a path, not across the project. Two chains running in parallel into the same milestone each have their own slack, which is why a delay in the electrics can leave the drainage untouched while gutting everything behind the electrics.

Second, the pools merge and split at the joins. Where two paths converge, the downstream tasks are governed by the tighter of the two, so a task can sit on a path with plenty of room and still have very little of its own, because it also sits downstream of a tight one. This is exactly where intuition fails on a real programme, and it is why arguing about float from the bar chart rather than from the logic is unreliable.

Third, this is why float ownership is a contract question and not merely a planning one. Standard forms differ on whether float belongs to the contractor, the employer, or "the project" — and the disagreement exists precisely because the resource is shared and consumable. The arithmetic tells you the pool exists; it cannot tell you whose it is.

What would refute the account? If a delay upstream reduced the float of tasks that are not on its path, the shared-pool picture is wrong and something else — resource contention, most likely — is doing the work.

• Why standard contract forms disagree about who owns float, and how a time-impact analysis tries to settle it after the fact.
• What happens to this picture when the constraint is a shared crew rather than logic — resource levelling produces delays that no float calculation predicts.

Every term the collection defines is gathered in the glossary.