Construction Claims
The SCL Protocol, in Practice · Part 4 of 24
The Critical Path: Where Time Really Lives
The critical path is the sequence that actually determines your completion date — the longest path through the logic, carrying the least float. Delay to it delays the job; delay to anything with float doesn't, until the float runs out. And 'critical' isn't a badge the software hands out — it's the path currently driving the finish, and it can move.
The critical path is the sequence of activities that actually determines your completion date — the longest path through the logic. Delay to it delays the job; delay to anything with float doesn’t, until the float runs out. “Critical” isn’t a badge your software hands out — it’s the path currently driving the finish, and it can move as the works progress.
The construction-site version
Two work streams heading for the same finish. Structure → MEP → finishes on one side; the façade package on the other. The façade could slip a week and nobody blinks — it has slack. The structure line can’t slip a day without the whole job moving. Same site, two very different consequences for the same “one week late,” because one path drives completion and the other doesn’t.
Miss that distinction and you’ll spend meetings fighting over delays that never mattered while quietly ignoring the one that did. The whole discipline of delay analysis is knowing, at any moment, which path is actually driving the finish.
The technical bit
The critical path is the longest continuous chain of logically-linked activities from the data date (or start) to completion; it carries the least total float, often zero. Float is how much an activity can slip before it affects a successor or the completion date. Activities off the critical path carry float, so delay to them is absorbed — until the float is exhausted, at which point that path can itself become critical.
Two features good practice keeps stressing. First, criticality is dynamic: the critical path can shift window to window as progress and events reshape the logic — it is not fixed for the life of the job. Second, near-critical paths matter: a path with only a few days’ float is where tomorrow’s critical path is hiding, because a modest delay can flip it critical. The Protocol assesses the effect of a delay event on completion by reference to the critical path (Core Principle 6), and that is inseparable from having a properly prepared, logic-linked programme and good records (Core Principle 1). Because criticality changes over time, the Protocol’s methods look at the contemporaneous programme window by window, not a single snapshot.
”It’s marked critical in P6, so a delay to it delays the job.”
Software criticality reflects the logic, constraints and settings in the file — which may not match the true path to the contractual completion milestone. Criticality has to be demonstrated, not read off a colour.
Check total float, and whether “critical” is defined as the longest path or by a total-float threshold. Hunt for constraints (mandatory / finish-on) that distort float; watch multiple calendars and open ends that fragment the path; and confirm the data date, so you’re reading the critical path as it stood when the event occurred — not as it looks today. The mechanics are in the P6 critical-path guide.
Evidence check
An accepted baseline with intact logic; the contemporaneous updated programme for the relevant window; records showing which path was actually driving completion when the event hit; and the basis for any constraint that affects criticality. Relevance always depends on the facts and the contract.
Rishi’s takeaway
- The critical path is the path that drives your completion date — longest path, least float.
- Delay to a floated activity buys no EOT until the float is gone.
- Criticality is dynamic — it moves as the job progresses and events reshape the logic.
- ”Critical in the software” ≠ “critical to the contractual completion milestone.” Prove it.
- Watch the near-critical paths; that’s where the next critical path is hiding.
Delay only counts when it lands on the path that’s actually driving the finish — and that path can move.
References. Society of Construction Law, Delay and Disruption Protocol, 2nd Edition, February 2017 — Core Principle 1 (programme and records); Core Principle 6 (effect of delay assessed on the critical path); Appendix A (definitions of critical path and float). Criticality, float and the treatment of concurrent or near-critical paths depend on the facts and the contract. Educational commentary; not legal advice.
Common questions
What is the critical path in construction?
The longest continuous chain of logically-linked activities driving the completion date, carrying the least total float — often zero. Delay to it delays the job; delay to activities with float is absorbed until that float runs out.
Is an activity marked critical in P6 always critical to completion?
No. Software criticality reflects the logic, constraints and settings in the file, which may not match the true path to the contractual completion milestone. Criticality has to be demonstrated, not read off a colour.
Does delay to any activity entitle you to time?
No. Only delay to the current critical path affects completion. A delayed activity with float buys no extension of time until its float is exhausted.
Can the critical path change during a project?
Yes. Criticality is dynamic — the critical path can shift window to window as progress and events reshape the logic. It is not fixed for the life of the job, which is why analysis looks at the contemporaneous programme.
What is a near-critical path?
A path carrying only a few days' float. It matters because a modest delay can flip it critical — it is where the next critical path is often hiding.
Related