What Clause 15 actually requires
Clause 15 of NEC4 ECC sits within the early warning provisions, and it is more demanding than most practitioners appreciate until a dispute forces them to read it carefully. The contractor is required to give an early warning as soon as they become aware of any matter that could increase the total of the prices, delay planned completion, delay a Key Date, or impair the performance of the works in use. That obligation is not limited to discrete risk events — it covers any matter, including programme-related risk that the contractor has identified but not yet notified.
The obligation runs in both directions. The project manager has a parallel early warning obligation. Clause 15.1 requires the project manager to give early warning of anything that could change the Accepted Programme, and that includes matters that might constrain the contractor's ability to work as planned — access restrictions, client-supplied information delays, third-party interfaces that are running late. Programme risk under NEC4 is not something that sits with one party; it is a shared early-warning responsibility.
What makes Clause 15 different from a simple notification provision is the way it connects to the programme and to the compensation event machinery. An early warning gives rise to a risk reduction meeting if either party requests one. The outputs of that meeting — agreed actions, revised assumptions — feed back into the programme, which must be updated under Clause 32 to reflect any changes in the contractor's intentions. The early warning is not a standalone administrative act; it is the start of a programme management loop that the contract expects to run continuously throughout the project.
The practical test is whether the programme — as accepted at any point in time — genuinely reflects the risk the contractor has identified. A contractor who has given an early warning about a potential six-week delay but whose Accepted Programme still shows planned completion on the original date has not completed the loop. The early warning has been filed; the programme has not been updated to reflect the risk. That gap matters commercially, because it affects how any subsequent compensation event will be assessed.
Why most programmes fail it silently
The most common Clause 15 failure mode is not a contractor who ignores the obligation — it is a contractor who complies with the letter of it while the programme tells a different story. Early warning notices are issued. Risk reduction meetings are minuted. And the Accepted Programme continues to show planned completion exactly on the contractual completion date, with no float, no time risk allowances, and no reflection of the risks the early warnings describe.
This happens because programme and early warning administration are often managed by different people in different systems. The commercial team tracks early warnings in a correspondence register. The planning team maintains the programme in P6 or Asta. The two systems do not talk to each other and nobody has explicit responsibility for making sure that the risks described in early warning notices are visible in the programme. The result is a paper trail that looks compliant and a programme that gives no information about the risks the project actually carries.
The silence matters at the point of a compensation event assessment. Under Clause 63, the assessment of a compensation event that causes delay is measured against the Accepted Programme. If the programme contains no time risk allowances and shows the project running exactly to the contractual completion date, a compensation event that delays any critical activity by a single day will appear to push the completion date by a single day. There is no buffer visible in the programme to absorb the impact. The contractor has handed the project manager a weapon: a programme that overstates the sensitivity of the project to any event.
The inverse problem is equally common. Some contractors inflate time risk allowances across the programme to build in a buffer that protects them in compensation event assessments, without those TRAs being justified by identified risks. A TRA that is not connected to a specific, named risk is just contingency disguised as schedule risk provision. NEC4 requires TRAs to be shown explicitly and their basis to be capable of explanation. A programme reviewer who asks the contractor to explain the basis for each TRA will quickly distinguish genuine risk provision from fabricated float.
Float types and what they tell you
NEC4 does not use the term "total float" in the same way that scheduling practice does, but understanding the different types of float in an NEC programme is essential for interpreting what the programme is actually saying about schedule risk. The contract draws a distinction between planned completion — the date the contractor intends to finish — and the contractual completion date. The gap between those two dates is, in scheduling terms, project float: slack in the programme that exists because the contractor has planned to finish ahead of contract.
Total float is calculated by the scheduling software for each activity: the amount of time an activity can be delayed without affecting the planned completion date. Total float on the critical path is zero by definition. Near-critical activities — those with small positive float — are the early warning indicators for which parts of the programme are most sensitive to delay. A good programme review will look at the distribution of total float across the schedule: a healthy programme has a realistic critical path with genuine near-critical paths that reflect the actual structure of the work, and the float distribution should be explainable in terms of the project logic.
Free float — the time an activity can slip without affecting any of its successors — is less commonly discussed but relevant for resource planning and for identifying activities where the contractor has genuine scheduling discretion. An activity with high free float can be delayed or rescheduled without triggering a knock-on effect, which means it is a candidate for resource smoothing and is not a schedule risk driver. Activities with zero free float, by contrast, must finish on time or they will immediately delay downstream work, regardless of whether the project has total float to absorb that delay.
Time risk allowances are the contractor's explicit schedule risk provision — a distinct category from float, included in the programme to represent the contractor's estimate of schedule uncertainty on specific activities or phases. Where a TRA is properly constructed, it is tied to a specific identified risk or to a class of uncertainty (weather, third-party dependency, productivity variability) and is sized proportionally to the estimated impact. The NEC4 expectation is that TRAs are visible, labelled, and connected to the risks that justify them. A programme with no TRAs, or with TRAs that are identical in size across all activities regardless of risk profile, should not be accepted without challenge.
Compensation events and schedule impact assessment
The connection between early warnings and compensation events is direct. A compensation event that is not preceded by an early warning does not lose its entitlement — NEC4 removed the deeming provision in some earlier editions that penalised late notification — but the early warning process shapes the quality of the compensation event assessment, because the best evidence about programme impact is generated close in time to the event, not months later when a retrospective assessment has to reconstruct what happened.
Assessing the schedule impact of a compensation event requires a time impact analysis: inserting the additional work representing the compensation event into the Accepted Programme, running the schedule logic, and showing what effect the insertion has on planned completion. The assessment is prospective — it is what an experienced contractor would have expected at the time of the event, not what actually happened afterwards. This prospective standard means that a well-maintained Accepted Programme, reflecting genuine risk through TRAs and realistic logic, will produce a fairer assessment than a thin programme with compressed durations and no risk provision.
The timing of programme updates matters enormously. If the Accepted Programme is two or three revisions out of date because the project manager has been slow to respond to submissions, the compensation event assessment will be based on a programme that does not reflect the current state of the project. Activities that have been completed will still appear as planned. Risks that have crystallised will not be reflected. The programme will not accurately model the sequencing of remaining work. An assessment based on this programme will either understate the true impact (if it fails to capture dependencies in the current working plan) or overstate it (if completed activities are treated as if they still need to happen).
The project manager's obligation to respond to programme submissions within the timescales in the contract is not administrative box-ticking — it is a precondition for reliable compensation event assessments. A pattern of late responses to programme submissions, or repeated rejections without adequate explanation, creates commercial exposure for the client: the assessment will be based on whatever programme was last accepted, regardless of how stale it is. Project managers who deprioritise programme acceptance will find that this choice surfaces in disagreements about compensation event quantum at exactly the moment when the project is already under commercial pressure.
What a defensible Clause 15 programme looks like
A programme that satisfies Clause 15's intent — rather than simply its administrative letter — has four qualities that are recognisable to an experienced reviewer. First, it is current: the data date is aligned with the current reporting period, progress has been recorded against activities that are underway, and the forecast logic reflects the contractor's genuine intentions rather than the original plan copied forward. Currency is the most basic test and the most frequently failed.
Second, the programme is honest about risk. TRAs are visible, labelled, and proportionate to the identified risks. Early warnings that describe schedule risk are reflected in the programme — either through TRAs on the affected activities or through revised logic that shows how the risk affects sequencing. Where an early warning has been issued but the programme has not been updated to reflect it, there should be a clear explanation of why the programme does not yet show the impact: for example, because the risk is still being assessed, or because a mitigation plan is in development and will be reflected in the next revision.
Third, the critical path is genuine. The activities on the critical path should be the activities that a knowledgeable observer would expect to drive the programme: the ones that are technically dependent on each other, that involve long-lead procurement, or that require scarce resources. A critical path composed of activities with artificially constrained logic, or one that conveniently runs through activities where the project has the most commercial leverage, is not a genuine critical path. Experienced project managers and planners can tell the difference within minutes of reviewing the logic.
Fourth, the programme connects to other project controls outputs. The programme's planned completion date should be consistent with the cost forecast. The TRAs should appear as schedule risks in the risk register. The early warning log should reference the activities affected by each notified risk. These connections are not bureaucratic tidiness — they are evidence that the project controls function is integrated rather than producing siloed outputs for separate audiences. A programme that is consistent with the rest of the project controls picture is a programme that can be defended in a compensation event dispute or a gateway review. A programme that exists in isolation, disconnected from the cost plan and the risk register, is a document that tells part of the story of the project and can be used to support almost any argument the author wants to make.