Critical Path Method in Construction: How to Identify, Validate and Monitor the Critical Path

The Empire State Building was completed in 1931, under budget and ahead of programme. The schedule was so tight that steel deliveries arrived by horse-drawn cart, were hoisted into place the same day, and the rivets were still cooling when the next column went up. Every activity on that project was critical. There was no float. No wiggle room. Every delay would have pushed out the completion date. That’s the critical path in its purest form: the longest sequence of dependent activities that determines the project’s earliest possible finish.

Most construction projects aren’t the Empire State Building. But the principle is the same. If you don’t know which activities are on the critical path, you can’t manage time risk. You can’t assess delay claims. You can’t make informed decisions about where to focus resources. The critical path method (CPM) is the foundation of every credible construction programme, and understanding it isn’t optional for anyone who reviews, approves, or challenges schedules. CPM is also the technical backbone of a complete construction schedule analysis, so the same principles cover both planning and forensic review.

What Is the Critical Path Method in Construction?

The critical path method is a network-based scheduling technique that identifies the longest sequence of dependent activities through a project. Activities on this sequence have zero total float, meaning any delay to any one of them delays the project completion date. The critical path tells you the minimum time needed to complete the project and which activities you cannot afford to delay.

CPM was developed in the late 1950s by the DuPont Corporation and Remington Rand, originally for chemical plant maintenance scheduling. It was quickly adopted in construction because it solves a problem that every project faces: with hundreds or thousands of activities, which ones actually matter for the completion date?

The answer is: the ones on the critical path. Everything else, by definition, has float.

Callout box: The critical path is the longest path through the project network. It’s not the path with the most activities, or the most expensive activities, or the activities that look like they should be important. It’s the path with the longest total duration when you add up all the activity durations and logic links.

Key CPM Terms

How the Critical Path Method Works: Forward and Backward Pass

CPM calculates the critical path through two passes through the activity network. The forward pass works from start to finish, calculating the earliest possible dates. The backward pass works from finish to start, calculating the latest permissible dates. The difference between the two is float.

The Forward Pass

Starting from the project’s first activity (or activities), the forward pass calculates the Early Start and Early Finish for every activity:

• ES of the first activity = the project start date (typically day 0 or the data date)
• EF = ES + duration
• For subsequent activities, ES = the maximum EF of all predecessor activities

Worked example with a simple three-activity sequence:

The forward pass tells us the earliest the project can finish is day 23.

The Backward Pass

Starting from the project’s last activity and working backwards, the backward pass calculates the Late Start and Late Finish:

• LF of the last activity = its EF (for an on-time project) or the contractual completion date
• LS = LF minus duration
• For preceding activities, LF = the minimum LS of all successor activities

Every activity has zero float. This is a simple critical path: A-B-C.

Now add a parallel path. Activity D takes 6 days, starts after A, and precedes C:

Activity D has four days of float. It can slip by up to four days without delaying the project. The critical path remains A-B-C. But D is near-critical; if it slips by five days, it joins the critical path.

How to Identify the Critical Path in Primavera P6

In Oracle Primavera P6, the critical path is identified automatically when the schedule is calculated (F9). Activities with zero or negative total float are flagged as critical. Here’s how to find it:

1. Apply the critical path filter. In the activities view, filter for activities where Total Float is less than or equal to zero. This shows only critical activities.
2. Review the Gantt chart. Critical activities are typically highlighted in red. Trace the longest continuous chain of red bars from the data date to project completion.
3. Check the activity network. P6’s network diagram view shows the logic relationships between activities. Following the longest path through this network confirms the critical path.
4. Watch for multiple critical paths. If your schedule shows more than one continuous chain of zero-float activities, you have multiple critical paths. This usually indicates an unstable schedule with very little flexibility.

Common Mistake: Constraints Masking the True Critical Path

Hard constraints (Must Finish On, Must Start On) override network logic. An activity with a hard constraint will show zero float regardless of its network position. If your schedule has many hard constraints, the software will flag them as critical even though they’re not on the true logic-driven critical path.

