Who Owns Unused Time?

Featured image: Mikhail Nilov via Pexels.

On some construction projects, that is a surprisingly literal question.

Large construction and infrastructure projects are often scheduled using the Critical Path Method, which models the dependencies between activities and identifies which chain of work determines the project’s completion date.

Activities outside that critical path may have float: time they can slip without delaying the project as a whole.

But in some construction contracts, that unused time does not belong to the contractor performing the activity.

It belongs to the project.

The Los Angeles Bureau of Engineering, for example, explicitly treats float as a shared resource available to both the city and the contractor. Some design-build contracts use similar language.

That produces a different way of looking at a schedule.

Suppose a project has two parallel paths.

One takes 15 days:

Fabrication: 10 days → Assembly: 5 days

Another independent activity takes only 6 days.

That shorter activity has roughly nine days of float. It could finish nine days later without moving the project completion date.

The obvious interpretation is:

That task has nine extra days.

The project-level interpretation is:

The project has nine days of flexibility on that path.

Those sound almost identical, but they encourage very different behavior.

If the task simply expands to consume all nine days, nothing is technically late. The project still finishes on time.

But something valuable has disappeared.

That time could have absorbed an unexpected review, a delayed approval, unavailable equipment, a dependency that turned out to be more complicated than expected, or work elsewhere that suddenly became more important.

This is why project schedulers pay attention not only to whether an activity is late, but to how much float remains.

A task can be two weeks behind its original date and still pose little risk if it has substantial float.

Another task can be only one day late and threaten the entire project because it sits on the critical path.

The same lens changes how resources are allocated.

If a critical activity needs help, moving someone from a task with three weeks of float may make the overall project safer even though the second task now appears to be falling behind.

The goal is not to keep every activity perfectly aligned with its original dates.

The goal is to protect the project’s ability to finish.

That idea feels especially relevant in software development now.

Software teams do not usually manage day-to-day work like a major construction project. Agile methods deliberately allow more flexibility, and estimates often evolve as the work becomes better understood.

But many software projects still have real milestones: client demonstrations, contracted feature deliveries, certification dates, launches, or payments tied to specific outcomes.

AI is also changing how long some kinds of work take. Tasks that historically required several days may suddenly take hours, while other tasks remain just as difficult as before. That makes historical estimates less reliable in both directions.

When a task finishes unexpectedly early, it is tempting to treat the reclaimed time as extra capacity belonging to that task or team.

The construction-scheduling lens suggests another possibility:

The project may have just gained float.

That time could remain available for integration, testing, review, an unexpectedly difficult dependency, or simply protecting a milestone whose estimate was less accurate than expected.

Float is not automatically permission for a task to take longer. It is flexibility available to the project.

Sources and further reading

Los Angeles Bureau of Engineering, Construction Schedule Control

Texas Department of Transportation, SH 288 Toll Lanes Project Comprehensive Development Agreement

NASA, Schedule Management Overview

DORA, Balancing AI tensions: Moving from AI adoption to effective SDLC use