NEC Clause 15 Early Warnings: A Quantified Register That Reduces Delay

NEC Clause 15 early warnings are meant to be boring. Not in the “ignore it” way, but in the “this is a dependable weekly control system” way. On a lot of jobs, the Early Warning Register turns into theatre: a long list of issues, discussed politely, then parked until they become delay, cost, and arguments.

Clause 15 is simple in intent. If you want this run as a weekly control cycle with a repeatable evidence pack, this is what we deliver under Project Controls & Reporting. It’s there to flush out anything that could increase cost, delay completion or a key date, or impair performance, while you still have room to change the outcome. The mechanism only works if early warnings trigger decisions and measurable mitigation, and if that mitigation is visibly tied into the programme update rhythm. Otherwise, it’s just minutes in a meeting. This only works when the programme update and submission discipline is solid, so Programme Compliance (Clause 31/32) matters more than most teams think.

The practical fix is not “raise more early warnings”. It’s to change the register from a diary into a decision tool. The approach below is what I’d call a quantified register, not because it’s fancy, but because it forces prioritisation, ownership, dates, and a programme link every single week.

What Clause 15 is supposed to do

Clause 15 is there to reduce the probability and impact of events that could increase the total of the Prices, delay Completion, delay meeting a Key Date, or impair performance.

Two practical points matter:

First, early warning is about foresight and mitigation. It is not the same as a compensation event notice. Treating early warning as “the CE notice in disguise” kills the benefits. You want early warning to happen early enough that you can still change the outcome.

Second, the register is only useful if it drives decisions. A register that does not produce actions, owners, dates, and programme change is not a control tool.

Why early warnings fail in real projects

Here are the three failure modes we see most often:

1. The register is not prioritised

   Everything is “high” or everything is “medium”. Nothing gets escalated. The PM and contractor teams get numb to it.

   
   

2. No link to the programme

   Risks are discussed, but the logic plan stays unchanged. Mitigation does not appear as activities, constraints, access dates, procurement lead times, or resequencing.#

   
   

3. Weekly meetings without outputs

   Meetings happen, but there is no fixed weekly rhythm that produces a consistent evidence pack: updated register, action list, programme changes, and narrative.

The fix is not more paperwork. The fix is a quantified method with a weekly control cycle.

Here’s the mindset shift: you are not logging risks. You are running a weekly risk-to-programme conversion process. That is where delays actually get reduced.

A quantified Early Warning Register

Instead of adding more fields and making it bureaucratic, treat each early warning like a “record card” that must be good enough to answer three questions in 60 seconds: What is it? So what? What are we doing this week?

Use a simple, consistent scoring so the room stops debating emotions and starts debating actions. You do not need Monte Carlo. You need a prioritisation habit.

