NEC4 clause 31: getting your programme accepted (and why most aren't)
Under NEC4, the programme is not a reporting formality — it is the instrument the whole contract runs on. Yet in practice a large share of first programmes are rejected. Here is what clause 31 actually asks for, the four reasons a Project Manager can give for non-acceptance, and how to audit your own submission before someone else does.
What acceptance requires — the short answer
Clause 31.1 requires the contractor to submit a first programme within the period stated in Contract Data, unless one was already identified in Contract Data Part 2 at award. Clause 31.2 lists what it must contain — far more than bars and dates, as we will see. The Project Manager then has two weeks to respond under clause 31.3: either accepting the programme, or stating which of four contractual reasons applies — the contractor's plans are not practicable; the programme does not show the information the contract requires; it does not represent the contractor's plans realistically; or it does not comply with the Scope.
That is the entire mechanism. Everything that goes wrong with NEC programmes — rejection cycles that run for months, compensation events assessed against thin air, payment withholding — flows from one of those two clauses being treated casually. The encouraging corollary: every one of the four rejection reasons can be tested against your own programme before you press submit.
Why the Accepted Programme is the keystone
NEC assesses compensation events prospectively: under clause 63 the delay is measured as the movement of planned Completion on the Accepted Programme current at the dividing date, with the event impacted into it — forecast forward, not reconstructed afterwards. It is the same forward-looking logic as a time impact analysis, embedded directly in the contract. That design only works if there is a current, realistic Accepted Programme to impact.
When there isn't one, CE assessment degenerates. The contractor impacts events into a programme the PM never accepted; the PM makes their own assessment against a model they don't trust either; both sides accumulate positions instead of agreements, and the dispute that eventually surfaces is built on a foundation neither party believes in. Most NEC time disputes trace back not to the delay events themselves but to the absence of a credible Accepted Programme when they happened.
The contract also applies direct commercial pressure. Where no first programme showing the required information has been submitted, the assessment provisions allow one quarter of the Price for Work Done to Date to be retained from amounts otherwise due, until it is. The detailed mechanics depend on the main Option in use, but the intent could not be clearer: NEC treats a missing programme as a quarter-of-your-money problem, not a paperwork problem.
Clause 31.2 as a self-audit checklist
Clause 31.2 is effectively a contents page for the programme, and the second rejection reason — "does not show the information which this contract requires" — is tested against it line by line. The list includes the starting date, access dates, Key Dates and the Completion Date; planned Completion (the contractor's own forecast, distinct from the contractual date); the order and timing of the operations the contractor plans to carry out; float and time risk allowances; health and safety requirements; provisions for the work of the Client and Others; and a statement of how the contractor plans to do the work, identifying principal equipment and resources. Each item maps to something concrete in a P6 model:
| Clause 31.2 requirement | What it means in P6 terms | Common failure |
|---|---|---|
| Starting date, access dates, Key Dates, Completion Date | Contract milestones with the correct dates, clearly coded and logic-linked | Key Dates missing entirely, or shown as text rather than driven milestones |
| Planned Completion | A separate milestone for the contractor's forecast finish, distinct from the Completion Date | One milestone doing both jobs — terminal float becomes invisible |
| Order and timing of operations | A complete logic network: every activity wired in, no open ends | Open-ended activities; sequence forced by constraints instead of logic |
| Float and time risk allowances | Calculated total float visible per path; TRA shown as identifiable activities or owned allowances | No TRA anywhere, or TRA buried inside padded durations where nobody can see it |
| Statement of how the contractor plans to do the work | Method and resource statement consistent with the modelled durations and crew logic | Narrative says two rigs, programme durations only work with three |
| Provisions for the Client and Others | Interface milestones and dependencies for client-supplied items and third parties | Client dependencies omitted — so their lateness can never be demonstrated |
| Health and safety requirements | Statutory and Scope-required periods modelled as durations or constraints with justification | Commissioning and notice periods squeezed to make the end date work |
The discipline worth borrowing: before submission, walk the 31.2 list with the programme open and tick each item against something you can point at on screen. If the evidence for an item is "it's implied", expect the PM to disagree.
The four reasons for non-acceptance, decoded
"Not practicable" is about physics and logistics: the plan cannot be built as drawn. Trades stacked in the same area beyond any plausible density, durations that imply production rates nobody has achieved, design release dates that have already passed. Reviewing PMs test this with simple cross-checks — quantities against durations, resource histograms against stated gangs — and a programme that fails them invites rejection on the first pass.
"Does not represent the contractor's plans realistically" is where structural quality bites hardest, because realism is the one reason a PM can evidence objectively. A programme with hundreds of open-ended activities is not realistic — float is fiction wherever logic is missing. A completion date achieved by a hard constraint rather than by the network is not realistic — the model is being overridden, not believed. Missing time risk allowances make the whole submission unrealistic by definition, since clause 31.2 expects them and no real plan carries zero risk. These are exactly the failures the DCMA 14-point assessment was designed to surface, which is why many NEC reviewers now run it, formally or informally, as their first filter. If your open-end count, hard-constraint count or float profile would embarrass you in that report, it will embarrass you in the acceptance response too.
The other two reasons — missing required information, and non-compliance with the Scope (NEC4's term for what NEC3 called the Works Information) — are more mechanical: the 31.2 checklist above covers the first, and a methodical read of the Scope's constraints on sequence, access and working methods covers the second. Mechanical does not mean rare; missing information is, in practice, the most frequently cited reason of the four.
Terminal float, TRA and everything else: who owns what
NEC4 splits float into three populations with different owners, and confusing them is one of the fastest ways to lose an argument about a compensation event.
Time risk allowances are the contractor's explicit provisions for the contractor's own risks — weather days on the roof works, re-work allowances, learning curves. They belong to the contractor: a compensation event cannot be absorbed into them, because they were never provided for client risk. They must be shown in the programme; the durable convention is to model them as identifiable activities rather than silently padding durations. Terminal float is the gap between planned Completion and the Completion Date, and it also belongs to the contractor — clause 63 measures delay as movement of planned Completion, so a CE that pushes planned Completion pushes the Completion Date with it, preserving the gap. Everything else — ordinary path float within the network — is owned by neither party and is available to absorb delay: a compensation event on a path with twenty days of float and five days of impact moves nothing and entitles nobody.
Clause 32: the revision discipline
Acceptance is not a one-off event. Clause 32 requires revised programmes at the intervals stated in Contract Data, each showing actual progress, the effects of implemented compensation events and notified early warnings, and how the contractor plans to deal with delays and correct notified defects. Each revision goes through the same acceptance test, and each accepted revision becomes the new reference for assessing whatever happens next.
This is the contract enforcing what good planners do anyway: disciplined baseline management. The chain of accepted revisions is the contemporaneous record — when a CE lands in month fourteen, the assessment starts from the most recent Accepted Programme, and the quality of that assessment is set by the honesty of every update before it. A contractor who lets revisions lapse, or lets quality decay update by update, is quietly dismantling their own evidence.
Deemed acceptance — and why relying on it is a bad idea
NEC4 added a backstop NEC3 never had. If the Project Manager simply does not respond within the two weeks, the contractor may notify the failure; if the silence continues for a further week after that notification, the programme is treated as having been accepted. The drafters' purpose was to stop the limbo that plagued NEC3 projects, where programmes sat unanswered for months and the contract drifted along without an Accepted Programme at all.
As a fallback against an unresponsive PM, it is valuable. As a strategy, it is poor. A programme accepted by silence has persuaded nobody: the PM who ignored it will dispute every CE assessment built on it, and a tribunal asked years later to rely on a deemed-accepted programme will weigh the fact that no human being ever endorsed it. Acceptance is worth having because of what it signifies — a shared model of the project — and a deemed acceptance signifies only that someone missed a deadline. Get the real thing.
A pre-submission routine that works
The pattern among contractors whose programmes pass first time is not genius scheduling; it is that they review their own submission the way the PM will. Concretely:
- Run the structural checks first. Open ends, leads, hard constraints, negative float, dangling milestones — anything that makes the programme objectively unrealistic. This takes minutes with the right tooling (it is precisely what ScheduleInsight's checks against an XER are for) and removes the easiest grounds for rejection before a human reviewer ever sees the file.
- Walk clause 31.2 item by item and tick each requirement against something visible in the programme — including separate planned Completion and Completion Date milestones, and TRA you can point at.
- Cross-check narrative against model. If the method statement and the durations imply different resources, fix one of them.
- Read the Scope's programme requirements once more. Z-clauses and Scope sections routinely add density rules, coding requirements and submission formats that the standard form does not.
Key takeaways
- The PM has two weeks and exactly four reasons to reject: not practicable, missing required information, not realistic, non-compliant with the Scope. Every one is testable before you submit.
- The Accepted Programme is the reference for prospective CE assessment under clause 63 — and a missing first programme can cost a quarter of the Price for Work Done to Date.
- Float has owners: TRA and terminal float are the contractor's; other float is available to absorb delay.
- Deemed acceptance (new in NEC4) is a backstop against silence, not a strategy — a programme accepted by default has persuaded no one.
Run the structural checks before the Project Manager does
Drop your P6 XER or MS Project file in the browser and see every open end, hard constraint and float problem a reviewer would find — in seconds, with nothing uploaded.