What Is Float (Slack) in Project Planning — and Who Owns It?

Float, also called slack, is one of the most important concepts in project planning and scheduling. It tells us how much an activity can be delayed before it affects another activity, a milestone, or the overall project completion date.

But there is another question that often causes confusion:

Who owns the float?

The answer is not always as simple as it appears.

What Is Float?

In simple terms, float is the amount of time an activity can be delayed without causing a defined consequence elsewhere in the project schedule.

For example, suppose an activity is scheduled to start on Monday and finish on Friday, but the successor activity does not need to start until the following Wednesday.

The activity has 3 working days of float.

If the activity is delayed by two days, the successor can still start on time.

If the activity is delayed beyond its available float, it may begin to affect subsequent activities or the project completion date.

Total Float

Total Float is the amount of time an activity can be delayed without delaying the planned project completion date.

An activity with:

• 0 days float — is critical to the current schedule
• 5 days float — can potentially be delayed by 5 days without delaying project completion
• 20 days float — has considerably more scheduling flexibility

Activities with zero or very little total float are normally closely monitored because delays can quickly affect the project completion date.

What Is Free Float?

Free Float is slightly different.

Free float is the amount of time an activity can be delayed without delaying the early start of its immediate successor activity.

This distinction is important.

An activity might have 10 days of total float but only 3 days of free float.

That means the activity could move by 3 days without affecting its successor, but moving it further may consume float elsewhere in the network.

So, Who Owns the Float?

This is where things become interesting.

From a pure scheduling perspective, float is generally a property of the project schedule and the logic between activities. It isn’t automatically “owned” by the contractor who happens to have an activity with float.

For example, imagine this simplified sequence:

Excavation → Foundations → Structural Steel → Roofing

If excavation has five days of total float, that does not necessarily mean the excavation contractor has five days that they can simply use whenever they want.

That float exists because of the relationships and constraints within the overall project schedule.

If another activity also needs to use that time, consuming the float may affect the overall schedule.

Contractor-Owned Float vs Project Float

This is why the question of float ownership can become contentious in construction contracts.

There are generally three concepts worth considering:

1. Project Float

Under a project float approach, the float belongs to the project as a whole.

The contractor, client, or another party may use available float provided that doing so does not create a delay to the contractual completion date.

This approach encourages the project team to manage float as a shared scheduling resource.

2. Contractor-Owned Float

Some contracts or scheduling philosophies treat float as belonging to the contractor.

Under this approach, the contractor may have greater discretion over how available float is used, subject to the contract conditions.

However, this should not be assumed simply because the contractor prepared the schedule.

3. First-Come, First-Served Float

Another approach is sometimes described as whoever uses the float first.

For example, if a contractor delays an activity by three days and consumes three days of available float, another party may subsequently have less float available.

This can create disputes if the contract does not clearly establish how float is to be treated.

The Important Point: Check the Contract

There is no universal answer that float always belongs to the contractor or always belongs to the client.

The contract, specifications and scheduling requirements should be examined carefully.

The contract may contain provisions dealing with:

• Total Float
• Free Float
• Critical Path
• Extension of Time
• Concurrent Delay
• Contractor delays
• Principal/client delays
• Changes and variations
• Time bars and notification requirements
• Baseline programmes
• Updated programmes
• Recovery programmes

These contractual provisions can be more important than the terminology used in the scheduling software.

What Happens When Someone Uses the Float?

Consider this example.

The project has a contractual completion date of 30 November.

An activity has 7 days of total float.

The contractor delays the activity by 5 days.

At this point, the project completion date has not moved.

The contractor might argue:

“We have 7 days of float, so the project is not delayed.”

From a scheduling perspective, that may be correct.

However, the situation changes if the client subsequently causes a delay that also needs to consume those same seven days of float.

This is where delay analysis and float ownership become particularly important.

Why the Critical Path Matters

Float is closely associated with the Critical Path Method (CPM).

The critical path is generally the longest path through the schedule and determines the shortest calculated project duration.

Activities on the critical path typically have zero total float.

However, it is important to remember that the critical path can change during a project.

An activity that has 10 days of float today may have zero float several weeks later because of delays, changes, logic changes or progress.

This is why a project scheduler should not simply identify the critical path once at the beginning of the project and forget about it.

The critical path should be monitored throughout the project.

Float Is Not “Free Time”

One of the biggest mistakes I see in project scheduling is treating float as spare time that belongs to whoever has it.

Float is better understood as schedule flexibility.

Using that flexibility may be perfectly legitimate, but once it is consumed, it is gone.

For example:

Original float: 10 days

Contractor delay: 4 days

Remaining float: 6 days

If another delay then consumes 6 days:

Remaining float: 0 days

The next delay may now affect the project completion date.

A Simple Way to Think About Float

Think of float like a buffer in the project schedule.

If you have a five-day buffer, you have some flexibility.

But that does not necessarily mean someone has five days of entitlement to delay their work.

The key questions are:

What does the contract say?

What does the approved programme show?

What caused the delay?

When did the delay occur?

What was the critical path at the time?

Was the delay concurrent with another delay?

These questions become particularly important when assessing Extension of Time (EOT) claims.

Float in Microsoft Project and Primavera P6

Both Microsoft Project and Primavera P6 calculate and display float based on the schedule network, relationships, calendars, constraints and other scheduling parameters.

However, the number displayed as “Total Slack” or “Total Float” should not automatically be interpreted as a contractual entitlement.

The software is calculating a scheduling result.

The contract determines the contractual rights and obligations.

This distinction is extremely important when using scheduling software for construction claims or delay analysis.

Final Takeaway

Float is an essential part of effective project planning.

It provides information about the flexibility within the schedule and helps project managers and planners identify activities that are becoming increasingly critical.

But float is not automatically owned by the contractor, the client, or any particular party simply because it appears against their activities.

The treatment of float should be determined by the contractual arrangements, scheduling methodology and circumstances of the project.

For construction projects, understanding float properly can make the difference between simply producing a programme and actually using the programme as an effective project management and delay-analysis tool.

Good scheduling isn’t just about knowing when an activity finishes. It’s about understanding what happens when it doesn’t.