NEC Clause 15 Early Warnings: A Quantified Register That Reduces Delay
- Mar 9
- 6 min read
Updated: 5 days ago
By Roman Bazelchuk | NEC Accredited Project Manager | APMG Project Planning and Control
Founder, NEC Planning Solutions Ltd
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. It is there to flush out anything that could increase cost, delay completion or a key date, or impair performance, while the team still has 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 is just minutes in a meeting.
The practical fix is not "raise more early warnings". It is to change the register from a diary into a decision tool. The approach below is a quantified register, not because it is fancy, but because it forces prioritisation, ownership, dates, and a programme link every single week.
What NEC Clause 15 Early Warning 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
The first failure mode is a register that is not prioritised. Everything is "high" or everything is "medium". Nothing gets escalated. The PM and contractor teams get numb to it and the meeting becomes a formality.
The second is a register with 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. The discussion and the programme exist in separate worlds.
The third is 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. Without those outputs, the meeting has no memory and the same issues recur.
The fix is not more paperwork. The fix is a quantified method with a weekly control cycle. The team is not logging risks. It is 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 the register bureaucratic, treat each early warning as a record that must answer three questions in 60 seconds: What is it? So what? What are we doing this week?
Five fields are enough to drive decisions without creating admin overhead.
Field | What it does | Example |
Title + description | Stops vague "general risk" wording. Forces the team to name the specific issue and the evidence behind it. | "Client sign-off delay for panel GA drawings threatens procurement lead time. Rev C issued 04/03. Sign-off outstanding. Manufacturer lead time 6 to 8 weeks from freeze." |
Time impact (1 to 5) | Forces a shared scale. Prevents waffle about whether something is "significant" or not. | 4 (2 to 4 weeks potential delay to commissioning start) |
Proximity (1 to 5) | Drives urgency based on programme reality. This is the field that changes behaviour most, because it asks: how soon does this threaten the critical path? | 5 (could hit critical path inside 2 to 3 weeks) |
Owner + action + due date | Converts discussion into delivery. No owner and no date means no action. | "Owner: Project Engineer. Action: request approve-for-procurement decision from client. Due: 10/03." |
Programme link (activity IDs) | Forces the register to change the plan. If the early warning does not connect to the programme, it is not a control tool. | "Sign-off → design freeze → procurement → FAT → delivery → install → commissioning start. Activities: ELEC-PANEL-FREEZE, ELEC-PANEL-PROC." |
If the team implements only this table, early warning meetings get sharper immediately. The register stops being a spreadsheet and becomes a weekly contract-management instrument.
Four additional fields, probability, controllability, clause 15 trigger, and closure rationale, are useful for a complete auditable register. These can be included in a full template but are not needed for the weekly meeting discussion. The five fields above are the ones that drive decisions.
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 from the programme or they use the programme as a claim narrative. If the programme has already lost trust, address that first through a Programme Review and Recovery before trying 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, and the narrative stays factual and evidence-backed. The programme is not being used to "prove entitlement" in the early warning meeting. It is being used to show control.
How it avoids becoming a compensation event fight
Early warning and compensation events intersect, but they should not be confused. Early warning is there to prevent or reduce impact. The CE process is there to manage contractual change assessment. 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, or 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 that affected CE perpective
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.
About the author
Roman Bazelchuk is the Founder of NEC Planning Solutions Ltd, a UK project planning and controls consultancy supporting contractors with NEC programme compliance, compensation event assessments and live project controls. He is an NEC Accredited Project Manager and holds the APMG Project Planning and Control qualification, with a BSc in Mechanical Engineering and postgraduate training in Planning and Control.
NEC Planning Solutions provides contract-aware planning support through a QA-governed delivery model, helping project teams keep programmes accepted, current and commercially useful from tender through to live delivery.
Need a weekly early warning rhythm that actually connects to the programme?
If the early warning register is not producing decisions, the programme is not reflecting mitigation, or the weekly cycle has become a formality without outputs, specialist NEC programme support sets up the register, the cadence, and the programme integration as a managed discipline.
