Open a schedule, sort by total float descending, and watch what happens to the room.
Somebody will say it out loud: "we've got 80 days of float on that, we're fine." And everyone relaxes a little. That's the moment the schedule starts lying to you.
Because here's the thing about total float: it is not a measurement of how much time you have. It's a measurement of how much logic you wrote. Those are very different, and confusing them is one of the most expensive habits in construction scheduling.
Where high float actually comes from
An activity gets high float for one of two reasons.
The real one
The work genuinely sits off the critical path, it's fully tied into the network on both ends, and the slack is a true buffer. This happens, and it's fine.
The common one
The activity has a predecessor but no successor — or a successor that's some generic milestone forty weeks out instead of the thing that actually waits on it.
In that second case, nothing downstream is holding the activity accountable, so P6 does exactly what you told it to do and hands it a huge number.
The test that settles it
Take your highest-float activity and ask a foreman a simple question:
If this finishes two months late, what stops?
| "Nothing, honestly" | Good — the float is real. |
| "We couldn't energize" | You just found a missing relationship. The float was never there. |
| "The inspection would move" | Same thing. The schedule didn't know about the dependency. |
Nine times out of ten in a schedule nobody has audited, it's the second answer.
Why this shows up in a claim
This is where it stops being academic.
In a delay claim, float ownership gets argued hard. If your schedule shows an activity carrying 60 days of float, the other side will use that number against you — that delay was absorbed, no impact, no entitlement. Try explaining afterward that the float was an artifact of a missing successor. You can be technically right and still lose the argument, because the schedule you submitted said otherwise.
The DCMA 14-point check flags this for a reason. Its high-float threshold — activities carrying more than 44 working days — isn't there because 45 days of slack is dangerous. It's there because a pile of activities carrying that much float is a symptom of open logic.
What to do about it, in order
-
Start with the open ends
Anything missing a successor gets one, or gets a written reason why it doesn't need one. That single pass usually collapses half the high-float population on its own.
-
Then look at what's left
Activities still showing large float after the logic is closed are worth a second look at the successor you chose. "Ties to substantial completion" is not a relationship. It's a placeholder someone left in.
-
Last, look at the shape
If most of your near-critical work is bunched inside a narrow band of float, you don't have one critical path — you have five that haven't declared themselves yet. One bad week and they all go critical together.
That last failure mode is the one that surprises teams, and it never shows up in a single float number.
The short version
High float should make you suspicious, not comfortable. Before you spend it, prove it's real.
See where your float actually is
Grupo AE — Schedule Intelligence reads your Primavera P6 (.xer) file and shows you the float distribution, the open-logic activities driving it, the full DCMA 14-point result, and CPLI and BEI — plus a Float Path Analysis that shows how bunched your near-critical paths really are.