A very workable scoring model is: Probability (1–5) × (Proximity (1–5) + Time impact (1–5). Cost still matters, but don’t let cost-only items dominate the conversation if they are not about to hit the critical path. In practice, you’ll find that “proximity” is the field that changes behaviour most, because it asks: how soon does this threaten the critical path, not how soon does the event occur.

Below is a clean structure that reads well, drives decisions, and stays auditable without becoming an admin monster.

EWR-Q field	Why it exists	A good example
Title	Stops vague “general risk” wording	“Client sign-off delay for panel GA drawings threatens procurement lead time”
Clause 15 trigger	Keeps it NEC-relevant and focused	“Potential delay to Completion”
One-paragraph description + evidence reference	Anchors the discussion in facts, not opinions	“Rev C issued 04/03. Sign-off outstanding. Manufacturer lead time 6–8 weeks from freeze. Evidence: RFI-22 + email thread 04/03–08/03.”
Probability (1–5)	Prevents everything being “high”	“4 (likely)”
Time impact band (1–5)	Forces a shared scale, avoids waffle	“4 (2–4 weeks)”
Proximity (1–5)	Drives urgency based on programme reality	“5 (could hit critical path inside 2–3 weeks)”
Controllability (1–5)	Stops pointless debate on what you can’t change	“3 (partly controllable via decision + resequence)”
Owner + action + due date	Converts discussion into delivery	“Owner: Project Engineer. Action: request ‘approve for procurement’ decision. Due: 10/03.”
Decision needed from PM/Client	Makes requests explicit and timed	“Yes, approve for procurement by 10/03”
Programme link (impact pathway + activity IDs or WBS)	Forces the register to change the plan	“Sign-off → design freeze → procurement → FAT → delivery → install → commissioning start. Linked activities: ELEC-PANEL-FREEZE, ELEC-PANEL-PROC…”
Status + closure rationale	Prevents zombie items, keeps audit trail	“Closed: sign-off received 09/03, procurement released same day (email ref…).”

If you implement only this table’s discipline, your early warning meetings get sharper immediately. The register stops being a spreadsheet and becomes a weekly contract-management instrument.

The weekly cycle that makes Clause 15 actually reduce delay

The register doesn’t reduce delay. The rhythm does.

The most effective cadence is a short weekly slot (45–60 minutes) that produces the same three outputs every time: the updated register with clear priorities, a dated action list, and a programme change log that shows what moved and why. When those three outputs exist, the project has “memory”. When they don’t, the project has recurring arguments.

A simple way to keep the meeting tight is to cap the discussion: the room only deep-dives the top five items by score (or anything “red”). Everything else is either progressing under action, or it gets rewritten because it’s not actionable yet. You’d be surprised how many early warnings disappear once the standard becomes “name an owner, name an action, name a due date, and show me the programme touchpoint”.

How this links to Clause 31/32 without turning the programme into a weapon

This is where most teams go wrong. They either keep the register separate or they use the programme as a claim narrative. If the programme has already lost trust, start with a Programme Health Check & Recovery before you try to fix it through register admin.

The clean approach is: early warning drives mitigation and decisions; the programme records the agreed mitigation logic and any validated impact pathway; the narrative stays factual and evidence-backed. You’re not using the programme to “prove entitlement” in the early warning meeting. You’re using it to show control.

If you’re serious about improving acceptance and reducing pushback, this discipline helps because it demonstrates that changes are governed, not improvised.

How it avoids becoming “a compensation event fight”

Early warning and compensation events intersect, but they shouldn’t be confused. Early warning is there to prevent or reduce impact. The CE process is there to manage contractual change assessment. If you need the CE side governed so it stays linked to programme logic and evidence, see NEC Compensation Events & Change Support. When teams blend them, two bad things happen: relationships get poisoned by over-notification, or time bars get missed because people “wanted to stay collaborative”.

The practical compromise is to add one small “CE watch” flag inside the early warning entry: not a CE, potential CE (facts developing), CE notified/pricing, implemented. That keeps commercial hygiene without letting the early warning meeting turn into a quotation debate.

A short example that sounds like a real project

If you read an early warning and it doesn’t naturally lead to a decision or a programme change, it’s not finished.

“Panel GA drawings need client sign-off before we can freeze design and release procurement. Rev C went out on 04/03. Manufacturer is 6–8 weeks from freeze to FAT. If we don’t get ‘approve for procurement’ by 10/03, delivery pushes into the install window and commissioning sequence becomes exposed. I need a decision by Friday. If it slips, we’ll resequence install and protect commissioning by pulling forward containment and first-fix where possible. I’ve linked it to the panel freeze and procurement activities so it’s visible in this week’s update.”

That is what “good” looks like: evidence, urgency, decision, mitigation, programme link.

Industry precedent

Courts and adjudication enforcement decisions are the public window into how NEC communications and processes get scrutinised. A useful example is Northern Ireland Housing Executive v Healthy Buildings (Ireland) Limited [2017] NIQB 43, which involved an NEC form and references the early warning obligation in Clause 15 in the judgment.

What NIHE v Healthy Buildings [2017] NIQB 43 gives you, in practice, is a public “reality check” on two NEC behaviours that routinely create disputes: (1) sloppy communications, and (2) weak records when issues get dealt with late.

In the judgment, the court sets out the NEC3 PSC communication rule that required notifications to be sent separately (Clause 13.7) and the early warning obligation to notify “as soon as” a party becomes aware of a matter that could impact time/cost/programme/key dates/performance (Clause 15).  It also emphasises the NEC “mutual trust and co-operation” ethos, and treats Clause 15 as reinforcing that spirit.

If you’d like to see how we set this up end-to-end (register, cadence, programme integration, evidence pack), see How It Works.