What CPM does — and what the textbook leaves out
Every project management textbook explains the Critical Path Method the same way. You build an activity network, you run a forward pass to find each activity's Early Start and Early Finish, you run a backward pass to find each activity's Late Start and Late Finish, and the activities where these dates match — zero total float — lie on the critical path. The path determines the earliest possible completion date. Worked examples involve four activities labelled A, B, C and D, durations of 5, 3, 7 and 2 days, and a critical path that runs A → C → D. That is the textbook.
On UK infrastructure, defence and nuclear programmes, none of this is wrong, but most of it is incomplete. A real Primavera P6 schedule has 8,000 to 30,000 activities, not four. The critical path runs through ten or fifteen near-critical alternatives that any single delay could pull onto the path. The deterministic CPM calculation ignores the merge-bias effect that almost always makes the probabilistic completion date later than the deterministic one. Software-imposed constraints distort the calculated float in ways the textbook does not anticipate. And the people reading the programme — a Project Manager assessing a Clause 32 revision under NEC4, a DCMA 14-point reviewer, an IPA gateway assessor — are asking questions that the textbook treatment does not equip the planner to answer.
This guide is for practitioners working on UK programmes who already know the forward and backward pass and need the parts the textbook leaves out: how near-critical paths matter as much as the headline critical path, how the deterministic critical path relates to the risk-adjusted critical path produced by QSRA, how CPM connects to the NEC4 contract machinery, the tool-specific gotchas in Primavera P6 and Asta Powerproject, and the failure modes that DCMA 14 was designed to flag.
Near-critical paths matter as much as the critical path
The single most important practitioner extension to textbook CPM is that activities with small amounts of positive float matter almost as much as activities with zero float. The textbook treats float as a binary: zero is critical, anything positive is not. The reality on a live programme is that an activity with three days of total float is critical in any meaningful sense — a normal delay will pull it onto the critical path within days. This is why the DCMA 14-point assessment, which is the de facto schedule-quality benchmark on UK defence and major infrastructure programmes, treats any activity with seven working days or less of total float as effectively critical for monitoring purposes.
The DCMA 14 threshold has a specific origin: empirical analysis of major US Department of Defense programmes showed that activities with low positive float consistently behaved like critical-path activities — small delays propagated to the project end date, and the operational signature of these activities matched the operational signature of zero-float work. The UK MoD and IPA-aligned programmes have adopted the same threshold because it stands up to empirical scrutiny. On programmes where the float-distribution check is failing — too many activities with low positive float, suggesting an artificially propped-up critical path — DCMA 14 flags it, and the planner needs to be ready with an answer.
In practice, this means a competent practitioner looks at three things when reviewing a critical path: the activities with zero total float (the textbook critical path), the activities with one to seven days of total float (the near-critical path under DCMA 14), and the cumulative distribution of float across the whole network. A schedule with 50 activities at zero float and another 300 within seven days of zero float has a critical path that is functionally a critical zone, not a critical line — and the planning narrative needs to reflect that.
Primavera P6 makes this analysis straightforward via the Activity table's Total Float column, sorted ascending and grouped by float band. Asta Powerproject's equivalent is the Float report. Either tool surfaces the float distribution in minutes; the discipline is to actually look at it, and to communicate it. A programme review that says "the critical path runs from groundworks through M&E commissioning to handover" without also saying "there are 240 near-critical activities within DCMA threshold, concentrated in the secondary fit-out phase" is missing where the actual schedule risk sits.
The deterministic critical path vs the risk-adjusted critical path
The deterministic critical path is a single path through the network produced by the CPM calculation on point-estimate durations. The risk-adjusted critical path — produced by a Monte Carlo Schedule Risk Analysis (QSRA) — is the answer to a different question: across many simulated runs of the programme, which path drives the project end date most often? The two are usually different, and the difference matters.
On a Monte Carlo run of a typical UK infrastructure programme, the deterministic critical path will be the most frequent driver of the project end date — but it will rarely drive completion in more than 60 to 70% of iterations. The remaining 30 to 40% of iterations are driven by paths that the deterministic calculation flagged as non-critical. The Criticality Index metric — the percentage of Monte Carlo iterations in which a given path drives the simulated project end date — gives the risk-adjusted view of where schedule sensitivity actually sits.
A practical example. A deterministic schedule shows the critical path running through the structural steel erection phase, with an electrical commissioning path running 14 days behind. The QSRA, run on three-point estimates that reflect the genuine uncertainty in each activity, produces a Criticality Index of 58% for the steel path and 31% for the electrical path. That 31% is the part the deterministic view ignored — and it is the part where focused risk mitigation work would have the largest expected effect on completion. Treating the deterministic critical path as the only thing worth managing means leaving 30%+ of schedule risk unaddressed. The practitioner who runs QSRA properly knows this; the planner who has only the deterministic view does not.
The relationship between deterministic and risk-adjusted criticality also explains the consistent finding that Monte Carlo P50 dates are later than deterministic completion dates — usually called the merge-bias effect. As multiple near-critical paths converge on completion, the probability that all of them finish on time is lower than the probability that any single one does. Deterministic CPM ignores this combined probability; Monte Carlo captures it. On programmes with many parallel workstreams converging on a single milestone (commissioning, handover, regulatory acceptance), the gap between deterministic and risk-adjusted completion can be material — three to six months on programmes of two to three years duration is not uncommon.
How NEC4 uses the critical path
On UK contracts written under NEC4 ECC, the critical path is not just a planning concept; it is contractually significant. The Accepted Programme under Clause 11.2(15) — the version of the Contractor's programme that the Project Manager has formally accepted — must show the critical path (and float on other activities) in a way that satisfies the contract's information requirements. A programme that does not show the critical path, or that shows it in a way the Project Manager cannot interrogate, is grounds for non-acceptance under Clause 31.3.
The critical path matters even more at compensation event assessment time under Clause 63. The time impact of a compensation event is assessed by inserting the additional work into the Accepted Programme, running the schedule logic, and showing what effect the insertion has on planned completion. The assessment depends on the Accepted Programme having a defensible critical path: an event that lands on the critical path drives planned completion immediately; an event that lands on a non-critical path consumes float without (initially) affecting completion. The line between these two outcomes is the critical path itself.
On programmes where the critical path is shifting between Accepted Programme revisions — a common pattern after several compensation events — the question of which path was critical at the time of the event becomes commercially important. Some adjudications turn on this question. The Contractor's position relies on a consistent, well-documented critical path that can be traced through the revision history; the Client's position relies on the same. Sloppy critical-path management is, in NEC4 terms, an avoidable source of dispute.
The Clause 32 revision cycle is what keeps the critical path current. Each revised programme submitted under Clause 32 shows the actual progress on every operation, the effect on remaining work, and the current critical path. The Project Manager's acceptance decision under Clause 31.3 turns in part on whether the critical path shown is plausible. A revised programme that shifts the critical path to a different sequence without a clear narrative explanation of why the previous path is no longer driving completion is the kind of submission a competent Project Manager would refuse to accept on the grounds that it does not represent the Contractor's plans realistically.
Primavera P6 and the critical path the tool actually shows you
The critical path Primavera P6 shows on the Gantt chart is the critical path according to the scheduling options set in the project — and those options have meaningful defaults that practitioners often do not check. The default critical-path definition in P6 is "longest path" — activities on the path with the longest total duration through the network, regardless of constraints. The alternative setting is "total float less than or equal to 0" (or another configurable threshold). On a programme with date constraints on intermediate milestones, these two settings can produce materially different critical paths.
Date constraints are the most common source of misleading critical paths in P6. An activity with a hard Finish-On constraint will report zero total float regardless of its true logical position in the network, because the constraint forces the late dates to equal the early dates. The resulting critical-path display includes the constrained activity as if it were a genuine driver of completion, when in reality it is a constraint imposed by the planner. A schedule with several hard-constrained intermediate milestones can produce a "critical path" that meanders through constrained activities and bears no relationship to the genuine longest-duration sequence.
DCMA 14 explicitly tests for this through the Hard Constraints metric (no more than 5% of activities with hard constraints) and the Critical Path Test (the critical path should run from project start to project completion without breaks, and the float on critical activities should be zero). A schedule that fails these tests usually has a critical-path narrative that is contaminated by constraint-driven artefacts. The practitioner discipline is to review every hard constraint in the schedule and ask whether it is genuinely required by the contract or by physical reality, or whether it has been added to make the schedule look acceptable. Many can and should be removed.
Asta Powerproject and Microsoft Project handle critical-path calculation similarly but with different default options and different terminology. The underlying mathematics is the same; the user-interface defaults differ. The discipline of checking the scheduling options before trusting the displayed critical path applies regardless of tool.
Common ways the critical path lies — and how to catch them
The critical path can mislead in several reliable ways, and a practitioner-quality programme review checks for each of them. The first is the multiple critical paths problem: two or more paths through the network with the same total duration, which P6 will display as critical without distinguishing between them. Multiple critical paths are commercially significant because they double the schedule risk — any slip on any of them delays the project — and DCMA 14 flags this as an Excessive Critical Path issue.
The second is the constraint-driven critical path described in the previous section: critical-path activities that are critical only because a hard constraint forces zero float, not because they are logically driving completion. The fix is to remove unnecessary constraints and re-run the schedule.
The third is dangling logic — activities with missing predecessors or successors that disconnect part of the network from the critical-path calculation. DCMA 14's Logic metric (no more than 5% of activities with missing predecessors or successors) catches this. A schedule with significant dangling logic produces a critical path that does not represent the full work; the planner needs to fix the logic before the path can be trusted.
The fourth is the artificially-extended critical path that runs through long-duration activities with overstated durations. Sometimes this is honest (the activity really does take 90 days); often it is the planner padding durations to create commercial protection. The check is to compare activity durations against historic benchmarks and against the durations of comparable activities elsewhere in the same programme. Outliers warrant explanation.
The fifth is the absent critical path — a schedule where the critical-path display does not run continuously from start to finish, with gaps or breaks driven by data integrity issues. This is the DCMA 14 Critical Path Test. A programme that fails it has a critical-path display that cannot be relied on for any practical purpose, and the underlying network needs work before the programme can be accepted under NEC4 or assessed against compensation events.
Putting it together
CPM is the foundation of UK programme management — at NEC4 acceptance, at DCMA 14 assessment, at QSRA simulation, at IPA gateway review. But the textbook treatment of CPM is not sufficient for any of those uses. A practitioner working on a UK infrastructure, defence or nuclear programme needs to know how the deterministic critical path relates to near-critical paths under DCMA, how it relates to the risk-adjusted criticality produced by Monte Carlo simulation, how NEC4 Clauses 31, 32 and 63 turn on the critical path being well-defined and well-maintained, how Primavera P6 and other tools can mislead, and how DCMA 14 catches the common ways the critical path can mislead.
The discipline that separates a good programme from a presentation programme is whether the critical-path narrative is genuine. A good programme has a critical path that traces logically from start to completion through activities that an experienced reviewer would expect to drive the project. The near-critical paths are visible and have been thought about. The constraints are necessary, not cosmetic. The QSRA criticality view has been compared to the deterministic view. And the critical-path activities are the ones the project team is actively managing, with daily attention from the planners and weekly attention from the project board.
SOMA provides programme assurance, CPM review, DCMA 14 assessment and QSRA delivery on UK infrastructure, defence and nuclear programmes — including the deterministic-to-risk-adjusted critical-path comparison that informs contingency setting at Initial Gate and Main Gate business cases, and the Clause 32 programme acceptance work that depends on a defensible critical path being maintained through every revision. The standard the work needs to meet is high; the practice that delivers to that standard is achievable when the right disciplines are applied.