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.

 
Give feedback

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.