Why NEC4 and schedule risk are inseparable
NEC4 — the fourth edition of the New Engineering Contract suite — is built around the Accepted Programme in a way that no earlier standard form contract was. Under NEC3 and NEC4, the programme is not just a planning document; it is the commercial engine of the contract. It drives compensation event assessments, it determines what float belongs to whom, it is the reference against which delay is measured, and it is the mechanism by which the contractor demonstrates entitlement to additional time and money. Understanding how NEC4 treats the programme is not optional for practitioners on NEC contracts — it is the foundation of commercial management.
The key risk for both parties is misunderstanding what the contract requires and what it protects. Contractors who submit thin, constraint-heavy programmes risk having them rejected — and then running the project without an Accepted Programme, which means compensation events must be assessed on assumptions the project manager makes, almost always to the contractor's detriment. Project managers who reject programmes for the wrong reasons — or who accept substandard programmes under time pressure — create problems downstream when those programmes are used as the basis for compensation event assessments.
This guide covers the main contractual provisions, the practical implications for schedule quality and risk, and the most common errors on both sides of the table. It is not a substitute for reading the contract — clause numbers are given throughout, and the full NEC4 Engineering and Construction Contract should be read alongside this guide.
Clauses 31 and 32: programme submission and acceptance
Clause 31 sets out what the Accepted Programme must contain. Under NEC4 ECC, the programme must show: the starting date, access dates, and Key Dates; planned completion; the order and timing of the operations the contractor plans to do; the order and timing of work by the client and others; the dates when the contractor needs information, decisions, and resources from the client; dates when work must meet the Accepted Programme; float; time risk allowances; health and safety requirements; and the contractor's resource and cost forecasts. This is a substantially more detailed requirement than most contractors initially appreciate.
Time risk allowances (TRAs) are the contractor's explicit acknowledgement of schedule uncertainty. They are distinct from float: TRA is the contractor's own risk provision for duration uncertainty, while float is the scheduling headroom that arises from the difference between the planned completion and the contractual completion date. The contract requires TRAs to be shown explicitly — they are not just embedded in activity durations. A programme that has no identifiable TRAs is arguably non-compliant with Clause 31, and a project manager who accepts it without raising this is storing up difficulties for later.
Clause 32 covers the contractor's obligation to revise the programme. The contractor must submit a revised programme when the project manager instructs it, when the programme no longer shows the actual progress, and in any event at intervals no longer than those stated in the Contract Data. Most contracts specify four-weekly programme revisions. A contractor who is not regularly revising and resubmitting the programme is not fulfilling their contractual obligations — and project managers should be issuing early warning notices and instructions to submit rather than accepting the status quo.
The Accepted Programme versus the Working Schedule
A common source of confusion on NEC projects is the difference between the Accepted Programme and what the contractor actually plans to do. The Accepted Programme is the contractually agreed reference document — the one that has been submitted, reviewed, and formally accepted by the project manager. The Working Schedule is the contractor's day-to-day operational tool, which may be more detailed, more current, or structured differently from the Accepted Programme.
The Accepted Programme need not be identical to the working schedule, but it should not diverge significantly from it either. A programme submitted for acceptance that bears no resemblance to how the contractor actually intends to work is a misleading document — and one that will produce incorrect compensation event assessments when events are measured against it. Contractors sometimes submit simplified or idealistic programmes for acceptance while managing internally to a detailed working schedule. This practice is commercially dangerous: when a compensation event arises, the assessment will be based on the Accepted Programme, not the working schedule.
The relationship between the two documents has become clearer in NEC4, which strengthens the obligation to show actual methods and sequences. Project managers are entitled to reject a programme that does not reflect the contractor's intended approach. If a programme shows a simple sequential construction sequence that the contractor intends to execute as a heavily overlapping, phased operation, it does not meet the Clause 31 requirements. The test is: if this programme were used to assess a compensation event today, would it produce a fair and realistic result? If not, the programme needs to be revised before it can be accepted.
Float allocation: who owns it and why it matters
Float — the difference between the planned completion date shown in the Accepted Programme and the contractual completion date — is one of the most commercially significant aspects of NEC4. Under NEC4 (and its predecessors), float belongs to the project, not to either party exclusively. This means that the contractor cannot "use up" the float on a compensation event to avoid showing a delay to the completion date, and the client cannot claim that the contractor has no entitlement to time because float exists. Float is shared project resource.
The practical implication is in compensation event assessments. Under Clause 63, a compensation event that affects the critical path of the Accepted Programme — that is, it delays the programme completion date — gives rise to a Planned Completion delay, and the contractor is entitled to an extension of time equal to the delay to planned completion (not just to the contractual completion date). If the programme shows float between planned completion and contractual completion, a compensation event that is critical to the planned completion but does not extend beyond the contractual completion date still gives rise to an extension — because the delay has consumed the contractor's own float allowance.
This is counterintuitive for project managers trained in other contract forms, where extension of time claims are typically measured against the contractual completion date rather than the planned completion. Under NEC4, the Planned Completion date in the Accepted Programme is the reference. Float is the contractor's property in the sense that compensation events should not be assessed in a way that forces the contractor to use their float to absorb the impact of events the client is responsible for. Contractors who understand this will plan programmes that make planned completion visible and distinct from contractual completion. Project managers who do not understand it will under-value compensation events and create disputes.
Compensation events and programme impact: Clause 63
Clause 63 governs how compensation events are assessed. The key point for programme management is that the assessment must be based on the effect the compensation event has on the Accepted Programme — specifically, the effect on the planned completion date and on defined costs. This requires a valid Accepted Programme to be in place: if there is no Accepted Programme, the project manager makes assumptions about the programme, and those assumptions will almost always be less favourable to the contractor than the contractor's own plan would have been.
The compensation event assessment process requires the contractor to submit a quotation showing both the time and cost impact. The time impact is assessed by inserting the compensation event work into the Accepted Programme and calculating how it affects planned completion. This is called a Time Impact Analysis (TIA). A well-constructed TIA shows the fragnet — the additional activities representing the compensation event work — inserted at the appropriate point in the programme, with revised logic, and demonstrates the resulting impact on planned completion.
A common mistake by contractors is submitting time impact analyses based on the working schedule rather than the Accepted Programme, or on a programme revision that has not been formally accepted. The assessment must be based on the last Accepted Programme at the time of the event. If the contractor has been submitting revised programmes that have not been accepted — because the project manager has been slow to respond or has rejected them on questionable grounds — then the compensation event assessment may be based on a programme that is months out of date, which can significantly understate the true impact. Keeping the Accepted Programme current is not just a contractual obligation — it is a commercial imperative.
Clause 63 also requires that compensation events are assessed at the time they occur, not in hindsight. The standard is what an experienced contractor would have expected the impact to be, using the information available at the time. This means the assessment is prospective, not retrospective — you cannot re-assess a compensation event in light of what actually happened if the actual outcome turned out worse than the forecast. This has important implications for risk: the contractor carries the risk of the actual impact being worse than the assessed impact, and the client carries the risk of it being better.
Common mistakes on both sides
The most common contractor mistake is submitting programmes that do not meet the Clause 31 requirements and then being surprised when the project manager rejects them. Thin logic, missing TRAs, activities without resources, and programmes that show completion exactly on the contractual completion date with no float are all reasons for rejection. The solution is to invest in proper programme preparation at the outset. A programme that takes two weeks to build properly is far cheaper than six months of dispute over a compensation event assessed against a poor baseline.
The most common project manager mistake is accepting programmes that are not fit for purpose, either because of time pressure or because of a reluctance to engage in the administrative process of rejection and resubmission. A programme that gets accepted under pressure and then proves inadequate for compensation event assessment is a much bigger problem than the delay caused by properly rejecting and requiring resubmission. Acceptance of a substandard programme is not a shortcut — it is a deferred problem.
Both parties frequently confuse the programme submission timescales. Under Clause 31, the contractor must submit a first programme within the period stated in the Contract Data (typically 4 weeks from the starting date). If no period is stated, the contract gives no time limit. Both parties should ensure the Contract Data specifies this period explicitly. Missing the submission deadline does not excuse the contractor — the project manager can instruct a submission — but it does mean the contract is operating without an Accepted Programme for the opening weeks, which is a commercial risk for the contractor.
A subtler mistake is treating TRAs as contingency to be drawn down rather than as explicit risk provisions. Some contractors strip TRAs from programmes to make them look more efficient. A programme with no TRAs signals either that the contractor has not thought about schedule risk or that they have buried their risk provision in inflated activity durations — neither of which is the intent of the NEC4 programme requirements. TRAs should be visible, labelled, and justified.
When to push back on programme rejection
Not all programme rejections are legitimate. The project manager can reject a programme only on the grounds listed in Clause 31.3: that the contractor's plans are not practicable, that it does not show the information the contract requires, that it does not represent the contractor's intentions, or that it does not comply with the Works Information. A project manager who rejects a programme on grounds other than these is acting outside their authority under the contract.
If a programme is rejected and the contractor believes the rejection is unjustified, they should respond in writing, identifying the specific grounds the project manager has cited and explaining why each ground does not apply. The contractor should not simply resubmit the same programme — that will result in the same rejection. They should either address the legitimate points (if there are any) or formally dispute the rejection through the compensation event mechanism.
An unjustified rejection of a programme is itself a compensation event under Clause 60.1(6) — the project manager has failed to reply to a communication within the required time, or has taken an action in breach of the contract. The contractor should notify this as a compensation event. This is not an aggressive commercial move — it is exactly how the NEC contract intends disputes about programme acceptance to be resolved. The early warning notice process and the adjudication provisions exist precisely so these disagreements can be addressed promptly rather than accumulating as unresolved tensions.
The broader lesson is that programme management under NEC4 is a continuous, disciplined process, not a one-off deliverable. The Accepted Programme must be kept current, TRAs must be maintained and visible, and compensation events must be assessed against a live and accurate programme. Contractors and project managers who treat the programme as an administrative burden rather than as the commercial engine of the contract will find themselves at a systematic disadvantage when things go wrong — which, on any real project, they eventually will.