What a clause 32 programme revision actually needs to show under NEC
- May 4
- 19 min read
By Roman Bazelchuk | NEC Accredited Project Manager | APMG Project Planning and Control
Founder, NEC Planning Solutions Ltd
Most NEC programme revisions fail. Not in a dramatic way. They are submitted, sit with the project manager for weeks, attract vague comments or no response at all, and eventually another revision is produced without the previous one ever being formally accepted. By month six, the contractor has submitted four or five revisions, none of them accepted, and the last accepted programme is still the one from mobilisation.
This is one of the most common patterns on NEC projects in the UK, and it is one of the most commercially destructive. Every month that passes without a current accepted programme is a month in which the contractor's compensation event entitlement is weakened. Every revision that fails to gain acceptance is a missed opportunity to update the commercial baseline. And every project team that treats clause 32 revisions as an administrative chore rather than a commercial discipline is quietly giving ground that the contract was designed to protect.
The problem is almost never that the contractor cannot produce a programme. The problem is that the NEC clause 32 programme revision does not show what the contract requires it to show. Clause 32 is short. It contains three requirements for revised programmes. But those three requirements interact with clause 31.2, with the compensation event machinery, and with the project manager's four grounds for non-acceptance in ways that most planning teams do not fully understand. A revision that meets clause 32.1 on the surface but fails to satisfy clause 31.2 in substance will be rejected. A revision that meets both but does not represent the contractor's realistic plans will be rejected. A revision that meets everything but arrives without a narrative explaining what changed and why will sit in a pile.
This article explains what a clause 32 programme revision actually needs to contain, why most revisions are rejected, and how to build a revision rhythm that keeps the accepted programme current throughout the project. It is the companion to the article on NEC clause 31 programme acceptance, which covers the initial acceptance mechanism. This article covers everything that happens after.
What clause 32 actually requires
Clause 32 of the NEC4 ECC is deceptively short. It sets out three things that every revised programme must show, in addition to meeting all the requirements of clause 31.2 that applied to the first programme.
The first requirement is the actual progress achieved on each operation and its effect upon the timing of the remaining work. This is not a statement of percentage complete. It is a requirement to show where each activity actually stands, what start and finish dates have been achieved, and how the remaining work has been recalculated in light of that progress. A revision that shows 60% progress on an activity but has not adjusted the remaining duration or the downstream logic to reflect that progress has not met this requirement. The contract expects the revision to show what progress means for the rest of the job, not just what has happened so far.
The second requirement is how the contractor plans to deal with any delays and to correct notified defects. If the project is behind programme, the revision must show what the contractor is doing about it. If there are notified defects that affect the programme, the revision must show how they will be corrected and when. A revision that shows delay without showing a plan to address it is incomplete.
The third requirement is any other changes which the contractor proposes to make to the accepted programme. This is the catch-all. Any change in sequence, any revised methodology, any new activity, any deleted activity, any change to logic, calendars, resources, or constraints that was not on the previous accepted programme must be visible in the revision.
These three requirements sit on top of clause 31.2, which continues to apply to every programme submitted for acceptance. That means every revision must still show the starting date, access dates, key dates, completion date, planned completion, the order and timing of operations, time risk allowances, the work of the employer and others, and everything else clause 31.2 lists. A revision is not a cut-down version of the programme with just the changes. It is a complete, current programme that meets all the requirements of clause 31.2 and additionally shows the three clause 32.1 elements.
Why most revisions are rejected
The four grounds for non-acceptance under clause 31.3 apply to every revision, not just the first programme. The project manager can reject a revised programme because the plans are not practicable, the required information is not shown, the programme does not represent the contractor's realistic plans, or the programme does not comply with the scope.
In practice, the reasons most revisions fail cluster around three patterns.
The first pattern is the progress-only update. The planner updates progress on activities, moves the data date forward, and resubmits. The dates shift. The bars move. The programme looks current. But nothing else has been addressed. Compensation events that have occurred since the last accepted programme are not shown. Changes in methodology are not reflected. Delays that have arisen are visible in the slippage but no recovery or mitigation plan is shown. The project manager receives a programme that shows where the job is, but not what the contractor is doing about it. That is not a clause 32 revision. It is a progress snapshot, and it is incomplete.
The second pattern is the optimistic re-baseline. The planner produces a revision that shows the project recovering to the original completion date despite obvious delay. Durations are shortened without explanation. Logic is changed to create parallelism that does not exist on site. Resources are shown at levels the contractor has no intention of providing. The project manager looks at the revision, compares it to what is happening on the ground, and rejects it on the basis that it does not represent the contractor's realistic plans. This is the most damaging pattern because it wastes a revision cycle and signals to the project manager that the contractor is not being honest about the state of the job.
The third pattern is the missing narrative. The revision is technically competent. Progress is correctly shown. Changes are incorporated. The logic is updated. But there is no written explanation of what changed and why. The project manager receives a programme with different dates and different logic from the previous accepted programme, and no context for what drove the changes. Without a narrative, the project manager has to reconstruct the reasoning themselves, which takes time they do not have and creates friction that delays acceptance.
None of these patterns involve bad planning in a technical sense. They involve planning without contract awareness. The planner is doing what scheduling software does: updating progress and rescheduling. But the contract requires more than rescheduling. It requires a revision that tells the project manager the current state of the works, the plan for dealing with problems, and the basis for believing the remaining programme is realistic.
The NEC3 to NEC4 change that matters
There is one significant change between NEC3 and NEC4 in the clause 32 requirements, and it directly affects what revisions should show.
NEC3 clause 32.1 required the contractor to show "the effects of implemented compensation events" on the revised programme. This was widely interpreted, incorrectly, to mean that only implemented compensation events should be shown. Non-implemented compensation events, meaning those that had been notified but not yet agreed, were excluded from many revisions on the basis that the contract did not require them.
This interpretation was always wrong. A compensation event that has been notified and is affecting the remaining work is a reality of the project whether or not it has been formally implemented. Excluding it from the programme produces a programme that does not represent the contractor's realistic plans, which is grounds for non-acceptance under clause 31.3.
NEC4 removed the line about implemented compensation events entirely. The effect is that clause 32.1 now simply requires the revision to show any changes the contractor proposes to make to the accepted programme. This includes all compensation events affecting the programme, whether implemented or not, whether agreed or still in quotation, whether notified by the contractor or the project manager. If the event is affecting the work, it should be visible in the programme.
The practical consequence is that every revision should show all compensation events that are affecting the programme at the time of submission. Implemented events should be shown as incorporated changes. Non-implemented events should be shown as proposed changes, clearly identified so the project manager can distinguish between changes that have been agreed and changes that are still in discussion. Activity codes or a dedicated WBS node for compensation events, as described in the article on Primavera P6 for NEC programmes, make this distinction easy to maintain.
What "actual progress achieved" really means
The first limb of clause 32.1 requires the revision to show "the actual progress achieved on each operation and its effect upon the timing of the remaining work." This is a compound requirement and both halves matter.
Actual progress means recording what has genuinely happened on site. Activities that have started should show actual start dates. Activities that have finished should show actual finish dates. Activities that are in progress should show actual start dates and realistic remaining durations based on current performance, not the original estimate. Activities that have not started should be left as planned unless there is a reason to change their forecast start.
The common mistake is to update progress using percentage complete without adjusting remaining duration. Percentage complete is a useful reporting metric but it is not what the contract requires. A 50% complete activity with ten days original duration does not necessarily have five days remaining. If the first half took twelve days because of weather or access problems, the remaining five days' worth of work may also take longer than planned. The revision should show a remaining duration that reflects reality, not arithmetic.
The effect upon the timing of the remaining work is the second half of the requirement, and it is the half that most revisions fail to address properly. Once progress is recorded, the schedule should be recalculated to show how remaining work has been affected. If an activity on the critical path took two weeks longer than planned, the downstream activities should show correspondingly later dates. If a non-critical activity used up its float, it may now be on or near the critical path, which changes the risk profile of the remaining programme.
This recalculation must be honest. A revision that shows three weeks of delay on the critical path but still shows planned completion on the same date as the previous accepted programme is lying. Either the delay has been recovered through genuine mitigation (which should be explained), or the planned completion date has moved (which should be shown), or the programme's logic has been manipulated to hide the delay (which the project manager will identify and reject).
The project manager's question, when reviewing the progress element of a revision, is simple: does this programme show me what is actually happening and what it means for the rest of the job? If the answer is yes, acceptance follows. If the answer is "it shows me what has happened but not what it means," the revision is incomplete.
Dealing with delays and defects
The second limb of clause 32.1 requires the revision to show how the contractor plans to deal with any delays and to correct notified defects.
This is the requirement that most revisions ignore entirely, and it is the one that project managers care about most.
If the project is behind the previous accepted programme, the revision must show what the contractor is doing about it. The options are limited but they should be explicit. The contractor may be accelerating through additional resources, extended working hours, or parallel working. The contractor may be re-sequencing to move non-critical work ahead of delayed critical work. The contractor may be accepting that planned completion has moved and showing the revised forecast honestly. Any of these responses is legitimate. What is not legitimate is submitting a revision that shows delay without addressing it.
The reason this matters commercially is that the contractor's response to delay affects compensation event assessment. Clause 63.8 requires assessments to assume the contractor reacts competently and promptly. If a revision shows delay and no recovery plan, the project manager may infer that the contractor is not reacting competently. If a compensation event arises during a period where the programme shows unaddressed delay, the PM's assessment of that event may be reduced on the basis that the contractor should have been mitigating. The article on NEC delay analysis and extension of time covers the clause 63.8 mitigation expectation in detail.
Notified defects are the second part of this requirement and are frequently overlooked. If defects have been notified under clause 44, the revision should show how and when they will be corrected. If correction affects the programme, that effect should be visible. Defect correction that requires access to completed areas, or that delays subsequent work, or that requires re-testing of systems, should appear in the programme as activities with logic links to the affected work.
In practice, most planning teams do not track defects in the programme at all. Defects are managed through a separate defects register and the programme ignores them. This is acceptable when defects are minor and do not affect the critical path. It is not acceptable when defect correction is programmatically significant, and the revision should show the distinction.
NEC clause 32 programme revision: how to show what changed and why
The third limb of clause 32.1 requires the revision to show "any other changes which the Contractor proposes to make to the Accepted Programme." This is the change-visibility requirement, and it is where the programme narrative becomes essential.
A revision that shows different dates, different logic, new activities, or deleted activities compared to the accepted programme has made changes. The contract requires those changes to be visible. The project manager needs to understand what changed, why it changed, and what the contractor expects the effect to be on remaining work.
The programme itself can show what changed through baseline comparison reports: activity-by-activity variance between the current revision and the previous accepted programme. P6, Asta Powerproject, and MS Project all produce these reports. They show added activities, deleted activities, changed durations, changed logic, changed dates, and changed constraints. This mechanical comparison answers the "what" question.
The "why" question requires a narrative. A programme narrative is not required by the exact words of clause 32, but it is the single most effective tool for securing acceptance. The narrative should cover four things.
First, a summary of progress since the last accepted programme: what has been achieved, where progress is ahead or behind plan, and what the data date is for the current revision.
Second, an explanation of any compensation events shown in the revision: which events have been incorporated, what their effect on the programme is, and whether they are implemented or pending.
Third, a description of any changes in methodology, sequence, or logic: what has changed, why the change was made, and what the effect is on remaining work and planned completion.
Fourth, a statement of the critical path: what the current critical path is, whether it has changed from the previous accepted programme, and what the current risk profile is for achieving planned completion.
A revision submitted with this narrative is easier for the project manager to review, less likely to be rejected, and far more useful as a commercial document if a dispute arises later. The narrative takes an hour to write. The acceptance it secures protects months of commercial position.
When revisions must be submitted
Clause 32.2 sets out three triggers for submitting a revised programme.
The first is at intervals no longer than those stated in the contract data. This is typically four weeks, though some contracts specify monthly or six-weekly intervals. This is the routine submission cadence, the regular heartbeat of programme management on an NEC project.
The second is when the project manager instructs the contractor to submit a revised programme. The contractor must comply within the period for reply stated in the contract data, which is typically two weeks. This instruction can come at any time and may reflect the project manager's concern that the programme has drifted from the work, or that a specific event needs to be incorporated.
The third is whenever the contractor chooses to revise the programme. The contractor is free to submit revisions more frequently than the contract data requires. This is useful when significant events have occurred between routine revision dates and the contractor wants to update the commercial baseline before the next scheduled submission.
The commercial significance of submission timing is often underestimated. A compensation event that arises three days before a routine revision is due should be incorporated into that revision. Waiting for the next revision cycle to include it means the accepted programme may not reflect the event at the moment it is being assessed, which weakens the contractor's quotation. The article on NEC delay analysis and extension of time explains why the accepted programme at the dividing date determines the quality of the contractor's time entitlement.
The acceptance cycle for revisions
Revised programmes submitted under clause 32 go through the same acceptance process as the first programme under clause 31.3. The project manager has two weeks to accept or notify non-acceptance with reasons. The same four grounds for non-acceptance apply. The same deemed acceptance mechanism applies under NEC4 if the project manager fails to respond.
This means every revision, not just the first programme, should be submitted formally, tracked for response, and followed up if the two-week window passes without acceptance or rejection. The contractor who submits revisions informally, by email without formal notification, by dropping a file into a shared folder, or by handing over a memory stick at a progress meeting, has no contractual record of submission date and cannot trigger the deemed acceptance mechanism.
Formal submission means a notification under the contract's communication rules (clause 13), with a clear date of submission, identifying the programme as a revised programme submitted for acceptance under clause 32. This formality is the trigger for the two-week acceptance clock and the backstop deemed acceptance provision. Without it, the contractor's programme is floating in the project manager's inbox with no contractual consequence for inaction.
When non-acceptance is the strategy
There is a version of the non-acceptance problem that is rarely discussed openly but that experienced contractors recognise immediately.
Some project managers avoid accepting revised programmes deliberately. Not because the revisions are non-compliant, and not because they lack time to review them. They avoid acceptance because a stale accepted programme gives them control over compensation event assessments.
The logic is straightforward. Under clause 64, if the contractor does not submit a programme showing the information the contract requires, or if no current accepted programme exists, the project manager can make their own assessment of compensation events. That assessment uses the project manager's own assumptions about the contractor's planned timing. Those assumptions almost always produce a lower entitlement than the contractor's quotation would have produced from a current accepted programme.
A project manager who keeps the accepted programme stale has, in effect, shifted the compensation event assessment mechanism from the contractor's forecast to the PM's judgement. Every unaccepted revision is another month where the PM retains that advantage. The contractor submits, the PM raises minor objections or simply does not respond within two weeks, the contractor does not trigger the deemed acceptance mechanism, and the cycle repeats.
This is not a conspiracy theory. It is an observable pattern on projects where the PM is under pressure to contain employer exposure on time and cost. The question is what the contractor should do about it.
The answer is procedural, not confrontational. First, every revision submission must be formal and dated under clause 13, creating the contractual record. Second, if two weeks pass without a response, the contractor must issue the notification of failure the same day. Third, if the PM then fails to respond within the further one week, the contractor must confirm the deemed acceptance in writing and treat the programme as accepted. Fourth, if the PM responds with non-acceptance, the reasons must be read against the four grounds in clause 31.3. If the stated reasons do not fall within those four grounds, the contractor has a compensation event under clause 60.1(9) and should notify it.
Most contractors never follow this sequence because it feels aggressive. But the contract provides this mechanism precisely for this situation. A contractor who uses it is not being confrontational. The contractor is administering the contract as it was designed to be administered. A project manager who understands that the contractor will follow the procedure will, in most cases, start accepting compliant revisions rather than face deemed acceptance or compensation event notifications. The procedural discipline changes the dynamic without requiring a single adversarial conversation.
The baseline drift problem and commercial exposure
The pattern described at the start of this article, where multiple revisions are submitted but none are accepted, creates a specific commercial problem.
Compensation event assessment under clause 62.2 uses the accepted programme at the dividing date. If the last accepted programme is from mobilisation and the compensation event occurs in month eight, the assessment must be built against a programme that is eight months out of date. That programme does not show the progress that has been made, the compensation events that have been incorporated, the changes in methodology that have occurred, or the current critical path. Building a time impact assessment against this baseline requires the contractor to first reconstruct what the programme should have looked like at the dividing date, which is harder, more disputable, and produces weaker entitlement than an assessment built against a current accepted programme.
This exposure grows with every month that passes without a revision being accepted. By month twelve, the contractor may have submitted eight revisions, none accepted, and the commercial baseline is still the mobilisation programme. At that point, every compensation event assessment is a reconstruction exercise, and the project manager has the upper hand in every negotiation because the contractor cannot demonstrate entitlement from a current, agreed baseline.
The remedy is not to submit better programmes. The remedy is to submit compliant revisions on a disciplined cadence, track acceptance, challenge non-acceptance that falls outside the four stated grounds, use the deemed acceptance provision when the project manager fails to respond, and treat every accepted revision as a commercial milestone worth protecting.
For contractors who struggle to maintain this discipline because they do not have a dedicated planning function, specialist contractor planning support is specifically designed to keep the revision cycle running throughout the project, at a cost that is small relative to the commercial exposure an absent accepted programme creates.
What a good clause 32 revision looks like in practice
A good revision is not a different product from the original accepted programme. It is the same programme, updated to reflect everything that has happened since the last accepted version. The difference between a good revision and a bad one is not the scheduling software or the technical skill of the planner. It is whether the revision addresses the contract's requirements in a way the project manager can follow.
The programme itself shows actual progress on all activities with honest remaining durations. The critical path is recalculated based on actual progress, not manually preserved from the previous version. All compensation events affecting the programme are visible, whether implemented or pending. Any changes in methodology, sequence, or logic are shown as explicit changes, not quietly buried in the schedule. Planned completion is shown honestly, not forced to match a date the contractor wants to present.
The baseline comparison shows what has changed since the last accepted programme: added, deleted, and changed activities with variance data the project manager can verify.
The narrative explains the context: what progress has been made, what events have affected the programme, what changes the contractor has introduced, what the current critical path is, and how the contractor plans to deal with any delay or defect.
Together, these three elements, the programme, the baseline comparison, and the narrative, constitute a clause 32 revision that meets the contract's requirements, addresses the project manager's review needs, and stands as a defensible commercial record if tested later.
Clause 32 Summary
Clause 32 is where the commercial value of the accepted programme is either maintained or allowed to decay. Clause 31 establishes the programme. Clause 32 keeps it alive.
Most contractors treat clause 32 revisions as an administrative burden rather than a commercial discipline. That treatment produces revisions that are rejected, ignored, or never formally submitted, creating months-long gaps in the accepted programme record that weaken every subsequent compensation event assessment.
The discipline required is not large. A monthly revision cycle. Progress recorded honestly. Compensation events shown whether implemented or pending. Changes explained in a short narrative. Formal submission tracked for acceptance. Two weeks chased if no response comes. Deemed acceptance triggered if the project manager remains silent.
That rhythm is the difference between a project where the accepted programme tracks the job and a project where the commercial baseline is quietly drifting into irrelevance. The contractors who maintain the rhythm recover their entitlement. The contractors who do not discover the cost of neglect when a dispute arrives and the last accepted programme is months, sometimes years, behind the live project.
FAQ
What does a clause 32 programme revision need to show?
Three things in addition to all the clause 31.2 requirements: actual progress on each operation and its effect on remaining work, how the contractor plans to deal with delays and correct notified defects, and any other changes the contractor proposes to make to the accepted programme. All three must be visible in the revision for it to be compliant.
How often must programme revisions be submitted under NEC?
At intervals no longer than those stated in the contract data, which is typically four weeks. The contractor must also submit a revision when the project manager instructs one (within the period for reply), and the contractor can submit more frequently whenever they choose. The contractual interval is the minimum, not the standard.
Can the project manager reject a programme revision?
Yes, using the same four grounds as for the first programme under clause 31.3: the plans are not practicable, the required information is not shown, the programme does not represent the contractor's plans realistically, or the programme does not comply with the scope. Non-acceptance on any other ground is itself a compensation event under clause 60.1(9). The project manager must give reasons for non-acceptance.
What happens if the project manager does not respond to a programme revision?
Under NEC4, the same deemed acceptance mechanism applies as for the first programme. If the project manager does not respond within two weeks, the contractor may notify the failure to respond. If the project manager then fails to respond within a further one week, the programme is deemed accepted. The contractor must issue the notification of failure; deemed acceptance does not happen automatically. The article on NEC clause 31 programme acceptance covers the deemed acceptance mechanism in detail.
Should non-implemented compensation events be shown on revised programmes?
Yes. NEC4 removed the NEC3 wording about "implemented compensation events" precisely because it was being misinterpreted as excluding non-implemented events. A revised programme should reflect all compensation events affecting the work, whether implemented or pending. Non-implemented events should be clearly identified so the project manager can distinguish agreed changes from proposed changes, but they should be visible in the programme because they represent the reality of the remaining work.
Is a programme narrative required under clause 32?
The exact words of clause 32 do not require a narrative. However, a revision submitted without a narrative explaining what changed, why, and what the contractor plans to do about any delays is significantly harder for the project manager to review and significantly more likely to be rejected or ignored. A short narrative covering progress, compensation events, methodology changes, and the current critical path is the single most effective tool for securing acceptance.
What is the difference between a clause 32 revision and a compensation event quotation programme?
A clause 32 revision is a complete updated programme submitted for acceptance showing the current state of all works. A compensation event quotation programme under clause 62.2 shows the specific changes to the accepted programme caused by one compensation event. They serve different purposes and are submitted through different contractual routes, but they should be consistent with each other. The revised programme should reflect implemented compensation events, while the CE quotation programme shows the effect of a specific event against the accepted programme at the dividing date.
About the author
Roman Bazelchuk is the Founder of NEC Planning Solutions Ltd, a UK project planning and controls consultancy supporting contractors with NEC programme compliance, compensation event assessments and live project controls. He is an NEC Accredited Project Manager and holds the APMG Project Planning and Control qualification, with a BSc in Mechanical Engineering and postgraduate training in Planning and Control.
NEC Planning Solutions provides contract-aware planning support through a QA-governed delivery model, helping project teams keep programmes accepted, current and commercially useful from tender through to live delivery.
Revisions falling behind or not being accepted?
If the revision cycle has stalled, the accepted programme has drifted from the live project, or compensation events are being assessed without a current baseline, specialist NEC programme support restores the revision discipline and protects the commercial record.
