What Clause 32 actually requires
Clause 32 of NEC4 ECC sits at the heart of the contract's programme management machinery. The Accepted Programme — the version of the Contractor's plan that the Project Manager has formally accepted under Clause 31 — is not a fixed document. It is the current best statement of the Contractor's intentions, and the contract expects it to be kept current through a continuous cycle of revision and acceptance. Clause 32 is the mechanism that drives that cycle.
Specifically, Clause 32.1 lists what each revised programme must show. The list is more demanding than many practitioners appreciate. Each revision shows the actual progress achieved on every operation that has started, the effect of that progress on the remaining work, the changes to the methods and resources the Contractor proposes to use, the current effects of every compensation event that has occurred, the effects of every early warning matter notified under Clause 15, and any other changes the Contractor proposes to make. A revision that fails to show any of these is not compliant with Clause 32.1 — and the Project Manager has grounds to refuse acceptance under Clause 31.3.
The content list matters because each item is doing analytical work. Actual progress establishes the data date and forces the schedule logic to be recalculated from real performance rather than from the original plan. The remaining-work impact shows the consequences of that progress for planned completion. The methods-and-resources update keeps the programme aligned with how the Contractor is actually executing the work, rather than how the tender team assumed it would be done. The compensation event effects make sure the time impacts of every CE that has occurred are visible in one place. The early-warning effects close the loop between Clause 15 notifications and the programme. And the Contractor's other proposed changes — sequencing, logic, additional risk allowances — give the Project Manager visibility on planning judgements that would otherwise stay inside the Contractor's scheduling office.
A revision that simply pushes dates out without explaining progress, methods or compensation event effects is not a Clause 32 revision; it is a re-presentation of the previous programme with a new completion date. The Project Manager should refuse to accept it under Clause 31.3(2) — the reason being that it does not show the information the contract requires.
When revisions happen — and the dangerous gap
Clause 32.2 sets out four triggers for revision. The Contractor submits a revised programme to the Project Manager for acceptance: at the intervals stated in Contract Data Part Two; within the period stated after the Project Manager instructs the Contractor to submit a revision; when the Contractor chooses to (within those intervals); and when a compensation event has occurred. Three of these triggers are predictable; the fourth — post-compensation-event revisions — is where most programmes drift out of date.
The interval in Contract Data Part Two is typically set at 4 to 8 weeks on infrastructure programmes. Some clients set it shorter (2 to 3 weeks on highly dynamic programmes); some set it longer (12 weeks on long-duration capital projects with stable scope). The interval is a floor, not a ceiling — nothing prevents the Contractor from submitting more frequently if useful, and the Project Manager's right to instruct a revision under Clause 32.2 is unconstrained by the stated interval. A common failure is for Contract Data Part Two to leave the interval blank, in which case there is no contractual revision frequency and the Accepted Programme can legally remain unchanged for the duration of the contract — a position no competent client should accept.
The dangerous gap appears after compensation events. The contract is unambiguous: a revised programme is submitted when a compensation event has occurred. In practice, many Contractors submit time impact analyses (TIAs) as part of compensation event quotations under Clause 62 but do not always update the Accepted Programme to reflect the time effects once the CE is implemented. The result is an Accepted Programme that no longer matches reality — completed CE work shows as planned future work, agreed extensions to planned completion are not reflected, and the next CE assessment under Clause 63 will be based on a programme that is materially out of date. NEC users' group commentary has flagged this drift as one of the principal sources of dispute on live NEC contracts.
The Project Manager's instruction power under Clause 32.2 is the antidote to drift. If the Accepted Programme is more than one cycle out of date, the Project Manager should instruct a fresh revision and require it within the period stated in Contract Data Part Two (typically two weeks). Tolerance of repeated late submissions effectively waives the contract's programme discipline, and the commercial consequences appear later in Clause 63 disputes over the basis of CE assessment.
The acceptance loop — and why silence is not acceptance
Once a revised programme is submitted, Clause 31.3 governs the acceptance process — the same provision that applies to the first programme. The Project Manager has two weeks (or the period stated in Contract Data Part Two) to either accept the revision or to notify the Contractor of non-acceptance, with one of the four contract-stated reasons in writing. The four reasons under Clause 31.3 are: that the Contractor's plans are not practicable; that the programme does not show the information the contract requires; that it does not represent the Contractor's plans realistically; or that it does not comply with the Works Information / Scope.
A reason for non-acceptance that does not fall within these four categories is not contract-valid. A Project Manager who refuses acceptance because, for example, the new planned completion date is later than the previous one, has not given a contract-valid reason. The Contractor can challenge the non-acceptance and, if necessary, refer the dispute to adjudication. Project Managers who use non-acceptance as a commercial lever rather than a quality control mechanism tend to find that this behaviour surfaces at adjudication and is judged unfavourably.
Silence is the most commercially dangerous response. NEC4 ECC was clarified to make it explicit that silence does not equal acceptance — the Project Manager must either accept or notify non-acceptance, and the absence of either keeps the previous Accepted Programme in force. This is the opposite of the position under some bespoke contract forms where the contractor relies on tacit acceptance. Under NEC4, a Project Manager who simply does not respond to a Clause 32 submission has left the Accepted Programme unchanged — and a subsequent compensation event will be assessed against the stale programme, which usually disadvantages the client because the stale programme does not reflect the current state of the works.
The practical implication for Project Managers is procedural discipline. Every Clause 32 submission requires a substantive response within two weeks — either an acceptance, or a non-acceptance with a contract-valid reason and (ideally) a clear statement of what the Contractor would need to change to make the next submission acceptable. Project Managers who treat programme acceptance as an administrative chore rather than an active contract management responsibility create the commercial exposure that surfaces later in Clause 63 disputes.
Common failure modes — and the cost at Clause 63 quantum
Five failure modes recur on live NEC4 contracts, and all of them hurt at the point where compensation events are quantified under Clause 63. The first is late submission by the Contractor — revisions that do not arrive within the stated interval, or that arrive only when a CE is being assessed. The pattern weakens the Contractor's position because the programme being relied on at CE time is, by definition, not current.
The second is incomplete submissions that fail Clause 32.1. A revision that shows updated dates but does not show actual progress, methods and resources changes, or the effects of preceding CEs, is not a compliant revision. The Project Manager can refuse acceptance under Clause 31.3(2). The Contractor who submits a thin revision and waits to see whether it is accepted is taking the risk that the previous (stale) Accepted Programme remains the reference document for the next CE quantum assessment.
The third is Project Manager silence — Clause 32 submissions that receive no formal response within two weeks. As noted above, silence keeps the previous Accepted Programme in force. The cumulative effect of repeated silence is an Accepted Programme that may be six or twelve months out of date by the time a significant CE arises, with consequences for both parties: the Contractor cannot rely on the programme to support its TIA, and the Client cannot rely on it to constrain the TIA the Contractor produces.
The fourth is non-acceptance for invalid reasons. A Project Manager who refuses acceptance because the new completion date is uncomfortable, or because the methods statement has changed, or because additional Time Risk Allowances have been added, has not used Clause 31.3 correctly. The four reasons are exhaustive; commercial discomfort with the revision is not among them. If the revision shows the Contractor's genuine plan, includes contract-required information, and is practicable, it should be accepted — even if the Client would prefer the programme to look different.
The fifth is the missed compensation-event revision. A CE has occurred, the time impact has been assessed and accepted under Clause 63, but the Accepted Programme has not been updated to reflect the time impact. The next CE assessment then uses a programme that does not show the previous CE's effect, and the Contractor has to argue from a stale baseline. NEC4 users' group commentary repeatedly highlights this as the single most common source of CE quantum disputes on live programmes — and it is entirely preventable through routine application of Clause 32.
What a defensible Clause 32 revision looks like
A revision that satisfies the contract's intent — rather than its administrative minimum — has the same four qualities as the Accepted Programme it replaces: it is current, it is honest about risk, it has a genuine critical path, and it connects to the other project controls outputs. The currency test is the easiest to apply: the data date is aligned with the actual reporting period, every operation that has started shows real progress, and the forecast logic recalculates from the data date rather than from the original plan.
The honesty-about-risk test asks whether the time impacts of preceding compensation events are reflected in planned completion, whether Time Risk Allowances on remaining activities reflect the risks the Contractor has actually identified, and whether early warnings notified under Clause 15 have either been incorporated into the programme or have been explicitly noted as still under assessment. A revision that ignores a notified Clause 15 matter because it has not yet been quantified is not honest about risk; the matter should be visible in the programme even if its impact is still being worked out.
The critical-path test asks whether the activities on the longest path through the network are the activities a knowledgeable observer would expect to be driving the programme. After several rounds of revision, critical paths can drift in ways that do not reflect the technical reality of the work — long-lead procurement that should still be critical drops off the path because durations have been compressed, while administrative activities with overstated durations appear on the critical path because the planner has added float in the wrong places. A revision that produces a critical path inconsistent with the programme's technical structure is a revision that has been driven by output rather than by logic.
The integration test asks whether the revision is consistent with the cost forecast, the risk register, and the early warning log. An Accepted Programme that shows planned completion three months later than the previous version, but where the cost forecast has not been updated to reflect the extended time, has not been properly integrated. The acceptance of the revision under Clause 31.3 should be conditional on the Contractor providing — or having provided — the corresponding updates to the cost forecast and the risk register. A revision accepted in isolation, without these supporting updates, weakens the project controls function and creates audit exposure that will surface at the next gateway review.
Putting it together
Clause 32 is the contract's answer to the problem of stale baselines. Without it, the Accepted Programme would be a one-time snapshot that gets less useful as the project moves on. With it, the Accepted Programme is a continuously refreshed picture of the Contractor's intentions — and the reference document against which compensation events are assessed under Clause 63. The mechanism is straightforward; the discipline of applying it is not.
The single most important thing for both parties to understand is that Clause 32 is not optional and not administrative. The Contractor who skips revisions when the project is busy, or submits thin revisions that do not meet Clause 32.1, weakens its own position at the next CE assessment. The Project Manager who does not respond to revisions within the two-week period, or who refuses acceptance for reasons outside Clause 31.3, weakens the client's ability to rely on the programme as a basis for CE quantum. Both behaviours surface as disputes that could have been prevented.
SOMA supports NEC4 ECC clients on UK infrastructure, defence and nuclear programmes — including programme assurance, Clause 32 revision discipline, CE time impact analysis, and the Clause 63 quantum work that depends on a current and defensible Accepted Programme. The standard the contract sets for programme management is achievable, but only when both parties treat the Clause 32 cycle as a live management process rather than a paperwork burden. That is the position SOMA helps clients reach.