Float-Slack Example
Example: Small Construction Project
Imagine this simplified programme:
Activity | Duration | Predecessor | Early Start | Early Finish | Total Float |
A. Site Preparation | 5 days | — | Day 1 | Day 5 | 0 |
B. Excavation | 5 days | A | Day 6 | Day 10 | 0 |
C. Order Steel | 3 days | A | Day 6 | Day 8 | 2 days |
D. Foundations | 5 days | B & C | Day 11 | Day 15 | 0 |
E. Structural Steel | 5 days | D | Day 16 | Day 20 | 0 |
F. Roofing | 5 days | E | Day 21 | Day 25 | 0 |
The important point is Activity C – Order Steel.
It finishes on Day 8, but Foundations cannot start until Day 11 because Excavation doesn’t finish until Day 10.
So C has some flexibility.
What happens if C is delayed?
Suppose the steel order is delayed by 2 days:
Original:
Order Steel: Day 6–8
Revised:
Order Steel: Day 8–10
Foundations can still start on Day 11.
Therefore, the project has not been delayed.
The two days of float have been consumed.
Now imagine the contractor delays it by 4 days
Order Steel becomes:
Day 10–12
Foundations cannot start on Day 11.
The delay has now moved onto the critical path and potentially delays the project by one day.
So we can illustrate it like this:
Available float: 2 days
→ Contractor uses 1 day
→ 1 day float remaining
→ Contractor uses another day
→ 0 days float remaining
→ Contractor uses another 2 days
→ Project delay begins
Now comes the interesting question: Who owns the 2 days?
Suppose the contractor says:
“Activity C has two days of float, so those two days belong to us.”
That isn’t necessarily correct.
The two days exist because of the relationship between the activities in the overall project network.
The float isn’t necessarily a two-day entitlement belonging to the contractor.
Now imagine the client causes a one-day delay to Excavation.
Excavation now finishes on Day 11 instead of Day 10.
The contractor’s steel order hasn’t changed.
But the available float on the steel order may effectively disappear because the successor activity has moved.
This demonstrates why saying “the contractor owns the float” can be misleading.
A better way to describe it
Think of float as:
Time available within the project schedule before a delay affects another activity or the project completion date.
It is a schedule resource, not automatically someone’s property.
An even better construction example
Consider a project where:
Excavation → Foundations → Structural Steel
and separately:
Shop Drawings → Structural Steel
Suppose the programme gives the Shop Drawings activity 10 days of float.
The contractor delays the drawings by 6 days.
No problem — Structural Steel can still start on time.
But then the client issues a variation that requires 5 additional days of drawing work.
Now the 10-day float has effectively been consumed by the combined effects of the delays.
This is where arguments can arise over who caused the delay, who was entitled to use the float, and whether an Extension of Time is due.
That is why, for serious construction projects, you shouldn’t look at float in isolation. You need to examine the baseline programme, updates, critical path, logic, actual progress and the causes and timing of delays.
The key lesson for your article
I’d actually add a highlighted box like this:
FLOAT IS NOT FREE TIME.
Float is flexibility within the project schedule. It does not automatically belong to the contractor simply because it appears against one of the contractor’s activities. The contract and the circumstances of the delay determine how float should be treated.
Here’s a clean visual network diagram of the example, showing the critical path and the 2 days of float on the steel-order activity.
The key point to show beneath the graphic: Activity C can move within those 2 days without delaying the project. But those 2 days are not automatically the contractor’s property—they are flexibility created by the overall schedule network.