What Clause 31 Requires
Three months into a £30 million highway scheme, the commercial team discovers there's no Accepted Programme. Every compensation event quotation submitted so far has been assessed by the Project Manager using their own assumptions. The result: months of entitlement quietly eroded because there was no agreed reference point to measure against.
NEC4 programme management centres on Clauses 31 and 32 of the Engineering and Construction Contract. Clause 31 requires the Contractor to submit a programme for acceptance within the period stated in Contract Data Part 1. If a programme is identified in Contract Data Part 2 at contract award, that becomes the starting point. If not, the Contractor must submit one within the stated period.
This isn't optional. Without an Accepted Programme, the Project Manager assesses compensation events using their own assumptions about the Contractor's planned timing. Those assumptions rarely favour the Contractor.
The programme must show at minimum:
- The order and timing of operations, with each operation's planned start and finish dates
- How the Contractor plans to meet each Key Date and the Completion Date
- Float and time risk allowances, shown as separate items
- Health and safety requirements
- Procedures set out in the Scope
- The dates by which the Contractor requires information, access, and other things from the Client
- Method statements for each operation
Why this matters commercially
On a typical NEC4 project worth £30 million, failing to secure an Accepted Programme turns every compensation event assessment into a negotiation rather than a measurement. The Project Manager's assessment under Clause 63.1 relies on their own assumptions about planned timing. Without an agreed programme to measure against, those assumptions almost always work against the Contractor.
NEC4 programme submission and acceptance timeline under Clauses 31 and 32
Scroll to see full diagram
Acceptance and Rejection Criteria
The Project Manager has two weeks from receiving a submitted programme to either accept it or notify non-acceptance with reasons. Clause 31.3 limits the grounds for rejection to four specific criteria.
| Rejection Ground | What It Means | Common Example |
|---|---|---|
| Not practicable | The planned sequence can't physically be achieved | Showing steelwork before foundations are complete |
| Missing required information | Programme doesn't contain contractually required data | No float or time risk allowances shown |
| Not realistic | Durations or logic don't reflect reality | Allocating 5 days for an activity that typically takes 20 |
| Does not comply with Scope | Programme contradicts requirements in the Scope | Sequence ignores phased handover requirements |
If the Project Manager fails to respond within two weeks, the Contractor can notify this failure under Clause 13.4. Should the Project Manager still not respond within a further two weeks of that notification, the programme becomes accepted. This deemed acceptance rule protects Contractors from Project Managers who simply ignore submissions.
The Project Manager can't reject a programme because they disagree with the Contractor's method or sequence, provided that sequence is practicable, realistic, and compliant with the Scope.
Float Ownership and Its Commercial Impact
Float is the time available before an activity delay affects the Completion Date. NEC4 doesn't explicitly state who owns float, but the widely accepted interpretation, supported by NEC guidance and adjudication decisions, is that float belongs to the project rather than to either party. The commercial consequences of this are real and measurable.
When the Project Manager assesses a compensation event for time impact, the assessment uses the Accepted Programme as its reference point. If that programme shows 4 weeks of float on the affected activity, a 2 week Client-caused delay consumes float without extending the Completion Date. The Contractor gets compensated for the cost impact but receives no extension of time.
Terminal float vs activity float
Planned Completion is the Contractor's forecast finish date shown on the programme. The Completion Date is the contractual obligation. Terminal float is the gap between the two. Activity float sits on individual activities or chains.
When a Client-risk event occurs, terminal float gets consumed first. The Completion Date only moves once all terminal float is used. Building excessive float into your programme therefore works against you when compensation events occur.
The practical takeaway? Programme your works realistically. If you inflate durations to hide float, you reduce your ability to show that a Client event caused actual delay to Completion. Every week of hidden float is a week of entitlement you won't recover.
The Programme as a Compensation Event Reference Point
The Accepted Programme serves as the reference for assessing the time and cost impact of compensation events under Clause 63. When a compensation event occurs, the assessment asks: what effect does this event have on the Accepted Programme current at the dividing date?
This is a prospective assessment. It measures the forecast impact from the dividing date forward, not the retrospective actual impact. That distinction matters because it rewards accurate forecasting and penalises contractors who wait to see what happens before submitting quotations.
Worked ExampleProject: £25 million highway improvement, NEC4 Option C
The Accepted Programme shows piling commencing 1 March with 8 weeks' duration, completing 25 April. No float exists on the piling chain to Completion.
On 15 February, the Client instructs a change to pile design (Clause 60.1(1)). The Contractor's quotation shows the revised design requires 11 weeks, extending piling completion to 16 May, a delay of 3 weeks.
Because the Accepted Programme showed zero float on this chain, the full 3 week delay flows through to Completion. The Contractor receives both time (3 weeks) and additional Defined Cost plus Fee for the extended preliminaries, valued at approximately £180,000.
Had the programme shown 4 weeks of float on piling, the 3 week delay would have been absorbed. The Contractor would receive cost compensation for the changed design but no extension of time.
Updating the Programme Under Clause 32
Clause 32 requires the Contractor to submit a revised programme at intervals no longer than the period stated in Contract Data (typically every 4 weeks) or when the Project Manager instructs. Each revision must show:
- Actual progress achieved against planned progress
- The effects of implemented compensation events
- How the Contractor plans to deal with any delays (including matters raised as early warnings)
- Any other changes to the programme
Failing to keep the programme updated hits you directly in cash flow. Under Clause 50.3, 25% of the Price for Work Done to Date is retained until the Contractor submits a programme showing the required information. That retention alone should be enough incentive to maintain the programme.
Gather maps daily site records to programme activities automatically, flagging when actual progress diverges from the Accepted Programme. When a Clause 32 revision is due, the data is already structured: actual start and finish dates, resource records, and CE effects are pre-populated rather than reconstructed from memory.
NEC4 programme update cycle: submit, review, accept or reject with 25% retention consequence
Scroll to see full diagram
Common Programme Failures That Cost Money
Most NEC4 programme disputes follow predictable patterns. Three failures cause the most damage:
No programme submitted at all. This is the single most expensive mistake. The PM assesses every compensation event using their own assumptions under Clause 63.1, and those assumptions almost always undervalue the Contractor's entitlement. You've handed the PM complete control over your valuations.
Programme not kept up to date. Clause 50.3 allows 25% of PWDD to be retained when the programme doesn't reflect current information. On a £30M project, that's up to £1.5M withheld from cash flow. Beyond retention, an outdated programme means future CE assessments use a reference point that no longer reflects reality.
Inflated durations hiding float. It's tempting to pad your programme with generous durations. Don't. When a Client event occurs, the hidden float absorbs the delay and no extension of time is granted. Lost preliminary costs run between £40,000 and £60,000 per week. The float you thought was protecting you ends up costing you.
The remaining common failures follow the same theme:
| Failure | Consequence | Financial Impact |
|---|---|---|
| No time risk allowances shown | PM rejects programme, delays acceptance | Leaves old reference point in place, weakening CE claims |
| Logic links missing | Can't demonstrate cause and effect for delay | Adjudicator can't trace delay path; claim fails |
| Not showing CE effects | Programme doesn't reflect current position | Future CE assessments use an outdated starting point |
| Sequential logic where parallel is possible | Inflates critical path and reduces available float | Delay claims overstated or dismissed; PM questions realism |
| No float shown; all on critical path | Impossible to distinguish genuine delay from padding | Adjudicator can't assess delay entitlement; claims rejected |
| Client dates not separated | Late Client information stays invisible on programme | Missed CE opportunities when Client info arrives late |
| Programmes keep losing acceptance | Perpetual non-acceptance cycle; PM uses Cl. 63.1 | Every CE quotation weakened; Contractor loses control |
| Unrealistic durations vs productivity | PM rejection under Clause 31.3 (not realistic) | Programme returned repeatedly; no Accepted Programme during resubmission |
| No copy of accepted version retained | Can't measure delays against original plan | Delay analysis relies on reconstructed data; entitlement reduced |
The common thread is clear. Poor programme management doesn't just create administrative headaches. It directly reduces entitlement and weakens your position in disputes.
Practical Programme Submission Checklist
Before submitting or revising a programme, verify it meets these requirements. Missing any one gives the Project Manager grounds for non-acceptance.
Pre-Submission
Programme format confirmed. Use an industry-standard tool (Primavera P6, Asta Powerproject, or MS Project). The format should match what's stated in the Scope. Submit native files, not PDFs, so the PM can interrogate logic and float.
Critical path identified and marked. The programme must show a clear critical path from the current date to each Completion Date. Without it, delay analysis is impossible.
Float shown separately from critical path. Float and time risk allowances must appear as distinct items, not hidden within activity durations. Clause 31.2 specifically requires this. If all activities sit on the critical path, the PM can't assess delay entitlement.
Resource loadings included. Each activity should show the resources required. Resource-loaded programmes prove that durations are achievable and defend against Clause 31.3 rejection on realism grounds.
Method statements referenced. Programme logic must align with your method statements and Scope requirements. Contradictions give the PM a reason to reject.
Client obligations and Key Dates identified. Show every date by which you need information, access, materials, or approvals from the Client as separate activities. These dates become triggers for compensation events if the Client misses them.
Post-Submission
Formal submission letter sent with date. Record the submission date in writing. This starts the two-week clock for PM acceptance or rejection and is essential for triggering deemed acceptance under Clause 13.4 if the PM doesn't respond.
PM acceptance or rejection chased within the two-week window. If the PM hasn't responded within two weeks, notify the failure immediately. A further two weeks of silence triggers deemed acceptance. Don't let submissions sit unanswered.
Copy of the accepted version retained. Save a locked copy of each Accepted Programme revision. Without that snapshot, you can't measure delays against the original plan at adjudication or dispute resolution.
Any rejection grounds reviewed against Clause 31.3. If the PM rejects the programme, check the stated reasons against the four permitted grounds. Challenge any rejection that amounts to mere disagreement with your method or sequence. Raise an early warning if repeated rejections risk leaving the project without an Accepted Programme.
.webp)
