One Process, One Register, One Conversation
Early warning is often described as the ‘jewel in the crown’ of NEC contracts.
There are two ways to look at the process:
- as a contractual obligation; and
- as an opportunity to manage risk.
If your primary concern is the first, the position is relatively straightforward. The parties are required to notify matters which could affect time, cost or the performance of the works in use, together with certain other matters depending on the contract and Options being used.
Failure to give an early warning when required can have contractual consequences.
But compliance is only the starting point. The real value of the NEC4 early warning process is in using it to manage project risk.
How the NEC4 Early Warning Process Works
Under NEC4, the Contractor and Project Manager, or their equivalents under other contracts in the suite, notify each other as soon as they become aware of a matter which could affect the project.
Those matters are entered into the Early Warning Register and discussed at early warning meetings. Those attending consider how the effects of each matter can be avoided or reduced, agree actions, allocate responsibility for those actions and review whether previous decisions remain appropriate.
That is the contractual process.
The mistake is to treat it as a separate contractual procedure sitting alongside the project’s existing systems for managing risk.
The Problem with Separate Risk Management Systems
On many projects, early warning is just one of several processes used to manage risk.
There may be:
- an Early Warning Register;
- a project risk register;
- an environmental risk register;
- a safety risk register;
- a stakeholder register;
- an interface register; and
- sometimes several more.
Each register has its own meetings, reporting arrangements and owners.
The same issue then appears in several places. Different people discuss different aspects of it, actions are duplicated and it becomes unclear where decisions are made.
Eventually, more time is spent administering risk than managing it. Consider a simple example.
A contractor is carrying out excavation near a watercourse through contaminated ground.
The contaminated material was anticipated and allowed for in the Accepted Programme and Prices. At that point, there may be no expected impact on Completion or cost.
However, because of the proximity of the excavation to the watercourse, there is a risk of contamination. That could have environmental consequences, result in regulatory intervention, affect stakeholders and the local community, or cause reputational damage.
The matter needs to be managed.
On a project with separate management systems, it might be entered into an environmental risk register and discussed at a stand-alone environmental risk meeting.
During the project, the contaminated material is found to be more extensive than anticipated. The issue may now affect the programme.
What happens next?
- Is the matter partially or wholly transferred to the Early Warning Register?
- Does it remain on the environmental register?
- Is it recorded on both?
- Who owns the risk?
- Which meeting makes the decisions?
- Where are the actions recorded and followed up?
These are administrative questions created by the project’s management system and do nothing to manage the actual risk.
The risk has not changed identity simply because its consequences have developed. It remains one matter which needs to be managed.
One Process for Managing Project Risk
There is a simpler approach.
One risk notification process. One register. One regular risk management meeting.
Use early warning as the framework.
The contract identifies the matters which must be notified because failure to do so may have contractual consequences. But that does not mean the project should limit its use of the process to those matters.
Safety, environmental, stakeholder, interface, reputational and operational risks can all be notified and managed through the same process.
The contract specifies the minimum content for the Early Warning Register, but it can contain whatever additional information the project needs to manage those risks effectively, including:
- likelihood;
- consequence;
- risk rating;
- risk owner;
- required actions;
- action owners;
- due dates;
- residual risk; and
- escalation status.
The NEC4 contract establishes the minimum process, not the ideal process.
The project should build on that process to create a risk management system which works for the project.
One Principal Risk Management Meeting
The same applies to the early warning meeting.
It should not become another contractual meeting added to an already crowded project calendar. It should be the principal meeting at which project risks are discussed and managed.
The people who need to make decisions should attend. Risks should be discussed, actions agreed, responsibility allocated and progress reviewed. The Accepted Programme should inform the discussion, particularly where a risk may affect planned work or Completion.
If a matter may also be a compensation event, it is notified and dealt with through the compensation event process.
The two processes have different purposes.
Early warning manages the risk. The compensation event process deals with any change to the Prices, Completion Date or Key Dates for which the Client is contractually liable.
The risk continues to be managed whether or not a compensation event has been notified and whether or not the matter is ultimately found to be a compensation event.
NEC4 Should Be Part of the Project Management System
Too many projects implement NEC4 by adding its procedures to what already exists:
- another register;
- another meeting;
- another workflow;
- another reporting requirement.
The result is more administration without necessarily improving project management.
NEC4 should be implemented as part of the project management system, not alongside it.
That requires the project to decide how early warnings, programmes, compensation events, risk management, commercial management, decision-making and escalation work together.
The contract provides the processes, but the project still has to decide how those processes will operate in practice.
If an NEC4 contract is requiring the project team to do something they would not otherwise need to do or increasing the administrative burden without providing any corresponding benefit, that is not an NEC4 problem, but an implementation problem.