The Defense Contract Management Agency 14-Point Assessment, metric 5, flags schedules where hard constraints exceed 5% of total tasks. When you see a programme with a high constraint count, the critical path shown by P6 may not reflect the real project risk. Our deeper guide to the DCMA 14-Point Assessment walks through every metric and the threshold for each.

How to Validate the Critical Path

The software-calculated critical path is only as reliable as the schedule it’s based on. A critical path derived from a schedule with missing logic, excessive constraints, or unrealistic lags isn’t a real critical path. It’s a software output. Here’s how to validate it.

Check for Open Ends

Every activity except the project start and finish should have at least one predecessor and one successor. Open-end activities (no predecessor or no successor) break the network logic. The DCMA 14-Point Assessment, metric 1, requires that fewer than 5% of activities have open ends.

If a critical activity has no predecessor, the network logic doesn’t drive its start date. It could be constrained, or it could be a standalone task with an arbitrary start. Either way, it’s not part of a true logic-driven path.

Audit Hard Constraints

Hard constraints lock an activity to a specific date, overriding the network calculation. If a critical activity has a “Must Finish On” constraint, it shows zero float because of the constraint, not because of its logical position in the network.

In P6, check the Constraints tab in Activity Details. Count the number of hard constraints (MFO, MSO). More than a handful across a full programme is a warning sign.

Review High-Duration Activities

The DCMA 14-Point Assessment, metric 8, flags activities with durations exceeding 44 working days (two months). These are often summary-level placeholders that should be broken into more detailed activities. A 90-day “civil works” activity on the critical path is probably hiding a more detailed sequence that should be modelled separately.

Verify the Critical Path Makes Sense

Step back from the software and ask: does this critical path reflect how the project is actually being built? If the critical path runs through the landscaping package on a high-rise building project, something is wrong. The critical path should follow the dominant trade sequence. This sense-check is one of the core moves in our step-by-step guide on how to review a contractor programme.

What we found: When the displayed critical path runs through a non-structural trade package on a building project, the usual explanation is open-end activities and hard constraints distorting the network calculation, not a genuine logic-driven sequence. The DCMA 14-Point’s metric 1 caps missing-logic activities at five per cent of the total; metric 5 caps hard constraints at the same threshold. Above either threshold, the network is being told what to display rather than calculating it.

What it means: If the critical path doesn’t trace a believable construction sequence, the network is telling you the calculation has been overridden. Approving the programme on its face means accepting a schedule whose real time risk is hidden behind the constraints.

How the Critical Path Changes Between Schedule Updates

The critical path isn’t fixed. It shifts as work progresses, delays occur, and logic is updated. Tracking these shifts is one of the most important things you can do as a project controller or client-side reviewer.

Why the Critical Path Shifts

A critical path shift happens when a non-critical activity consumes its float and becomes critical. This can occur because:

• A non-critical activity is delayed beyond its float
• The project is re-sequenced (logic changes between updates)
• Durations are revised based on actual progress
• Constraints are added or removed

When the critical path shifts, the activities that matter for completion change. If you’re not monitoring these shifts, you could be focusing resources on the wrong work front.

What Critical Path Shifts Tell You

A programme where the critical path jumps between updates is a sign of instability. It suggests that either the original logic was incomplete, or the project is being re-sequenced on the fly. Both are risks.

A programme where the critical path is consistent across updates is more reliable. The construction logic is holding. The plan is being followed.

Near-Critical Path Monitoring

The near-critical path is any path with total float between one and 10 working days. These paths can become critical with minimal delay. On a well-managed project, near-critical paths get the same attention as the critical path because they’re one rain event, one late delivery, or one productivity dip away from driving the completion date. The mechanics of float, and the difference between total float and free float, determine when a near-critical path tips over.

Bent Flyvbjerg and Dan Gardner, in How Big Things Get Done, describe the pattern of projects that “think fast, act slow.” Boston’s Big Dig, the highway tunnel project through downtown Boston, took 16 years and tripled its budget. One of the core problems was that schedule risks that looked manageable individually compounded into critical path failures. Activities that weren’t critical at baseline became critical as the project progressed, and there was no systematic monitoring of near-critical paths. The result was a project that kept discovering new critical paths, each one pushing out the completion date.

