5 Time Risk Allowance Mistakes That Undermine NEC Programme Acceptance

Time Risk Allowances are not padding. Under NEC, they are part of realistic planning. Clause 31.2 requires the contractor’s programme to show float and time risk allowances, and the NEC guidance is clear that where reasonable TRA is missing, unclear or not shown properly, the Project Manager has grounds not to accept the programme because it does not represent the contractor’s plans realistically or does not show the information the contract requires.

That sounds technical, but the commercial problem is simple. A weak TRA approach creates avoidable friction at exactly the points where contractors need credibility most: programme acceptance, monthly updates, and compensation event assessment. It is the same reason weak programme logic and weak contract administration turn into bigger disputes later.

If you want the accepted programme to work as a real control tool, not just a submission file, these are the five mistakes to avoid.

Mistake no 1: Leaving TRA out of the programme altogether

The first mistake is the most obvious one. The programme is submitted with logic, dates and activities, but no visible provision for contractor-risk time. Under NEC, that is not a minor drafting issue. Clause 31.2 requires float and time risk allowances to be shown, and the NEC guidance says a programme without them may properly be rejected because it does not show all the information the contract requires and does not represent the contractor’s plan realistically.

This matters because once TRA is absent, the whole programme starts to look more optimistic than operational. The Project Manager is left asking whether the submission is a real delivery plan or just a best-case sequence. That weakens confidence before the first update cycle even starts. It also makes later discussions on compensation events harder, because the starting point was never transparently realistic in the first place.

Mistake no 2: Lumping TRA at the end of the programme

A very common mistake is to carry time risk as a single block near planned Completion. It may feel tidy, but NEC guidance treats that as a poor approach because it is not logical and is misrepresentative. Time risk allowances should sit within the operations they actually relate to, so their reasonableness can be understood and discussed.

Why is this such a problem? Because a lumped buffer says almost nothing about how the works will actually be delivered. It does not tell the Project Manager which operations are genuinely exposed. It does not help a reviewer understand where the contractor has made realistic allowance. And it makes the critical path story less believable because the contingency is detached from the operations carrying the risk.

Good NEC programmes do not hide uncertainty in one soft block at the back end. They distribute TRA where the risk lives. If weather affects civils, put the allowance there. If testing and commissioning carry uncertainty, show it there. If a procurement package has real timing risk, reflect it in that sequence. That is what makes the programme read like a delivery strategy rather than a negotiation position.

Mistake no 3: Using generic percentages instead of reasoned allowances

Another mistake is applying a broad-brush percentage uplift across activities without any operational logic. The NEC guidance is clear that there is no exact science for TRA, but there still needs to be logic. Allowances should not be a generic percentage or a guess. They should be measurable, explainable and capable of being verified against the nature of the operation.

This is where many programmes lose credibility. A planner may think a flat uplift is commercially safe, but to a reviewer it often looks lazy. It suggests that the team has not actually worked through where risk sits in the sequence and how much time is reasonably needed to deal with it. That makes programme acceptance harder and later arguments over change more vulnerable.

The practical test is simple. For each operation that includes TRA, you should be able to explain what the contractor-risk exposure is, why it is not already covered elsewhere, and why that level of allowance is reasonable. If that explanation cannot be made clearly, the allowance is probably too vague.

Mistake no 4: Treating TRA as static instead of reviewing it in updates

Time Risk Allowances are not a one-off tender exercise. NEC guidance says they are variable. If conditions change, the allowance may need to change too. If the relevant risk never occurred, the appropriateness of the original allowance should be discussed and reflected through the next programme update.

This is where weak update discipline causes trouble. Some contractors leave historic allowance buried in activities that are complete or no longer exposed. Others strip allowance too aggressively and issue updates that look neat but no longer reflect delivery reality. In both cases, the programme becomes less trustworthy over time, which is exactly the opposite of what the accepted programme is meant to achieve.

