Float Is Not Free: The Delay That Happens Long Before the Date Moves

Ask a project manager when the delay started and they'll tell you the month the completion date moved.

They'll be wrong, usually by a long way. By the time a completion date slips, the delay is old news. It has been happening quietly for weeks or months, on a path nobody was watching, in a number nobody was reporting. The date moving isn't the delay. It's the funeral.

The number they weren't watching is float. And of all the things I've seen mismanaged on projects, float is the one that costs the most while attracting the least attention — because it disappears without setting off a single alarm.

What float actually is

Total float is the amount of time an activity can slip without pushing out the project completion date. Zero float means critical: slip and the end date moves with you. Twenty days of float means twenty days of slack before anyone notices.

That's the textbook. Here's the part the textbook underplays.

Float is not slack. Float is a buffer against uncertainty that hasn't happened yet. It's the reason a bad week in July doesn't become a claim in December. It absorbs your under-resourced fortnight, your late delivery, your rework, your mistakes. It is, in the most literal sense, an insurance policy against your own future.

Which makes the next question the only one that matters: whose insurance is it?

Who owns the float

This is where scheduling stops being a planning question and becomes a contract question — and it's why this belongs to project managers, not just planners.

Broadly there are four positions. The float belongs to the contractor, because it's his programme and he built it. It belongs to the employer, who paid for the works. It's shared and apportioned somehow. Or — the most common position, and the one most likely to apply to you — the float belongs to the project, and it goes to whoever needs it first. First come, first served.

The FIDIC standard forms are largely silent on this. Particular Conditions sometimes add a float clause; more often nobody thinks about it until it's contested. The SCL Delay and Disruption Protocol takes the "project owns it" line: where there is remaining total float on the affected path at the time of an Employer Risk Event, an extension of time should only be granted to the extent the delay is predicted to push that float below zero.

Read that again slowly, because it's doing something brutal.

An employer delay that consumes your float but doesn't move the completion date entitles you to nothing. No EOT. Nothing to claim. The event was real, it was at the employer's risk, it caused genuine harm — and the contractual answer is that you had a buffer, the buffer absorbed it, and there is no harm to compensate.

The trap

Now follow the consequence, because this is the part that gets missed.

March. An employer-risk event — late access, a slow approval, whatever it is — eats fifteen days of float on a path that had twenty-five. The completion date doesn't move. Nobody claims. Nobody notices. The monthly report says the project is on programme, and the monthly report is correct.

August. Something goes wrong that is squarely the contractor's fault. Under-resourced crew, a rework, a subcontractor failure. It costs ten days on the same path.

In a project that still had its twenty-five days, that ten-day slip is a non-event. The buffer absorbs it. Nobody outside the site team ever hears about it.

But the buffer is gone. So the ten days go straight through to the completion date, and the contractor is now in culpable delay, exposed to liquidated damages for every one of them.

Think about what just happened. The contractor paid for the employer's March delay with his own insurance policy, received nothing for it, and then paid a second time in August for a delay that would otherwise have cost him nothing at all.

Two payments. One invisible, one very expensive. And the first one is what caused the second.

This is the mechanism by which projects that were "fine all year" arrive at the last quarter suddenly, inexplicably late. Nothing dramatic happened in the last quarter. The last quarter is simply where a year of quiet float erosion finally surfaced.

Why nobody sees it

Because nobody reports it.

Look at a standard monthly progress report. Percent complete. Earned value, if you're lucky. Milestone dates. Forecast completion. Every one of those numbers is a lagging indicator — they only move after the damage is done and irreversible.

Float is the leading indicator, and it's almost never on the page.

If your report showed that the longest path had twenty-five days of float in January, nineteen in February, twelve in March and four in April, everyone in the room would understand the project's trajectory instantly. You wouldn't need a delay analyst. You wouldn't need an argument. You'd need a decision, and you'd have three months in which to take it.

Instead the report says "on programme" every month, right up to the month it says "eight weeks late." Both statements are true. Neither was useful.

There's a second reason it goes unseen, and it's less comfortable. Some contractors deliberately hide float — burying it inside inflated activity durations rather than showing it as float, on the theory that visible float is float the employer will try to take.

I understand the instinct and I think it's a serious mistake. Concealed float is indefensible if it's ever discovered, and it does something worse than that: it corrupts your own management data. You can't manage a buffer you've hidden from yourself. You end up with a programme that lies to the employer and to you, and only one of you is trying to build something with it.

The record problem

Here's where this connects to everything else.

The March event — the one that ate fifteen days of float — generated no claim, because no claim was available. So on most projects it generated no document either. No notice, no record, no assessment. Nothing happened, contractually speaking, so nothing was written down.

Now it's December. You're in a dispute. You want to explain that the reason you had no buffer in August is that the employer consumed it in March. You want to argue concurrency, or apportionment, or simply fairness.

And there is nothing. No contemporary record of the March event, its effect on float, or the fact that you flagged it at the time. You're reconstructing it from a programme comparison, nine months after the fact, against an employer's team who will point out — correctly — that you said nothing at the time because you knew there was nothing to say.

Readers who've followed my other articles will recognise this shape. It's the same failure that kills FIDIC claims and the same one that fails quality audits: the record you need on the bad day has to be created on the ordinary day, by someone who has no idea the bad day is coming.

March was an ordinary day. Nothing was wrong. The completion date hadn't moved. That was precisely the day the project was lost.

What to actually do

Report float. Every month, without exception. Not just the completion date. The total float on the longest path, and on every near-critical path — everything under about fifteen days, though set the threshold to suit the job. Show it as a trend, not a snapshot. A single float figure is noise; four months of float figures is a story.

Track the erosion rate. If you're burning two days of float a week on a path with twenty days left, you have ten weeks. That's not a scheduling observation, it's a management deadline. Someone should be making a decision about it now, not in ten weeks.

Notice float consumption even when no claim exists. This is the discipline that separates people who win claims from people who deserve to. When an employer-risk event consumes float without moving completion, write to the Engineer anyway. Not a claim — you may not have one. An early warning, recording the event, its effect on float, and your reservation of position. FIDIC's programme clause has an early-warning obligation sitting right at the end of it, and this is exactly what it's for. It costs ten minutes and it converts an invisible event into a documented one.

Fix float ownership at contract stage. This is where the game is actually won or lost, and it's won by whoever thought about it before signature. If float ownership matters to your risk profile — and it does — it belongs in the Particular Conditions, negotiated, in writing, before anyone is arguing about it. Afterwards it's just two positions and no answer.

Don't hide it. Show the float. Manage the float. Defend the float openly, on the record, as an asset you're entitled to manage. That's a position you can hold. Concealment isn't.

Watch the critical path move. Float erosion doesn't just shrink the buffer — it promotes paths. The path that was comfortably non-critical in February can be the longest path by June, and teams keep watching the one they were told about at kick-off. Re-check which path is actually longest every single month.

The reframe

Most people manage the completion date. It's the number the client asks about, the number on the report, the number everyone can understand.

But the completion date is an output. By the time it moves, every decision that moved it has already been taken, and taken by people who didn't know they were taking it.

Float is the input. It's where the project is actually being won or lost, in increments small enough that nobody escalates any of them.

So the question at the monthly review shouldn't be are we still finishing on time? The programme will say yes, and the programme will be right, and it will keep being right until the month it isn't.

The question is: how much buffer did we have last month, how much do we have now, and who took the difference?

Ask that one for four months running and you'll see the delay coming while there's still time to do something about it. Ask the other one and you'll find out on the day it's too late — which is, I'd guess, roughly when you found out last time.