NEC4 programme requirements are listed in clause 31.2: dates, sequence, others' work, allowances, what the Contractor needs and when, and how each operation will be done. Each programme submitted for acceptance has to show all of them, and a gap gives the Project Manager a reason not to accept it.
NEC3 ECC has the same list at 31.2. NEC4 adds that the programme is in the form the Scope states, so read your Scope alongside this checklist. For how these contents fit with the rest of the clause, see the clause 31 guide, or go back to the NEC programme guide.
Checklist by item
| Item in 31.2 | What to show | Common gap |
|---|---|---|
| Starting date, access dates, Key Dates, Completion Date | Each as a milestone, using the dates currently in force | Dates not updated after a compensation event is implemented |
| Planned Completion | Its own distinct milestone, separate from the Completion Date | Only one finish date shown, so float at the end can't be seen |
| Order and timing of the Contractor's operations | Linked activities at a level of detail that suits the work | Summary bars or broken logic |
| Order and timing of work by the Client and Others | As last agreed with them; if not agreed, as the Scope says | Utilities and Client's contractors left off, or based on old assumptions |
| Dates for meeting each Key Date's Condition, and for finishing work others depend on | Planned dates, shown against the Key Dates | Hand-over points to Others not identified |
| Provisions for float | Visible, so the reader can tell what spare time exists and where | Float absorbed into long durations |
| Provisions for time risk allowances | Identified, not hidden: see the time risk allowance guide | Nothing shown, or the same percentage on every activity with no thought behind it |
| Provisions for health and safety requirements | Time for the activities and restrictions the Scope and law call for | Possession or permit constraints ignored |
| Provisions for the contract's procedures | Time for submissions, reviews, tests, inspections and acceptances | Design submitted with no reply period in the sequence |
| Dates when the Contractor needs access, if later than the access date | A planned date for each affected part of the Site | Everything assumed from the Contract Data date |
| Dates when it needs acceptances | Specific dates, tied to activities | "Approval by PM" with no date |
| Dates when it needs Plant and Materials and other things from the Client | Delivery or provision dates for each item | Client-supplied items shown only in the Scope |
| Dates when it needs information from Others | Named items and dates | Vague "information required" activity |
| For each operation, how the work will be done, including principal Equipment and other resources | Short method statements and resources, in or linked to the programme | Only the bars sent, with no resources or method |
| Anything else the Scope requires | Reports, narrative, formats, baseline comparison | Scope not read by the planner |
| Form stated in the Scope (NEC4) | Software, file type, native file if required | PDF only, when the Scope calls for the native file |
Why these items are there
Each one has a job later in the contract. A date for access or Client-supplied items that appears on the Accepted Programme becomes part of the test for a compensation event, under 60.1(2) and 60.1(3). So if you leave a date off, you may lose the protection it would have given you. The same is true of Others' timings under 60.1(5): an event can be measured against what the programme says only if the programme says something.
Float and time risk allowances matter because a compensation event's delay is assessed through planned Completion. If they aren't visible, there will be an argument about what spare time existed. The float guide shows how that plays out.
A narrative helps
31.2 doesn't ask for a narrative unless the Scope does, but many planners send one anyway. A page or two can explain changes since the last revision, the critical path, the allowances and any outstanding dates, and it gives the Project Manager somewhere to start during a tight two-week reply period. It also helps to keep the method statements and resource information in one place, because that is the item most often missing.
For Clients drafting the Scope
Use the Scope to make these requirements specific. Software, file type, activity coding, logic rules, how time risk allowances are to be shown and how many weeks of look-ahead you want are all fair things to state. The more precise the Scope, the easier it is to give a sound reason for not accepting, and the less room there is for argument about the form. See the Scope definition for how it works in NEC4.
Related guides
- The NEC Programme: A Complete Guide
- Programme Acceptance and Reasons for Not Accepting
- Deemed Acceptance of a Programme Under NEC4
- NEC Clause 32: Revising the Programme
- What Is the Accepted Programme?
- NEC Clause 31 Explained
See how this works in practice
Click through Contract Status with sample contracts: raise the notice, reply to it, and watch both sides of one record.
Take the guided tour Book a demo
Try the planner role-play, use the free NEC tools or download free NEC templates.
This guide is general information in our own words, not legal advice. Your contract and its Contract Data always govern. NEC, NEC3 and NEC4 are trade marks of Thomas Telford Ltd; Contract Status is not affiliated with or endorsed by NEC.