A stronger monthly cycle reviews TRA as part of normal programme maintenance. If the risk did not happen, the programme should show that gain. If the risk profile has changed, the update should show that too. That keeps planned Completion credible and stops the programme becoming either padded or artificially optimistic.

Mistake no 5: Treating TRA as static instead of reviewing it in updates

TRA, float and terminal float are not the same thing, and contractors get into trouble when the programme blurs them. The NEC guidance explains that TRA is the contractor’s provision for events at its risk and that it should remain in the assessment of delay to planned Completion caused by a compensation event. It also points to clause 63.8, which includes risk allowances for cost and time for matters with a significant chance of occurring and which are not compensation events.

That issue sits close to the same territory discussed in NEC and Contractor’s Float, an adjudication-related note originally published on the NEC-Adjudicators website. It is a useful reminder that where contingency sits in the programme, and whether it is tied to particular operations or shown as float before Completion, can materially affect how delay is argued under NEC.

In practice, this is where contractors can weaken their own CE position. If the accepted programme hid risk badly, or if durations and allowances were overstated without explanation, the compensation event assessment starts from a weak baseline. If the programme showed realistic and explainable TRA from the outset, the contractor is in a much stronger position when assessing prospective delay. That is why the programme and the CE process should never be treated as separate disciplines.

What good NEC Programme looks like

A good NEC programme does not try to look risk-free. It shows the work sequence clearly, identifies realistic contractor-risk time, and keeps that logic reviewable as the job moves forward. That gives the Project Manager a better basis for acceptance and gives the contractor a better basis for defending the programme later when progress slips or change lands.

If your programmes keep attracting acceptance comments, repeated revisions or weak confidence from project teams, the issue is often not software. It is that the programme does not yet meet a disciplined NEC submission standard. That is exactly what our NEC Programme Compliance (Clause 31/32) service is built to fix, by tightening logic, structure, narrative alignment, update discipline and overall submission quality.

What it means for contractors

In NEC, Time Risk Allowances are not a side note. They sit inside the commercial mechanics of the programme. Clause 31.2 requires the contractor’s programme to show both float and time risk allowances, and the NEC guidance says the Project Manager should not accept a programme without reasonable allowance because it does not represent the contractor’s plans realistically. It also says those allowances should be attached to the duration of specific activities or parts of the works, not hidden as a vague overall contingency.

For contractors, that means TRA affects more than acceptance. It affects whether the accepted programme looks believable in progress meetings, whether the narrative aligns with the logic, and whether later compensation event assessments start from a credible baseline. That is why this is not just a planning detail. It is a contract control issue.

Where that discipline is weak, issues usually show up as programme acceptance comments, unclear update cycles and avoidable friction on change, which is exactly where NEC Programme Compliance under Clause 31/32 becomes commercially important.

FAQ

What is a Time Risk Allowance in NEC?

A Time Risk Allowance is the contractor’s allowance in the programme for events that are at the contractor’s risk. Under NEC Clause 31.2, the programme submitted for acceptance must show provisions for float and time risk allowances.

Can a Project Manager reject a programme without reasonable TRA?

Yes. NEC guidance says the Project Manager should not accept a programme without reasonable time risk allowances because it does not represent the contractor’s plans realistically, and if no TRAs are shown at all it also fails to show all the information the contract requires.

Are Time Risk Allowances the same as float?

No. NEC treats float and time risk allowances as separate things in Clause 31.2. The distinction matters commercially because allowance attached to specific operations is not the same as general terminal float near Completion.

Do Time Risk Allowances matter when assessing compensation events?

Yes. NEC guidance says Time Risk Allowances should be retained when assessing delay to planned Completion caused by a compensation event, and Clause 63.8 also refers to risk allowances for time and cost for matters that have a significant chance of occurring and are not compensation events.

---

Need stronger programme control on a live project?

If you need clearer programmes or contract-aligned planning support, start with a practical discussion about your project.