The NEC form of contract is often described as a contract built on collaboration, communication, and proactive management. However, these are not outcomes guaranteed by the wording alone. This bulletin explores how key NEC mechanisms rely on specific behaviours, and how the absence of those behaviours can undermine otherwise well-structured contractual processes.
NEC is a behavioural contract. NEC contracts are written in a way that assumes certain behaviours will occur. Phrases such as “act in a spirit of mutual trust and co-operation” (clause 10.2), “give an early warning” (clause 15.1), “submit a programme” (clause 31.2), and “assess compensation events” (clause 63) are often interpreted as procedural requirements. In practice, each of these depends on people doing specific things at the right time.
Take an early warning as an example. It is not simply a form or a meeting; it is a behaviour. It involves noticing a risk early, choosing to raise the issue even when there is uncertainty, and communicating it clearly to others. In practice, this might look like a site manager stopping a conversation to say “we’ve got a potential access issue here”, or a planner challenging a sequence in a meeting rather than waiting to see if it becomes a problem. It could be someone picking up the phone to clarify a risk rather than waiting to formalise it later. When those behaviours do not occur, risks are often discussed informally, held back, or only raised once they begin to impact delivery. At that point, the process technically exists but no longer delivers its intended value.
Where do projects typically drift? Across NEC projects, recurring issues are often attributed to process failure. In many cases, the process itself is understood, but the behaviours required to make it work are inconsistent or delayed.
Early warnings may be notified late, or not issued at all, often because of perceived commercial consequences or a belief that notifying them reflects negatively. In practice, this can look like teams discussing a risk on site but not formally raising it or waiting for more certainty before saying anything. Programme submissions may occur, but without regular updating or meaningful engagement with logic and sequencing. For example, known changes in access, constraints or sequencing are understood by the team but not reflected in the programme. Compensation events are sometimes notified or assessed late, or influenced by hindsight rather than the forecast position at the relevant point in time. This often shows up as conversations happening too late, or positions being shaped by what is now known rather than what was understood at the time. In each of these cases, the contract is clear. The difficulty lies not in what is written, but in what people actually do.
What “good” looks like in behavioural terms: It is often easier to describe success in general terms such as “good collaboration”, but this can be difficult to translate into practice. A more effective approach is to focus on what people actually do when NEC is working well.
On well-performing projects, risks are raised at the point they are recognised rather than when they become unavoidable. This might be someone openly saying “this could become an issue” even when the detail is not yet clear. Programmes are updated to reflect current reality, not historic intent, with teams adjusting sequences based on actual site conditions rather than sticking to the original plan. Compensation events are assessed based on the information available at the time, without being influenced by what is known later. Individuals ask questions early, test assumptions, and share information in a way that supports collective understanding. These are small, observable actions, often simple conversations or decisions in the moment, but they have a significant cumulative impact on project outcomes.
Focusing on what you want more of: One practical way to strengthen NEC delivery is to be more deliberate about the behaviours you want to see and then pay attention to whether they are happening.
For example, a project might consider whether early warnings are being notified at the point of uncertainty, whether programmes are being regularly updated to reflect actual progress, or whether compensation events are being assessed based on the correct point in time. By gathering simple data on these kinds of behaviours, it becomes possible to see what is really happening in practice rather than what is assumed. This might include looking at when a risk was first discussed compared to when it was formally raised as an early warning, whether programme updates reflect known changes at the time they are submitted, or whether compensation events are being assessed based on the correct contractual point in time rather than hindsight. These types of measures provide a clearer view of how the contract is being applied day to day. Feeding this information back to the team, and recognising when the right behaviours occur, helps to reinforce them.
Over time, this creates a shift away from relying solely on process compliance and towards actively encouraging the behaviours that make the contract work as intended.
This topic, including practical approaches to measurement and feedback, will be explored in more detail in a future bulletin.
Designing the environment for the right behaviours: The behaviours seen on a project are shaped by the environment in which people are working. This includes the consequences people experience, the pressures they are under, and the signals they receive from leadership.
If notifying an early warning leads to challenge or potential conflict, people are less likely to do it. If time pressure consistently prevent getting on with the job, people are more likely to delay raising issues or updating programmes. If programme logic is not regularly discussed or challenged, it is less likely to be tested against reality. Over time, these signals shape what people see as the “right” thing to do. Leadership plays a significant role here, particularly in what is noticed, questioned and reinforced in day-to-day interactions.
Where the environment supports openness, clarity, and timely action, NEC processes tend to work as intended. Where it does not, the contract can become reactive and adversarial despite its original intent.
Cloud-based systems help. Using an established cloud-based system such as “Contract Bee” or “Cemar” will help create the framework for correct behaviours. The correct processes should be embedded within the system, and it encourages the right language to be used on each form and the correct timescales to be followed.
Key Performance Indicators(KPIs) to encourage correct behaviours: The use of KPIs has been considered in detail in CECA bulletin 41. As highlighted in that bulletin, carefully considered KPIs can help create the behaviours that will benefit the project. They can encourage the parties to perform in a way that they may not otherwise be incentivised to do if they were purely following the rules and risk profile of standard contract wording. Equally, ill thought or misconceived KPIs can actually lead to bad behaviours undermining their original intent. When creating a KPI the author should consider what behaviour/objective is trying to be achieved and then produce a clear, achievable, and measurable KPI that will encourage that behaviour to happen. Ideally, relevant KPIs should be considered for all parties involved in the contract. This would help bolster the spirit of mutual trust and collaboration whilst encouraging more proactive behaviours around the use of the contract.
Summary: NEC contracts provide a strong framework for collaborative and proactive project delivery. However, their effectiveness depends on the behaviours of the people applying them. Understanding and shaping those behaviours, particularly around early warnings, programme management, and compensation events, is key to achieving the outcomes that NEC is designed to deliver. A focus on what people actually do, alongside measuring and reinforcing the right behaviours, will lead to more consistent and sustainable project performance.