What the project manager checks when reviewing your NEC programme
- 13h
- 19 min read
A contractor's planning team submits a programme on a Tuesday. Two weeks later, on the deadline day, the project manager issues a non-acceptance notice. The reasons are listed: the programme is not practicable, key dates are not properly shown, the work of others is unclear, time risk allowances are not visible. The contractor reads the notice and recognises that several of the issues could have been spotted before submission. The team rebuilds the programme, addresses the comments, and resubmits two weeks later. The cycle continues. By month four, three programmes have been submitted, none accepted, and the project is operating without an accepted baseline.
This pattern is one of the most common on NEC projects in the UK, and the cause is rarely incompetence on either side. The cause is that the contractor's planning team and the project manager are working from different mental models. The planning team is preparing a programme to demonstrate the contractor's plan. The project manager is reviewing the programme against a structured set of acceptance criteria. The two activities should produce the same result, but they often do not, because the contractor's planning team rarely knows what the project manager actually checks, in what order, and what triggers a rejection at each step.
The strongest contractors flip this dynamic. They build programmes for review, not just for submission. They know what the project manager will look at first, what they will look at next, where the most common failure points sit, and what evidence the project manager needs to see at each stage to move from challenge to acceptance. The result is programmes that get accepted on the first or second submission rather than the fourth or fifth, and accepted programmes that hold up commercially when compensation events arise.
This article explains what the project manager actually checks when reviewing an NEC programme. It walks through the review sequence as the project manager experiences it, identifies the questions they ask at each stage, and shows where most rejected programmes fail. It is written for contractors who want to understand the review from the other side of the desk, so they can pre-empt every objection before it lands.
The four grounds for non-acceptance: the only legal basis for rejection
Before the review begins, the project manager has to remember a constraint that contractors should also remember: under clause 31.3 of NEC4 (and NEC3), there are only four valid grounds for non-acceptance. The contractor's plans are not practicable. The programme does not show the information the contract requires. The programme does not represent the contractor's plans realistically. The programme does not comply with the scope.
That is the complete list. A project manager who rejects a programme on any other ground is acting outside the contract, and the rejection is itself a compensation event under clause 60.1(9). Disagreeing with the contractor's chosen sequence is not a valid ground if the sequence is practicable. Believing that acceptance creates liability is not a valid ground. Wanting more detail than the contract requires is not a valid ground.
This matters because it shapes how the project manager structures their review. Every issue the project manager identifies has to map back to one of the four grounds, or the rejection cannot be sustained. The project manager who understands this works through the programme asking, at each point: "if I were to reject the programme on this issue, which of the four grounds would I cite, and would the contractor be able to challenge that ground?" The contractor who understands this asks the same question in reverse: "for everything I have shown in my programme, which of the four grounds could be used against me, and have I closed off that possibility?"
The article on NEC clause 31 programme acceptance covers the four grounds in detail. The rest of this article looks at the review sequence the project manager applies to test the programme against each of them.
The first thirty seconds: the cover and the format
A project manager opening a programme submission for the first time forms a preliminary view within thirty seconds. That view is based on the cover, the format, and the immediate visual impression of the programme on screen.
The first question is whether the submission is formal. A programme submitted as an email attachment without a formal notification under clause 13 is technically deficient. The two-week acceptance clock starts on formal submission, not on email receipt. A programme that arrives without a clear submission notice gives the project manager an immediate procedural concern: when does the clock start? If the answer is unclear, the project manager has grounds to delay engagement.
The second question is whether the submission package is complete. A properly submitted NEC programme is not just a Primavera P6 or Asta Powerproject file. It is a package containing the schedule file, a PDF or printout of the programme, a programme narrative explaining what is being submitted and what has changed since any previous version, baseline comparison reports if a previous version was accepted, and any supporting documentation referenced in the narrative (resource histograms, method statement cross-references, calendar definitions). A submission that arrives as a single .xer file with no accompanying documentation tells the project manager that the contractor has not invested in the review experience. The project manager will engage with it eventually, but with reduced enthusiasm.
The third question is whether the programme is in the form stated in the scope. NEC4 added an explicit requirement under clause 31.3 that the programme must comply with the scope, which can specify software, format, level of detail, and submission package contents. If the scope requires Primavera P6 and the contractor submits in Microsoft Project, that is grounds for rejection on the fourth limb. If the scope requires resource-loaded activities and the contractor submits without resource loading, the same applies. The project manager checks the scope against the submission early in the review.
The contractor who prepares the submission package as a deliberate review experience signals planning maturity in a way that affects the entire review. The project manager opens the package, sees a clear submission notice, a complete set of files, a programme narrative that orients them quickly, and a format that complies with the scope. The first thirty seconds produce a positive disposition. The contractor who submits a single file with no narrative starts the review from a lower baseline, and every subsequent issue the project manager finds carries more weight.
The first review pass: structural integrity
The project manager's first substantive pass through the programme tests structural integrity. This is fast. It takes ten to fifteen minutes for an experienced reviewer working with proper layouts. It produces a yes-or-no decision on whether the programme is fundamentally sound enough to merit detailed review.
The structural checks are well established. The project manager runs through each one in sequence.
Are there open ends? An open-ended activity is one with no predecessor (an open start) or no successor (an open finish). On an NEC programme, open starts should exist only at the project start milestone. Open finishes should exist only at completion milestones. Any other open end is a logic error. The project manager runs the standard open ends report. If the report shows more than a handful of open ends beyond the expected start and finish milestones, the structural integrity has failed and detailed review is not worth pursuing yet.
Does the logic flow from start to finish? The project manager checks whether every activity has at least one predecessor and one successor (except the start and finish milestones). They check whether any activities are dangling outside the main logic network. They check whether the critical path runs cleanly from start to finish without breaks. A programme with broken logic chains cannot demonstrate compensation event impacts and is not fit for purpose.
Is the critical path identifiable and credible? The project manager looks at the critical path filter. Are the activities on the critical path the ones that the project manager would expect to be critical based on the nature of the works? Or are they activities that look critical only because the logic has been built in a way that distorts the calculation? A critical path that runs through unexpected activities (a survey activity dominating the critical path of a major construction package, for example) is a signal that the logic is not modelling reality.
Are constraints minimal and justified? The project manager runs the constraints report. NEC programmes should have a small number of constraints, all tied to contractual dates: the start date, access dates, key dates, the completion date, and any sectional completion dates. A programme with dozens of constraints, especially "must finish on" or "must start on" constraints applied to activities that have no contractual date, is a programme that has been forced to look a particular way rather than calculated honestly.
Are calendars sensibly applied? The project manager looks at calendar assignments. Different types of work should sit on different calendars: site works on the contractor's site calendar, design and approval activities on a working week calendar, manufacturing on a manufacturer's calendar. A programme with all activities on a single default calendar misrepresents how delay will manifest and produces compensation event assessments that nobody can agree on.
These five structural checks take an experienced reviewer fifteen minutes. If the programme passes them, detailed review proceeds. If it fails any of them, the project manager has grounds to non-accept on the limb that the programme does not represent the contractor's plans realistically, and detailed review is unnecessary.
The contractor who runs these same five checks before submission catches the structural issues that produce the most common rejections. The article on Primavera P6 for NEC programmes covers the schedule design choices that make these checks pass naturally.
The clause 31.2 information check
Once structural integrity is established, the project manager works through clause 31.2 systematically. Clause 31.2 is the longest clause in section 3 of the NEC4 ECC. It sets out, item by item, what every programme submitted for acceptance must show. The project manager works through the list and verifies each item is present.
The starting date and the access dates. The starting date is the date the contractor takes possession. The access dates are the dates on which the contractor can access different parts of the site. The project manager checks that both are shown explicitly, not implied through activity logic. If access to the south compound is required by 1 May and the programme shows the activity that needs that access starting on 5 May without showing the access date, the project manager has grounds to non-accept on the limb that required information is not shown.
The completion date and the contractor's planned completion. These are different things. The completion date is the contractual obligation. Planned completion is the contractor's forecast. The gap between them is terminal float, which belongs to the contractor under clause 63.5. The project manager checks that both dates are shown as separate milestones, not collapsed into a single completion event.
Key dates. Key dates are intermediate contractual milestones at which the contractor must achieve specific conditions for the works. The project manager checks that every key date in the contract data is shown on the programme, with the activities that lead to it clearly identified. A programme that omits key dates fails the information check on the limb that required information is not shown.
The order and timing of operations. This is the substantive content of the programme: the activities, their durations, their logic relationships, the sequence of work. The project manager checks that this is at a sensible level of detail (not 50 activities for a 24-month project, not 50,000 activities either), that durations are reasonable, and that the sequence makes physical sense.
Time risk allowances. Clause 31.2 explicitly requires time risk allowances to be shown. These are the contractor's risk periods, distinct from float. A programme that hides risk allowance inside activity durations without making it visible fails this requirement. The project manager looks for either separate TRA activities or a dedicated TRA column showing the allowance per activity. Programmes that have no visible TRA at all are particularly vulnerable to non-acceptance, because they signal either an unrealistic plan or hidden contingency that cannot be evaluated.
Float. The programme must show float as a separate concept from time risk allowance and from terminal float. Float is the time between an activity's late finish and its early finish. It belongs to the project as a whole, not to either party, and it is consumed in the order activities use it.
Information from the project manager and others. The programme must show when the contractor needs information, acceptances, decisions, plant, and materials from the project manager, the employer, or others. This requirement is critical commercially. Under clause 60.1(3), if the employer fails to provide something by the date shown in the accepted programme, that is a compensation event. If the programme does not show when the employer is required to provide something, the contractor cannot trigger the compensation event. The project manager checks that all employer dependencies are explicit on the programme, not implied. The article on NEC clause 31 programme acceptance covers this commercial mechanism in detail.
The work of the employer and others. Activities being performed by parties other than the contractor must appear on the programme, either as activities with the appropriate responsibility code or as constraints. A programme that shows only the contractor's own work and ignores work being performed by others on the same site cannot model interfaces accurately and cannot support compensation event assessment for delay caused by others.
Health and safety requirements. NEC4 added this requirement that was not in NEC3. The programme should show health and safety milestones, sequencing constraints driven by safety considerations, and any specific safety requirements stated in the scope.
Other information stated in the contract data. The contract data may specify additional programme information beyond the standard clause 31.2 list. The project manager checks the contract data for any project-specific requirements and verifies they are shown.
The project manager works through this list in sequence. Each item is either present or not. Items that are not present are flagged as potential non-acceptance grounds on the limb that required information is not shown. The contractor who has built the programme around this list explicitly, with each clause 31.2 element placed deliberately rather than emerging from the schedule incidentally, passes this check easily.
The realism test
After the information check, the project manager moves to the realism test. This is the most subjective of the four grounds, and the one that produces the most disagreement, but it follows a recognisable pattern when applied properly.
The project manager asks: does this programme represent what the contractor actually plans to do, with the resources they actually plan to deploy, in the sequence they actually plan to follow? Or does it represent a tidy picture that does not match operational reality?
Several specific tests inform this judgement.
Are durations achievable with the resources shown? The project manager checks whether the programme is resource-loaded and whether the resource levels are consistent with the durations. A six-week activity for a major concrete pour that shows two operatives is not credible. A two-week activity for a complex M&E commissioning sequence with no commissioning resource shown is not credible. The project manager flags activities where the resource and duration do not match.
Is the sequence physically possible? The project manager checks whether activities that depend on each other physically are sequenced correctly. Following trade activities cannot start before preceding trade activities are complete in the same area. Commissioning cannot start before installation. Procurement lead times must precede installation. A programme that compresses physical sequences in ways that are not possible on site fails the realism test.
Does the programme match the method statement? Most NEC contracts require a method statement either as part of the scope or as a contractual deliverable. The project manager cross-references the programme against the method statement. If the method statement says the M&E sequence is install before testing before commissioning, but the programme shows commissioning starting before installation is complete, there is a contradiction. The contradiction is grounds for non-acceptance on either the realism limb or the scope compliance limb.
Is mitigation visible? If the programme shows recovery from a delay or compensation event, the mitigation measures should be visible: re-sequenced activities, additional resources, extended working hours, parallel sequences. A programme that shows recovery without showing how recovery is achieved is not credible. The article on NEC programme acceleration and mitigation covers the mitigation discipline that supports realism.
Is planned completion honest? The project manager checks whether planned completion sits at a date that reflects the contractor's actual forecast, or whether it has been forced to match the completion date or some other politically convenient date. A programme where planned completion sits exactly on the completion date despite obvious delay risk is not realistic. A programme where planned completion has been pulled back to match a stretch target the contractor has no realistic chance of achieving is not realistic.
The realism test is where experienced project managers differentiate themselves from inexperienced ones. An inexperienced project manager either accepts everything that looks superficially plausible or rejects everything that does not match their preconception. An experienced project manager applies the realism test rigorously but fairly, identifying specific issues with specific evidence rather than rejecting the programme as a whole.
The contractor who anticipates the realism test pre-empts each of the specific checks. They include resource loading. They cross-reference the method statement. They make mitigation visible. They show planned completion at an honest date. They build the programme to survive the realism test on its merits.
The scope compliance check
The fourth ground for non-acceptance is non-compliance with the scope. This is often the most overlooked check by contractors and the easiest for project managers to use as a reason for rejection.
The project manager pulls the scope document and works through any programme-related requirements. Common scope requirements include the scheduling software to be used (Primavera P6, Asta Powerproject, MS Project), the level of detail required (number of activities, work breakdown structure depth), the format of submission (file types, accompanying documents), the frequency of updates (typically four-weekly), the resource information required (labour, plant, materials), specific milestones the programme must show beyond the standard clause 31.2 list, and any specific reporting outputs required (S-curves, histograms, look-ahead programmes).
The project manager checks each scope requirement against the submitted programme. A programme that fails any scope requirement is grounds for non-acceptance on the fourth limb. The contractor who has not read the scope carefully and worked through every programme-related requirement is exposed to a category of rejection that is entirely avoidable.
The most common scope compliance failures are:
Wrong software. The scope specifies Primavera P6, the contractor submits in Asta Powerproject. This is a clear non-compliance.
Missing resource information. The scope requires resource-loaded programmes, the contractor submits without resource loading. The project manager non-accepts on the basis that scope-required information is not shown.
Wrong update frequency or format. The scope specifies a particular update package (programme narrative, baseline comparison, activity list, resource histograms), the contractor submits a subset.
Missing project-specific milestones. The scope requires specific intermediate milestones beyond the standard NEC clause 31.2 list, and these have not been included.
The contractor who reviews the scope at programme inception, lists every programme-related requirement, and builds the programme to address each one explicitly avoids this entire category of rejection. It takes an hour to review the scope properly. It saves weeks of revision cycles.
What gets the programme accepted: the project manager's perspective
The project manager who has worked through the four checks above arrives at a decision. The decision is rarely binary in practice. It is usually a question of how many issues exist and how serious they are.
Programmes that pass all four checks cleanly get accepted. The project manager has no grounds to reject and acceptance is the only contractually permitted response.
Programmes that pass with minor issues typically get accepted with comments. The project manager accepts the programme but flags areas that should improve in subsequent revisions. The contractor benefits from the acceptance and addresses the comments at the next revision under clause 32.
Programmes with significant issues that map clearly to one or more of the four grounds get non-accepted with reasons. The project manager states the specific issues, references the specific grounds, and gives the contractor enough detail to correct the programme. NEC4 clause 13.4 requires the project manager to state reasons in sufficient detail to allow the contractor to correct the submission. A non-acceptance that is too vague is itself a procedural failure.
Programmes that are fundamentally not fit for purpose get non-accepted with significant reasons. This is the worst outcome for the contractor. It indicates structural problems that require substantial rebuilding rather than incremental fixing.
The project manager's preference is usually for option two: acceptance with comments. This keeps the project moving, maintains the accepted programme baseline, and gives both parties a working document to operate from. The project manager who reaches for non-acceptance does so when the issues are too significant to defer, not when minor improvements would be welcome.
The contractor who understands this dynamic targets option two. They build the programme to pass the four checks cleanly, but they also accept that small improvements will always be possible. They submit a programme that the project manager can accept with confidence even if some refinements are obvious. This is significantly more productive than submitting a programme designed to be perfect, finding it has minor issues, and ending up in a non-acceptance cycle that consumes weeks of project time.
The questions the project manager asks throughout
Underlying the four checks is a single question that the project manager asks, in different forms, throughout the review:
Can I accept this programme today?
If the answer is yes, the project manager accepts. If the answer is no, the project manager identifies the specific reasons that map to one of the four grounds. If the project manager cannot articulate a specific ground, they cannot reject, because there is no other contractually valid path.
The contractor who builds the programme to make the project manager answer "yes" to that question on first submission has solved the acceptance problem. The contractor who builds the programme to make the project manager work to find reasons to reject has set themselves up for the rejection cycle that consumes most of the time wasted on unaccepted programmes.
The difference between the two approaches is not technical. It is whether the contractor's planning team has internalised the project manager's review experience and built the programme to pass that experience cleanly. The strongest planning teams do this naturally. They review their own programme through the project manager's eyes before submission. They run the structural checks. They work through clause 31.2 systematically. They apply the realism test honestly. They check scope compliance line by line. By the time the programme is submitted, they have already identified every issue the project manager would have flagged and either fixed it or made a deliberate decision to defend it.
For contractors without dedicated planning resource at this level, specialist NEC programme support provides the discipline as a managed service. The contractor submits a programme that has already passed the project manager's review test before it leaves the planning team. Acceptance follows on the first or second submission rather than the fourth or fifth.
Summary
A contractor's planning team and a project manager review the same NEC programme in different ways. The planning team builds the programme to demonstrate the contractor's plan. The project manager tests the programme against four specific grounds for non-acceptance: practicability, required information, realism, and scope compliance. The two activities should produce the same conclusion. They often do not, because the planning team rarely knows what the project manager actually checks, in what order, and what triggers a rejection at each step.
The project manager's review follows a recognisable sequence. The first thirty seconds check whether the submission is formal, complete, and in the right format. The first review pass tests structural integrity through five specific checks: open ends, logic flow, critical path credibility, constraint discipline, and calendar appropriateness. The clause 31.2 information check works through the contractually required content item by item. The realism test asks whether the programme matches operational reality. The scope compliance check verifies that every programme-related requirement in the scope has been addressed.
The contractor who builds the programme to pass each of these checks before submission catches the issues that produce the most common rejections. The contractor who submits without anticipating the review enters a cycle of revision and rejection that consumes weeks of project time and weakens the commercial baseline for compensation event assessment.
The discipline is not difficult. It requires reading the scope carefully at programme inception, building the programme around the clause 31.2 requirements explicitly, applying the structural checks before submission, and reviewing the programme through the project manager's eyes before it leaves the planning team. Contractors who apply this discipline find that programmes are accepted on first or second submission. Contractors who do not find that even sound programmes fail the review process and that the cumulative effect across multiple revisions is significantly worse than getting acceptance right the first time.
FAQ
What are the four grounds for non-acceptance under NEC clause 31.3?
The contractor's plans are not practicable. The programme does not show the information the contract requires. The programme does not represent the contractor's plans realistically. The programme does not comply with the scope. These are the only valid grounds. A project manager who rejects on any other ground (such as disagreement with sequence or method) is acting outside the contract, and the rejection is itself a compensation event under clause 60.1(9).
What does the project manager check first when reviewing an NEC programme?
The first thirty seconds of review look at submission formality, package completeness, and scope compliance with format requirements. The first substantive pass tests structural integrity: open ends, logic flow, critical path credibility, constraint discipline, and calendar appropriateness. If structural integrity fails, detailed review usually does not proceed. The contractor who submits with structural issues invites non-acceptance before the project manager has even engaged with the substance.
How long does the project manager have to review an NEC programme
Two weeks under clause 31.3 of NEC4 (and NEC3). If the project manager does not respond within two weeks, the contractor may notify the failure under clause 31.3, and if the project manager fails to respond within a further week, the programme is deemed accepted under NEC4. The deemed acceptance mechanism does not exist in NEC3. The article on NEC clause 31 programme acceptance covers the procedural sequence in detail.
What information must an NEC programme show under clause 31.2?
The starting date, access dates, key dates, completion date and contractor's planned completion, the order and timing of operations, time risk allowances, float, information needed from the project manager and others, the work of the employer and others, health and safety requirements, and any other information stated in the contract data. NEC4 added the explicit health and safety requirement and the requirement that the programme be in the form stated in the scope, neither of which appeared in NEC3.
Can the project manager reject a programme because they disagree with the contractor's chosen method?
No. Disagreement with the contractor's chosen method or sequence is not one of the four grounds for non-acceptance under clause 31.3, provided the chosen approach is practicable, realistic, and compliant with the scope. A project manager who rejects on the basis of preferred method rather than contractual ground is acting outside the contract.
What is the realism test under clause 31.3?
The realism test asks whether the programme represents the contractor's actual plans realistically. Specific checks include whether durations are achievable with the resources shown, whether the sequence is physically possible, whether the programme matches the method statement, whether mitigation is visible where recovery is shown, and whether planned completion sits at an honest forecast rather than a politically convenient date. The realism test is the most subjective of the four grounds but follows a recognisable pattern when applied properly.
What scope requirements typically affect NEC programme acceptance?
The scope can specify scheduling software, level of detail (number of activities, WBS depth), submission package contents, update frequency, resource information requirements, project-specific milestones beyond the standard clause 31.2 list, and specific reporting outputs (S-curves, histograms, look-ahead programmes). The contractor should review the scope carefully at programme inception and build the programme to address each scope requirement explicitly. Failure to comply with any scope requirement is grounds for non-acceptance.
What is the strongest position for a contractor in programme acceptance?
A first-submission acceptance with minor comments. This keeps the project moving, maintains the accepted programme baseline for compensation event assessment, and demonstrates planning maturity. Contractors who target acceptance with comments rather than perfect first submission tend to achieve it more often, because they build programmes to pass the four checks cleanly while accepting that small refinements will always be possible.
Need a programme review service before submission?
If programmes are being repeatedly rejected, if the four grounds for non-acceptance are not well understood within the planning team, or if the gap between submission and acceptance is consuming project time, specialist NEC programme support reviews the programme through the project manager's eyes before submission and identifies every issue that would otherwise produce a rejection.
