Scope of this guide and the contract it refers to
This guide covers schedule risk under the NEC4 Engineering and Construction Contract (ECC), 2017, as amended in January 2019 and October 2020. Clause numbers are ECC numbers and differ in other NEC4 contracts. Many clients amend the programme, early warning and compensation event clauses by Z clauses, so check the Contract Data and the Z clause schedule before relying on anything here. Check any amendment later than October 2020 against your own copy.
The guide does two jobs. It sets out what the contract requires of the programme, float and time risk allowances, and how compensation events are assessed against them. It then explains how a quantitative schedule risk analysis (QSRA) uses the Accepted Programme, what the programme gives a QSRA, and what it lacks. NEC4 does not require a QSRA. It requires time risk allowances to be shown and says nothing about how they are sized.
What clause 31 requires the programme to show
Where the Contract Data does not identify a programme, the Contractor submits a first programme for acceptance within the period stated in the Contract Data (clause 31.1). If the Contractor has not submitted a first programme showing the information the contract requires, the Project Manager may retain a quarter of the Price for Work Done to Date until it does (clause 50.3). Where the Contract Data identifies a programme, that programme is already the Accepted Programme.
Clause 31.2 lists what a programme submitted for acceptance must show. In summary: the starting date, access dates, Key Dates and planned Completion; the order and timing of the operations the Contractor plans to carry out; the order and timing of the work of the Client and Others, as last agreed or as stated in the Scope; the dates the Contractor plans to meet each Condition stated for a Key Date; the dates the Contractor needs access, acceptances, Plant and Materials, information and other things from the Client; provisions for float, time risk allowances, health and safety requirements and the procedures in the contract; and a statement of how the Contractor plans to do the work, identifying principal equipment and other resources. Resource and cost forecasts are not on the list.
The Project Manager replies within two weeks, either accepting the programme or giving reasons for not accepting it (clause 31.3). There are four grounds: 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. If the Project Manager has not replied in time, the Contractor notifies the failure and, if there is still no reply within one further week, the programme is treated as accepted.
Challenging a non-acceptance
A non-acceptance outside the four grounds is not valid. Thin logic, an absence of float or activities without resources are grounds only if they make the plans impracticable or unrealistic, or leave out information that clause 31.2 requires. A Project Manager who wants more from the programme should say which ground applies and which part of the programme triggers it.
The Contractor's response is to answer each stated ground in writing, correct what is a fair point, and resubmit. Resubmitting the same programme invites the same reply. If the Project Manager is late, the failure to reply is a compensation event under clause 60.1(6), which the Contractor notifies under clause 61.3. A non-acceptance that the Contractor believes is invalid is not itself a compensation event. It is a disagreement, and if it cannot be settled it goes to the dispute resolution clauses (Option W1 or W2), not through the compensation event process.
Float, time risk allowances and planned Completion
Three things are easy to confuse. A time risk allowance (TRA) is time the Contractor includes in the programme for risks that are the Contractor's to carry. Float is spare time in the programme. Terminal float is the gap between planned Completion shown on the Accepted Programme and the Completion Date. Clause 31.2 requires the programme to make provision for float and to show TRAs. It does not say who owns float, and NEC4 has no float-ownership clause.
The position that follows from clause 63.5 is this. Float and TRAs are shown in the programme under 31.2. A compensation event is assessed against the Accepted Programme, and the Completion Date and Key Dates move by the length of time that, due to the compensation event, planned Completion is later than planned Completion on the Accepted Programme. Three consequences follow. First, the Contractor's TRAs stay in the programme, because the compensation event is added to the programme and does not draw them down. Second, float on non-critical paths may be consumed by a compensation event, and if it is all consumed without moving planned Completion, there is no time effect. Third, terminal float stays with the Contractor, because both dates move by the same amount. The Client cannot treat the gap between planned Completion and the Completion Date as a margin for its own delays.
Terminal float is protected only against Client risk events. Delay the Contractor causes itself moves planned Completion later and uses up terminal float without moving the Completion Date. A risk that lands within its TRA does not move planned Completion at all. The SCL Delay and Disruption Protocol and other forms take different positions on float, so do not carry assumptions across from them.
One calculation point. Total float on the critical path is zero only where the scheduling software calculates float to planned Completion. If the finish is constrained to the Completion Date, critical-path float equals terminal float. State which basis the programme uses, because it changes how every float figure reads.
How compensation events are assessed against the programme
The effect on the Prices is assessed on the actual Defined Cost of work already done and the forecast Defined Cost of work not yet done, plus the resulting Fee (clause 63.1). The effect on time is assessed under clause 63.5, as above. Where a compensation event changes the programme for the remaining work, the Contractor's quotation includes a revised programme (clause 62.2). Time impact analysis is the usual industry name for inserting the compensation event work as a fragnet and reading the change in planned Completion. NEC4 does not use that term.
If there is no Accepted Programme, or the Contractor has not submitted a revised programme the contract requires, the Project Manager uses its own assessment of the programme (clause 64.2). That is the main commercial cost of a poor programme. The Contractor loses control of the baseline its time entitlement is measured against. Once a compensation event is implemented, its assessment is not revised because the outcome differs from the forecast (clause 65.2), so the baseline matters at the time of assessment, not afterwards.
Worked example. The Completion Date is 120 days from the starting date. The Accepted Programme shows planned Completion at day 110, so terminal float is 10 days. A critical-path TRA of 15 days sits in the programme.
Event A delays the critical path by 12 days. Planned Completion moves to day 122, so the Completion Date moves to day 132. Terminal float is still 10 days and the 15-day TRA is untouched.
Event B delays an activity with 8 days of float by 6 days. Planned Completion does not move, so there is no change to the Completion Date. 2 days of float remain. The cost effect is still assessed under 63.1.
Event C, taken in place of Event B, delays the same activity by 11 days. It uses its 8 days of float and then 3 days reach planned Completion. Planned Completion moves to day 113 and the Completion Date to day 123.
A programme with no TRAs and planned Completion equal to the Completion Date does not make these results worse for the Client or better for the Contractor. A one-day critical delay is one day either way. The real weakness is elsewhere. The Contractor has no cushion for its own risks and no terminal float, and it has a weaker evidential position if the Project Manager argues that the delayed activity was not critical.
Revised programmes and the Early Warning Register
The Contractor submits a revised programme at the intervals stated in the Contract Data, when the Project Manager instructs it, and when the Contractor chooses to (clause 32). Those are the only triggers. A revised programme shows the actual progress achieved and its effect on the remaining work, including the effects of implemented compensation events and of notified early warning matters, and how the Contractor plans to deal with delays and Defects (clause 32.1). Clause 32 is covered in detail in the linked guide.
Clause 32.1 is the contractual link between the Early Warning Register and the programme. Clause 15 requires both parties to give an early warning of any matter that could increase the total of the Prices, delay Completion, delay meeting a Key Date, or impair the performance of the works in use, and either party may instruct the other to attend an early warning meeting. A Client-side matter, such as late access or late information, is notified on the same basis as a Contractor-side one. If the Contractor fails to give a warning that an experienced contractor would have given, the Project Manager may say so when it notifies a compensation event, and the event is then assessed as if the warning had been given (clauses 61.5 and 63.7). The compensation event notification time bar is eight weeks (clause 61.3).
A common failure is a paper trail that looks compliant. Early warnings are logged in a correspondence register and early warning meetings are minuted, while the programme shows planned Completion on the Completion Date with no TRAs and no sign of the matters notified. The cause is usually administrative. The commercial team keeps the register, the planning team keeps the programme, and nobody owns the link between them. The fix is a single reference: each open early warning that could delay Completion or a Key Date carries the activity IDs it affects, and the next revision shows its effect.
A Contractor-risk matter is reflected in a TRA on the affected activities or in changed logic. A Client-risk matter is not reflected in a TRA, because if it happens it will be a compensation event and the time is assessed then. Putting Client-risk time into a TRA is double protection that a Project Manager can fairly question under the realistic-plans ground in 31.3.
What the Accepted Programme gives a QSRA
When a Client commissions a QSRA on an NEC contract, the Accepted Programme is the natural base model, because it is the only programme both parties have agreed. It gives the analyst:
The Contractor's stated method and sequence, with Key Dates, access dates and the Client's dependencies already in the logic. The planned Completion and the Completion Date, so results can be read against the two dates that matter contractually. The TRAs and float, so the Contractor's own view of its risk is on the page. A baseline that has passed the clause 31.3 test, and updates under clause 32 that carry actual progress, so a status date and remaining durations are available.
That is a good starting point. It is not a model ready to run.
What the Accepted Programme lacks
The clause 31.3 test confirms that the plans are practicable and realistically represented. It is not a schedule quality check. A programme can be accepted and still have missing predecessors, hard constraints or summary-level activities that a simulation cannot use. AACE International Recommended Practice 64R-11 CPM Schedule Risk Modeling and Analysis: Special Considerations sets out why model integrity must be established before simulation. Widely used schedule health checks such as the DCMA 14-point assessment (missing logic and hard constraints, each at or below 5 per cent of tasks, for example) are a sensible first pass.
Beyond logic quality, the programme lacks the inputs a QSRA exists to supply. Each TRA is a single number, so there are no duration ranges. The risks behind the TRAs are not quantified, because the Early Warning Register records matters but not probabilities or impacts. There is no correlation between activities that share a driver, such as weather or one supplier. The programme does not separate Contractor risk from Client risk, which matters because only Contractor risk belongs in a TRA. And NEC4 gives no confidence level for planned Completion: nothing in the contract says whether it is a P50, a P80 or a hope.
The treatment of existing TRAs needs a decision. If they are left in the model and the model also carries the risk, the same time is counted twice. On a QSRA we take the TRAs out of the base, model Contractor and Client risks as separate groups, and compare the Contractor-risk result with the TRAs the Contractor has shown.
Sizing time risk allowances from a QSRA
Worked example, with illustrative figures. The Accepted Programme is re-based with its TRAs removed and the deterministic finish is taken as day 0. The QSRA carries duration ranges and discrete risks that are the Contractor's to carry, and excludes Client-risk events because those are compensation events. The results are a P50 of 18 working days after day 0 and a P80 of 34 working days after day 0.
The Contractor sets TRAs totalling 18 working days, a P50 position, and spreads them over the activities that drive the result, labelling each with the risk ID from the register. Planned Completion is day 0 plus 18. The Completion Date is day 0 plus 34, so terminal float is 34 minus 18 = 16 working days. If the Completion Date were instead day 0 plus 25, terminal float would be 7 working days, and the confidence of meeting the Completion Date would be read from the model's cumulative curve, somewhere between P50 and P80.
Choosing the percentile is a commercial decision for the Contractor. Planning at P50 leaves an even chance of using the terminal float on its own risks. Planning at P80 leaves little or none, but a planned Completion that far from day 0 may look unambitious to the Client. Whichever is chosen, state it in the programme notes so that a later reader knows what the TRAs mean. A Client reading the programme can then compare the TRAs to the QSRA and ask for the basis if they differ, though the only grounds for non-acceptance remain those in clause 31.3.
Programme review checklist
Each of these can be answered pass or fail from the programme file and the register.
1. Current. The data date falls in the current reporting period, progress is recorded, and a revision has been submitted at the Contract Data interval.
2. Early warnings linked. Every open early warning that could delay Completion or a Key Date carries activity IDs, and the latest revision shows its effect (clause 32.1).
3. TRAs mapped. Every TRA is labelled and tied to a risk ID or a stated class of uncertainty, and no Client-risk time sits inside a TRA.
4. Logic sound. Missing predecessors and successors are within 5 per cent of tasks, hard constraints are within 5 per cent, and the critical path is driven by logic and not by constraints.
5. Dates stated. The programme states planned Completion, the Completion Date, terminal float and the float calculation basis.
6. Consistent. The TRAs appear in the risk register as schedule risks, and planned Completion is consistent with the cost forecast.
No clause requires an explanation of each TRA, so checks 3 and 6 are good practice rather than contract compliance. A failure on them is not a ground for non-acceptance unless it brings the programme within one of the four grounds in clause 31.3.