Critical Path and Delay Analysis

Every delay analysis starts with the critical path. If a delay event doesn’t affect the critical path, it doesn’t delay the project. Period.

Why Delay Analysis Starts with the Critical Path

The SCL Delay and Disruption Protocol describes Time Impact Analysis at paragraph 4.12 (Core Principle 4) as the recommended methodology for contemporaneous assessment of EOT applications. The TIA process inserts the delay event into the Updated Programme and recalculates the predicted completion date. Note that the 2nd Edition (Introduction §K(c)) removed any expressed preference for TIA where the analysis is time-distant from the delay event. The TIA process inserts the delay event into the programme and measures the impact on the critical path.

If the contractor is claiming an EOT for a delay event, the first question is: did this event delay the critical path? If the answer is no, there’s no entitlement.

Determining if a Delay Event Impacted the Critical Path

For each delay event:

1. Identify the affected activity or activities
2. Determine whether those activities were on the critical path at the time of the event
3. If they weren’t critical, check the float values. Could the event have consumed enough float to make the path critical?
4. Verify against contemporaneous records: site diaries, progress reports, and correspondence should confirm the event and its timing
5. If using TIA, insert the delay event into the programme and re-schedule. Compare the new completion date to the original

As-Planned vs As-Built Critical Path

Comparing the as-planned critical path (from the baseline) to the as-built critical path (from the actual progress data) shows how the project’s time risk evolved. If the critical path shifted significantly from the baseline, the original plan may not have captured the real construction sequence.

This comparison is central to forensic schedule analysis. Per AACE International RP 29R-03, Section 3.1 (MIP 3.1, Observational/Static/Gross), the as-planned vs as-built analysis examines the difference between what was planned and what actually happened, tracing how the critical path changed over time.

Common Critical Path Problems in Construction Schedules

Artificially hidden critical path. Constraints mask the true critical path. A programme with 50 hard constraints might show 200 critical activities, but most of them are critical because of constraints, not logic. The actual logic-driven critical path is buried.

Multiple critical paths. When more than one continuous chain of zero-float activities exists, the schedule has very little float. Small delays push the project further behind with no buffer. It generally indicates that the schedule is overly compressed or the logic is incomplete.

Negative float on the critical path. Negative float means the schedule is already behind the contractual completion date. If the critical path shows negative five days of float, the project is running five days late. The DCMA 14-Point Assessment, metric 7, flags any negative float as a schedule quality concern (the pass threshold is 0%).

Resource-driven vs duration-driven critical path. Some schedules use resource levelling, which changes activity dates based on resource availability rather than pure logic. A resource-driven critical path may differ from the logic-driven critical path. Delay analysis should use the logic-driven path; resource allocation is a separate consideration.

Tools for Critical Path Analysis

Oracle Primavera P6 is the industry standard for CPM scheduling on construction projects. It calculates the critical path automatically and provides filtering, grouping, and display options to trace and monitor it.

Microsoft Project supports basic CPM but has more limited analysis features. It’s suitable for smaller projects but isn’t the preferred tool for difficult construction programmes or forensic schedule analysis.

ScheduleLens automates critical path validation: it checks for open ends, flags constraint abuse, tracks critical path shifts between updates, and monitors near-critical paths. Rather than manually auditing every programme update, ScheduleLens flags the specific issues that make the critical path unreliable so you can challenge the programme with evidence.

Standards and References

What to Do Next

Next time you receive a contractor’s programme, don’t just look at the completion date. Open the activity list, filter for the critical path, and check: does it make sense? Are there open ends? Are there hard constraints driving the zero-float activities? Is the near-critical path being monitored?

The critical path tells you where the project’s time risk is concentrated. But only if it’s real. Validate it before you rely on it.

This article is for educational purposes and does not constitute legal or professional advice. Always verify programme data against your project’s specific contractual requirements.