Introduction and welcome

Glenn Hide: Good afternoon, everyone. Welcome to this, our very first webinar. We're very pleased to have you online. I'm Glenn Hide. I run a company called GMH Planning, and we're a specialist consultancy that focuses on NEC forms of contract. I'll allow David and Ben to introduce themselves over the next couple of slides.

In conjunction with CECA, we've been publishing monthly bulletins. Hopefully some of you have read some of them. Number fifty seven was our last published bulletin. And each month we're taking a look, a focused deep dive on aspects of NEC contracts. And we thought we'd extend it. So here is our very first webinar. So we're going to look to produce a monthly webinar to accompany the series as well.

David, would you like to introduce yourself and CECA?

CECA introduction

David Allen: I certainly would. Thank you. Hi, I'm David Allen. I'm the Executive Director for CECA Southern. And thank you for joining us here for our first NEC contract webinars series.

Before I hand over to Ben and Glenn from their various companies, we will deliver the session. I'd just like to say a few words about CECA and why we're doing this.

The Civil Engineering Contractors Association, CECA, is a not for profit member led trade association that represents and promotes civil engineering contracting organisations that deliver and maintain seventy to eighty percent of the mainland UK's infrastructure. We deliver against five core pillars that you'll see on the screen in front of you across six English regions and the devolved nations of Scotland and Wales.

We engage with government clients and those that influence our industry at all levels. And if you want to know more about us, you can go to our website at ceca.co.uk.

But in reference to today's event, this has been delivered under our skills and training pillar. And we also, where we deliver an extensive range of training activity that is intended to increase the awareness of those involved and the sustainability of the organisations that they work for.

As Glenn mentioned, GMH Planning have been delivering NEC training for us for a while now, and following those engagements we had early days between Glenn and myself, we decided that we needed to do something beyond the training itself to increase the awareness a bit wider from those that were attending the training, also to just reinforce that training. And we started producing the bulletins that Glenn has referred to.

They are very good at actually knuckling down on the real intent of the clauses and increasing that general awareness. So that has really proved a boon to our members and others in the industry that have been able to have a look at them.

Now, subsequent to discussions with Glenn and Ben earlier this year, it was agreed to take this to the next level. And out of that, we now have our first NEC contract webinar. This one will look at a positive approach to early warning and more will follow. So without further ado, I hand you over to Ben. Thank you.

Session overview

Ben Walker: Thank you very much David. Welcome everybody. Really excited to be a part of this and over this series of episodes looking at NEC we hope to really strike a chord between the theory, what's required, and some practical useful tips. And I think we've packed a few actual examples into the slides rather than just talking about theory so looking forward to doing that.

So welcome. A little bit of an introduction. Why should you spend the next forty minutes plus questions watching us today?

We're going to cover why this topic matters, firstly, and what is an early warning? So early warning is not a defined term, so it's got a literal interpretation. So Glenn will take us through those two things.

Next, I'm going to look in a little bit of detail around actually giving early warning by notifying. What does that mean? What do we have to put in the communication there? And how do we manage that then within the early warning register?

Next up, then we'll look at early warning meetings. Who should attend? How frequently should we have them? And what's the real objectives there? Are we just sitting around agreeing that it's bad? Or what do we actually do about it to take those early interventions?

We'll have a little look at what looks good, bringing all those things together and also by difference, those common problems, perhaps some of them logistical, practical, systematic and actually quite often behavioural. So we'll look at those and maybe ways in which we can oil the wheels a little bit and get things back on track.

So a lot to understand about the intent of early warnings here, and then we have that nice long Q&A session that we really would like you to get involved. So please do use the chats. I think we're only going to be monitoring the LinkedIn chats as it happens live, but we will look at the chats across the different platforms. I think we're live across lots of social media platforms, some of which I've not heard of, so there we go. But we'll be amassing all the Q&A together and bringing it together.

I'll leave you with one more thing. I always put this quote in my presentations because I just think it's probably the most powerful thing I've ever heard. So as we go through the webinar today, and in fact, probably the majority of the ones that we do, I'll just leave this quote from the great late Dr. Martin Barnes hanging over proceedings for the rest of the hour. And that is that project management is about influencing what hasn't yet happened. Everything else is administration.

And I think that's really powerful because what it's setting the tone here is that proactive collaborative foresight approach. Do we want to be passengers on our projects, or are we going to actually project manage? So we don't want to be project administrators, we are project managers, and part of that function is influencing the future. And early warnings, there's no better example of NEC procedure than that.

So with that, I'll hand over to Glenn, who perhaps can explain to us why this topic matters. Glenn, over to you.

Why this topic matters

Glenn Hide: Absolutely. Such an important topic. It's a very simple topic, but it's one of the most misunderstood and mismanaged or has been in the past. I think we are getting better as an industry. I have seen an improvement, but there's still room for improvement.

And I think the survey we ran last year proved this. So we did an industry survey through our group and we asked people, what percentage of you are still finding people on your projects who think early warnings are a negative process and view them negatively? And the result was that fifty three percent of people still found on their projects they had someone or multiple people of that manner.

I'd love to see in the chat an early contribution from you. Do you find that? So in the chat, if you are finding that there's still some people who seem to misunderstand what's meant to be a positive process, put your comments into the chat now and we can have a little look through them towards the back end of this session.

Why? Why are we still finding people who think this is negative? So we're going to pick up on some fundamental points around the early warning process we need to know and understand.

So some really simple stuff. Early warnings, they're meant to be a project management tool. They're not a means of allocating the risk or the liability. Effective early warnings mitigate or avoid problems, and we're not looking to assign blame. So we're trying to get the issue out there on the table and see what we can do about it.

And a collaborative approach increases project success. That's pretty self explanatory, I think. And then another quote from NEC contracts where they quote, the foresight applied collaboratively mitigates problems and shrinks risk. And the early warning process is the cornerstone of that process.

So if we look at objectives we're looking to achieve out of today's webinar, it's to really look at the true purpose of the early warnings and the early warning process. Master the practical requirements of section fifteen of the contract. So all of the clauses within section fifteen, we're going to make sure we fully understand them. There's not too many, but we need to understand them.

Transform early warning from early warring. Must admit, Ben put that in. I quite like that. And yeah, so early warnings aren't about going to war. In fact, we're peacemakers. So the complete opposite of warring is what the early warning process should be. We're going to look to seek collaboration and problem solve and identify and avoid common pitfalls that tend to happen around early warnings.

So that's what we're going to try to achieve in this session.

What is an early warning?

Glenn Hide: So what's an early warning? Well, this won't take too long because there's only two words to analyse. So what does early mean? Well, it means occurring with little time elapsed, straight away, not late.

What does warning mean? It's something that serves to give advance notice or caution regarding a particular matter that could have a negative outcome.

So when you put those two words together, all it really means is there's a potential problem. Let's talk about it whilst there's an opportunity to do something about it. So it really is that simple, isn't it, Ben?

Ben Walker: It's very simple, Glenn, and people love to complicate things, don't they? And I think one of the things we learn about early warnings is as much what they're not about, which is useful to know so that we don't fall down the hole of, I don't know, in particular, I guess, conflating them with compensation events. They're forty five clauses away from compensation events. So this kind of urge to conflate the two things is to really leapfrog all of that potential value. So let's leave compensation events for another webinar, and just focus on the purpose of early warning here.

So, yeah, absolutely. And it's not a defined term, so it does have this literal sense. And, you know, few words as possible. Very NEC, very clear.

Core contractual requirements

Ben Walker: So, yeah, I think then probably start having had that little acknowledgement that this is about a timely, advanced warning of something. Let's look more specifically at what our obligations are. So, of course, this is a clause. So it's one of the rules of the game. And we know from clause ten point one that we have to act as stated in the contract. So this is not optional. This is something we must do.

And what it says is the contractor and the project manager give early warning as soon as aware by notifying the other of any matter which could. And I've highlighted a couple of words there. So as soon as aware. This isn't when convenient within a reasonable time period or anything like that. It's as soon as aware.

I think when thinking systems and agility, you know, and this isn't something we have to worry about going through governance, this is commercially benign to do this, right? There's sanctions for not doing it but actually it's pretty safe to do it. Very safe.

And it's which could, so we're not interested in late notifications. This is early warning so it hasn't happened yet. It could impact us. There's actually four bullet points underneath that first sentence. We've bridged them into three little icons here: increase total prices, delay completion, there's a separate bullet point for delay a key date, or impair the performance of the works in use. So, you know, very crudely time, money, quality, I guess.

But I think what's sometimes missed, and it really sets the scene, and I'd ask you just to ponder on it, is that extra provision that sits underneath those bullet points. It says, additionally, the project manager or the contractor may give early warning of any other matter which could increase the contractor's total cost.

Now, bear in mind, this is core clause stuff. So it's ambivalent to main option. It doesn't matter whether it's an option A lump sum contract or a cost reimbursable contract. It doesn't know about the payment mechanism. This is core clause. And yet, we have this ability to warn about something that could increase the contractor's total cost. Now, that really should speak to us and communicate really what this is about.

And it's saying to us that if the contractor is feeling some pain, then it'd be very short sighted for the project manager to not play a role there in helping, you know, address that pain and mitigate it. So even in a lump sum, or as we call it, priced contract with an activity schedule, there's still the need there and the option to communicate a risk or a pressure on the contractor.

Bear in mind as well, just to finish this slide, notifications are formal communications, so they do need to follow clause thirteen.

And Glenn, do you want to say a few words about your experience on the project manager contractor? Do you find these are in balance? I'm not so sure personally.

Glenn Hide: Yeah, it still tends to be the contractors would notify the majority of the early warnings. So to some degree, I think we're to expect that because they're the ones at the coal face unearthing the problems. So, yeah, I think it is a tendency that there'll be more. We're looking at project manager contractor relationship, but obviously this would be mirrored for contractor subcontract relationship. So, yeah, you do tend to get more from the contractor, but obviously as you've highlighted here, project manager, if they're aware of potential issues, then they should equally be getting these early warnings into the system as quick as possible.

Ben Walker: Yeah. And, you know, it's not really believable to say that there aren't these things out there, right? The project manager, the client are dealing with political pressures, press, budgetary constraints, planning, perhaps land issues. So there's loads of useful information there that we can impart onto our supply chain, onto our specialist contractors so that they can be thinking about that stuff as well. And that, again, is where the foresight applied collaboratively comes in.

We are trying to mitigate problems before they happen and maximise the opportunity for intervention. So a few key points there.

Glenn, in terms of giving early warning, do you want to take us through the rudiments of what we must do and what might be optional?

Essential content for early warning notifications

Glenn Hide: Yeah. So when we, whoever we are, whether we're a project manager or contractor, so when we're notifying an early warning, we need to think about the minimum content. So as a minimum, we want to know what is the matter that we're talking about. So not an essay, a book, but nice and concise, but in enough detail that makes it clear what the issue is. We're not going to solve it in the early warning. We just want to get across information to know what are we actually talking about?

The nature of the potential impact, just to some degree. So we don't want to solve it. We don't want to say this is the issue and this is how we're proposing to solve it. But if you've got a few ideas of already things that could minimise the impact, we might sow some of those seeds just to again show that it's a very positive nature of this particular early warning.

Optional content, so the next stage as well. So we've described what the thing is and normally they'll be on a cloud basis maybe a tick box as to what it can impact, the three bullets that Ben mentioned. And then do we need an early warning meeting? Not always. And often we'll have a regular meeting set up now especially with NEC4. So do we need an early warning meeting? So whoever's writing the early warning can make that judgment. And if an early warning meeting is necessary or beneficial, we can then sow the seed: who should attend, where should we hold it, when should we hold it. And again, depending on the sense of urgency of the early warning would decide how important that is.

What we don't want to include is cost and time implications. This is an early warning. We're going to discuss it in the meeting and flush out these things. Early warnings are not about how much might this cost. We don't want to go in. This is not meant to be a commercial tool. And again no firm conclusions in the notifying of the early warning. There's no point in issuing, notifying an early warning and then almost resolving it in the same communication. It almost says, well, do we even need an early warning?

So the early warning is really facilitating situations where it will be beneficial for us to discuss things and as a team effort, decide what we're going to do going forward.

Ben Walker: Yeah, I'd echo that, Glenn. And I think the big test for me when drafting an early warning is to look at it before you send it and think, am I opening a conversation here? Am I setting the groundwork to having that discussion or are we making closed sort of fait accompli statements where we're making assertions about one thing or another or maybe prematurely trying to seek the solution?

And I know you've got a slide in a minute around how digital tools perhaps approach this with replies and things. I think that would be a really useful part of the conversation.

So yeah, I completely agree with everything you said there. We're not. It is premature, isn't it, to price them? I know I think actually NEC4 recognised that the language that was used in NEC3 did talk about risk register and risk reduction. And I think with that came a load of assumed best practice around the discipline of risk management, where we do allocate and we do think about money. And we kind of want some of that, but not just yet. And I think that move to calling it the early warning register was a useful one.

Early warning register management

Ben Walker: Okay. Mentioning the early warning register. So there is a requirement, an obligation on the project manager to keep a risk register, or as NEC4 calls it, the early warning register.

And very simply, it's a register of all of the notified early warnings. So as soon as they're notified, they get put on the register. And there is actually an opportunity to pump prime the register from contract data parts one and two. So there's an identical entry in contract data part one and part two so that pre contract date you can actually pump prime this register.

I think importantly, and I think Glenn's mentioned it already, this is not a contract document. It's a management tool. It doesn't exist pre contract date. So it's only upon the contract date that this even has the chance of being formed. And that again illustrates and confirms to us that this is not about allocating a risk. So you wouldn't be pricing these and using them as some kind of provision or some schedule. You'd certainly need some careful Z clausing to bring that into effect anyway.

Quite often we see these, not often now, but now and then I still see a risk or an early warning register priced up as a provisional sum tool. Definitely, that's not what it's for.

So what do we put on it? Well, the contract tells us the register has a brief description of the matter and then the proposals, solutions and decided actions agreed upon as to how we might mitigate or avoid it.

And, you know, we offer an example on the screen there. I think it's administratively helpful to number the early warnings. Note that I haven't put on this register who they're from because, again, it doesn't really matter. This is about getting the issues on the table in the register for conversation.

Put a notification date on there just so that we know when they've been notified. And the status. So this status, again, this is just something that I've always done.

When putting CEMAR together, I was wondering about this obligation to remove or deciding which risks could be removed from the register. I never like to remove them because I think they're such an important source of lessons learned and we can share them perhaps across the programme or even at some point hopefully the industry so we can learn from each other's mitigation measures perhaps.

So I think many of these systems now they'll just have a status of turning them to live or avoided or passed.

The other thing Glenn mentioned is we wouldn't price early warnings and I think that's sensible certainly in those opening notifications. But I think a lot of people wanted some form of being able to prioritise and weigh them. And so there's nothing in the contract that precludes you from doing this. And some people make good use of it. They might maybe score their risks out of likelihood and consequence and get a product of maybe five by five matrix, bringing a bit of that risk discipline into these things.

But the really important bit on the register, I think, is tracking those proposals and solutions and actions. And remember that minutes to a meeting are not communications. So just because we've recorded the actions here and the last part of the clause reminds us of this, if there is an action to take, for instance, the project manager might want to go and instruct some additional trial holes or some other form of mitigation. If that requires, for instance, a change of the scope, then you must go and action that separately. So the minutes aren't enough. We need to go off and actually action those things properly.

Anything to add, Glenn?

Glenn Hide: Only I think the scoring, a lot of the cloud based systems do this scoring. And as Ben said, it's not a contractual requirement. I get it. I don't think it does too much harm and I can see why it's there. The only thing I would say, if people put too much focus on the scoring and just focus on the high score ones, eventually the low score ones come to bite you. So they all need keeping an eye on and moving forward. And if we just keep the score as a sense of urgency and no more than that, then I think they do a job.

Digital system considerations

Ben Walker: And, you know, talking about how people may systematically approach some of these requirements and then, you know, the contract doesn't preclude you from doing various things, but certain practices have sort of sprung up and some galvanise the intention, others you could argue take us away from it. Do you want to give us a bit of a reality check on these digital systems, Glenn?

Glenn Hide: Yeah, I mean, generally cloud based systems, there's a few out there and you guys need to do your homework and you need to trial these different systems and see which ones you find work the most thoroughly and obviously price and things like that will come into it. So we're talking generally about systems, not sort of homing in on one in particular.

All of these, a lot of these cloud based systems, just with regards to the early warning process, some of them suggest you need to respond to an early warning. And it's just one of the frustrations that technically there's no contractual obligation to respond to an early warning.

Now you can respond and some early warnings that don't need a meeting, they can be responded to and we don't need a meeting. And others, most of them, we're going to discuss at the early warning meeting. And then when you update the actions into the register, that is the response that's required. So the slight frustration is that some early warnings, some cloud based systems suggest that you've got to respond to an early warning within the period for reply, which contractually isn't actually correct.

It's not a big problem, it's not a big deal, but it then just means if they haven't responded, they've had the meeting, they've updated the action, they've now got to manually go back into the early warning, because their system says you haven't responded, and then just say, see early warning register, and then the action goes away.

So it's really just a reminder, not so much just the problem with the cloud based systems, but that you don't have to respond to an early warning. But some early warnings can be, you know, responded to, which might then mean that we either don't need to discuss at the meeting or it's a very quick discussion. So that's just one element, so within the system requirements.

We just need to make sure what the system does is actually in line with the contractual requirements, because as good as these systems are, sometimes certain aspects maybe don't do things quite as thoroughly as the contract requires.

So my important box here is the contract requirements. So there is no mandatory response time. We want to focus on the notification, a meeting at the appropriate time, and then driving the actions will be recorded in the register itself.

Ben Walker: Yeah, that might even shed a little bit light on how one system did adopt this, although quite often you'll find a box or a tick or a setting that will say this isn't necessary. But a lot of clients do want to see that the early warnings have been acknowledged.

But you're quite right. You know, it's very easy then to misunderstand that acknowledgement or that appreciation that the risk has happened as being actually that it's been dealt with. And certainly, if you think of most of the other actions on your to do list day to day, they might hit you on a dashboard summary on the front of one of these systems.

And that's okay, because, okay, I know I need to reply to a quote, and they kind of sit there and persist and go amber and red until you deal with them. Early warnings are different, though. The authors of the contract, they're not going to take a guess at an average timeframe for avoiding a risk. You can't, can you? A price adjustment for inflation might never be avoided or passed. It's an ever present risk. So it's not appropriate to reply to it and then it disappear off your radar.

So the risk register, sorry, the early warning register and maybe the programme register, you know, things you really want on your dashboard, keeping them in mind.

The last thing I would say as well, and if you are a client doing this and you're kind of looking at the overall compliance and bringing into your calculation of how well are we managing NEC, a reply to an early warning in a certain amount of time. I would be very cautious of that for all the reasons Glenn's just mentioned.

And one of the things you perhaps ought to look to is the age of those proposal solutions and actions and how many of them there are relative to the perhaps the risk score. So you can see whether you're taking a proportionate approach to those things. So, yeah, all good points. And yeah, the system.

And I haven't thought, we haven't talked about this, but here's a question we can ask our viewers. Is there a valid KPI to do with early warnings because I've never thought of one. I have seen people try and write KPIs. How many open early warnings have we got? That should be irrelevant. You could have not many or you could have lots. But you could have a project that doesn't have any many issues or not. I've seen some projects that said number of early warnings compared to compensation events and they actually scored the project low if they had too many early warnings compared to compensation events. I think they missed the point. Maybe stop the CEs from happening. But they said oh no you're wasting our time. There's too many early warnings compared to compensation events. So I'd love if viewers have got a KPI that will be useful for early warnings because as I say I can't actually think of one.

Glenn Hide: That's a really good point. And, you know, maybe the vendors of the software could come forward with some of the things and share those as well as to what sort of metrics people are asking for. And we can do a bit of a sanity check on those and feed them back. That's a really good point, Glenn.

Early warning meetings

Glenn Hide: Okay. Moving on. So much to talk about on this one topic. We'll talk about early warning meetings next. I think I was going to talk to this slide, Glenn, if you don't mind me asking.

Can pick up this one. So who can call the meetings? So contractor or the project manager. A lot of contractors I've run a training session today and even today I've asked contractors in the room, raise your hand if you notified an early warning and it fell on deaf ears. There was no meeting. It all felt a waste of time. A lot of them put their hand up. And I said, well, you do realise you're part of the problem because you could have instructed the meeting. What, can we? Well, yeah, even with NEC3, it's the one meeting, one instruction, in fact, that the contractor can give in the whole contract. So either party can instruct the meeting and obviously the other party should want to come to that.

And NEC4 has also highlighted that subcontractors can be invited if they would assist or could assist in the decisions being made.

Also with NEC4, we've got this minimum early warning interval that the client's now forced to think about in terms of how often do we want to have the early warning meetings. So clients will set that interval in data part one, and then it means that at least every four weeks or monthly, we will be having an early warning meeting. And sometimes I've seen that set at two weeks, occasionally a week.

So that's very useful, introduced with NEC4. And then just really focus on the meeting objectives, which is covered in clause fifteen point three. So cooperate in considering the proposals, look for solutions in terms of who it's going to affect, deciding the action and who should take them and agree what matters can then be removed or I prefer like you, Ben, closed. So we don't delete them from the register. We just close them and then you can filter out the closed ones and then keep open the open ones and the open ones will then form the agenda for the next meeting. And very importantly, review previous actions. So go back over all the open early warnings and see is there any update we can do in terms of that action. Which is why I don't think there should be a KPI on how long has your early warning been open for. Some early warnings will stay open for a long time as we keep reviewing it. It's doing its job. And so there should be no measure or a detrimental consideration that you've had this early warning open too long. Yes, we should close them as soon as we can. But they stay open as long as necessary. And if it's a really clear and obvious issue, well, we probably don't need a meeting. They're the ones that probably can just be responded to and we don't need to have those as a discussion at the meeting. Anything to add on that one Ben?

Ben Walker: Yeah, just one thing. It popped into my head. I was delivering a training course a couple of months ago, and one of the delegates said something. Every day is a school day, right, on the training sessions, and it is really, really helpful to me just to think it through. They said for goodness sake, make sure you invite more people from site than the office when you do these early warning meetings. And it made me think about the boots to shoes ratio at least.

So you need people with shoes to do the assessments, but you need people with boots perhaps to come up with the good ideas from the site. So if you want your early warnings to be genuinely ingenious, I think that the Latin ingenium meaning clever and later ingenuity, engineers derived from this. It's about problem solving and coming up with clever ideas. You know, get the right people in those meetings. Get your specialist contractors there.

It's very often the first time that the specialist contractors, the subcontractors NEC calls them, the main contractor, the client, the designer are all together discussing the programme. Hopefully they've got a contemporaneous programme ready, recently accepted, and they're looking at options and discussing problems with foresight collaboratively. And there might be a better plan than what somebody dreamt up three or four years ago and the original pass of the programme. There might be a better one that actually not only avoids and mitigates the risks, but actually delivers a better outcome overall.

So, you know, I often wonder whether early warning meetings, and I know this debate has raged elsewhere as well, whether we're missing a trick and we should be thinking about opportunities as well as warnings. And I think, again, having that mindset is probably helpful.

Glenn Hide: Definitely. I had another person in a training session recently say, I don't really like the word warning. That feels a bit confrontational. I don't like the name. And I said, well, what would you call it? And they said, well, I don't know. What about a heads up? And I did laugh. But I actually said, I quite like that. A heads up. I like it. Well, this is what it is. But it's called an early warning. But it's a heads up.

Ben Walker: Absolutely. And above all else, I think we've got to break that adversarial connotation.

If I had another anecdote off the top of my head, I would remember the one about the client banging the table at the commercial meeting. I don't want to see another early warning this month. You may or may not have experienced that yourselves. But that just smacks of totally misunderstanding the process. And it might not all be the client's fault. If the contractor is weaponising these and they become tedious and only about future compensation events rather than genuinely mitigating problems on the project and achieving a better success for all.

And equally, when the contractors are giving you early warning about a risk to their overall cost, you're obligated to give more than just sympathy, right? You genuinely have to cooperate and follow these points. And, you know, it's short sighted not to.

And I guess clients, maybe we should be looking at more behavioural metrics from clients holding everyone to account, you know, because this is ultimately their budget that we are, you know, spending well, not spending at all. Project management, not project administration. Project management.

When to hold early warning meetings

Ben Walker: So when to hold an early warning meeting? I think, Glenn, you briefly covered this already. Under NEC4, there is now an early warning meeting interval, and this is identified in contract data part one. And I think really there's no harm in maybe setting this weekly. It probably is a nice agenda item on a progress meeting.

And it just keeps those fresh. I've seen these happen really well. I could mention many clients who have them on a whiteboard projected straight from the system and they're running through them deciding whether or not they can tweak the likelihood or impact score if they do that and really adding proposals, solutions, actions and managing it live collaboratively around that system.

So I talk about culture, knowledge, and discipline. Again, those systems, however you do it, manually on a spreadsheet or on a system, get around the table, use it for the project management tool that it is.

What else have we got on the slide? So yeah, when the issues are complex or unclear, multiple parties are affected, creative solutions are required. So yeah, this is about perhaps dealing with the more complex stuff.

Meetings are not needed perhaps if things are very clear and obvious or if a simple response can close out the matter.

When in doubt, there's no harm. And that kind of interval of early warning does allow you to keep that cadence and that rigour.

But remembering what Glenn said as well, it's the one time the contractor can actually instruct something to happen. So we don't need to be terribly polite about it. Oh, do you mind terribly meeting with me to discuss this problem I might be having? Just instruct it.

And again, there's another benefit of these web based tools because they handle the language for you. So the problem of politeness perhaps isn't there.

But we'll perhaps say a couple of other things about these systems not becoming a barrier. We don't want to be using them to hide behind or to stifle actual human conversation. So again perhaps we missed that off when we were talking about digital systems. But really, Glenn, I think with all these things and I'm sure we'll cover this point in other topics as well when we talk about collaborating.

A lot of the NEC procedures and formal communications, they can be a formalisation, right? We can submit and accept on the same day. And all the better if we've had that workshopping in the background on things like compensation events, quotations, that sort of thing. Programme submissions. So really, we're hoping that these systems aren't just somewhere to sort of lob these communications. Behind that should be the richness of these meetings and other conversations.

So bringing all this together, what does good look like, Glenn?

What good practice looks like

Glenn Hide: Well, timing. So notified as soon as the potential issue is identified. The clue is in the word. It says early. Not a, well, fairly early or, well, not as early as we might have done, but not as late as it might have been.

Before the matter becomes critical, when we still get a chance to be able to minimise the impact of that happening.

Content. So I think we've said, you know, clear, concise description of the matter. Don't be too wordy, but just make it nice and clear what the thing is. You know, you could draft an early warning and give it to a colleague, say, have a quick read of this. Does that make sense to you? I know you don't know anything about it, but do you understand what I'm saying there? That's always quite a good test.

Constructive tone, focusing on opening up the conversation. So don't start with, oh, this is a problem. It's going to be a right load of money. This is going to cost you. You need to try and be positive with this thing and make it clear that it's an issue. And we've got a bit of time to be able to do something about it.

And yeah, don't put the early warning in and kick back and think, well, that's it. We've got the regular requirement now for early warning meetings, the early warning interval. So it's more likely that we're going to have these regular meetings anyway. But it doesn't just start with the early warning and then stop and it's like, I've done my job. We need to keep moving forward in terms of that early warning sequence.

What are your indicators? Well, regular proactive notifications from both parties, the meetings being positive, being engaged at those meetings. The actions being clearly allocated and tracked. You can audit the early warning register and see who's been there, what the actions are, the fact that clearly it's being regularly reviewed and updated. And hopefully seeing that actually the number of early warnings to CEs, there is a ratio that we have quite a lot of early warnings and not too many compensation events. Now, it's not a definitive indicator, but it's a good clue that you're doing things right.

And you can think about how that sort of links to programme management, compensation discussions. But I can't remember, I don't think we really cover this. We'll pick up on this in future sessions. But if you don't put an early warning in, notify it, then we're going to see that it can influence how a compensation is assessed if you haven't done it. So commercially, if nothing else, you need to do it to protect yourself as a contractor. Otherwise, you could be accused of not giving an early warning and it may impact the assessment of a future CE.

Ben Walker: I must have been in such a positive mood when I put these slides together, Glenn. I completely forgot to mention the sanctions. So thank you for that. It was just occurring to me that we hadn't, as you said it.

Financial sanctions and protections

Ben Walker: Yeah. And well, let's just briefly talk about those. So there is a sanction. And sometimes I'm asked why was the sanction only on the contractor?

Well, so let's introduce that sanction. So the sanction is if you don't notify an early warning, which an experienced contractor should have notified, that's the test, then the project manager will notify you of this. And then later on, if a compensation event does arise and it's then assessed as if you had given that early warning, which you should have given.

And that's quite a big sanction and actually crops up in the disallowed costs as well in option C, D, E. So that's a really big one. And you know the kinds of things you might imagine there? Well, if we had had early warning a couple of weeks before, if it could have been given, then maybe we don't have critical path delay. So it could be big money here that starts getting struck out. So it's actually a really big sanction. And Glenn, I was going to raise it a little bit actually in the problems and solutions because sometimes I wonder whether that particular clause is driving some of the behaviours around early warnings where we just blanket everything rather than think through the individual risks. We were almost just ticking that box that we will never fall foul of that sanction. And I think that might be one of the problems rather than, you know, remaining a little bit more measured about the likelihood of that happening and just doing what we've got to do. And that means, of course, having good communications with your big team if you're a large tier one contractor and making sure that those threats and risks are coming up to you.

So to answer the question about, you know, why not the client? Well, I think there is a certain argument for there perhaps should be a sanction on the PM. There is a breach of contract, isn't there, which is a compensation event.

But, you know, the contractor's reputation might suffer as a result of the project manager not saying something, which are giving early warning of something they knew about. But really the sanction is pretty natural, right? Because you just forgo that opportunity. And I think this is one of the reasons I think clients should be looking at, you know, how many early warnings have my project managers notified? And I wonder whether one of the things, Glenn, is maybe a retrospective review of compensation events and asking as a team, which of these could we have early warned on? And actually, could we have taken some intervening measures on? Because not all of them do, but some of them might. So, yeah.

Glenn Hide: Yeah, I think the obvious sanction on the project manager is that, well, if you don't give an early warning about a potential problem, the contractor can't help you solve it and it might therefore become a compensation event that you didn't need to have ever paid for because they could have helped you. So that's the natural sanction against the project manager.

The right approach

Ben Walker: Absolutely. Okay. So the right approach, I think we've kind of said it. It's about understanding that it's a management tool, not a commercial activity. I think we've got to, I don't want to appear naive, right?

Once the events being, once the, sorry, once the early warning has been given and notified properly and it's on the register and we're in one of those early warning meetings, then of course we're going to talk about money. One of the things we might do is explore certain mitigations that might need instructions. We could use clause sixty five for that and the instruction of proposed changes to the scope to understand what sort of commercial impact one thing or another might have.

So and we might more broadly just discuss those and think about, you know, approximate costs and impacts to programme within those early warning meetings. The important thing, though, I think to acknowledge is that those conversations are healthy when you are having them verbally in a room and you're optioneering. It's very different if you're dealing with lots of communications and you just get one land on your desk, which looks as though it's a fait accompli and it's going to cost me a lot of money, which is not an opening conversation.

So I think, of course, we're going to discuss the options and part of that has got to be their feasibility and their delay and cost impacts as we explore the different mitigating options. But we do that in the meeting. So I think the wrong approach would be to do that straight off the bat in the initial notification, using it as that fixation, there we go, we did mention it, that fixation with clause sixty one five, sixty three seven, which are those sanctions. There's also one of the disallowed costs, which are those sanctions for not giving early warning.

And that kind of focus on whose fault is it, whose liability is it? Remember, early warnings, the early warning register, they do not change risk allocation. They do not change liability. That's all later. Forty five clauses later and then a bit more in clause eighty.

So really, maybe you need to do this with a coffee to check early on in the contract startup workshop, perhaps. We have got the same interpretation of early warnings, right? We know that they're a management tool. We're going to use them productively and we're going to have this open conversation because it can't harm us.

Playing cards close to the chest, there's sanctions. If we're open and we're genuinely trying to mitigate the problems in the ethos of what we've got set out in front of us with those procedures, then we're on the right track.

Anything to add, Glenn?

Glenn Hide: No, I think you covered that very much so.

Common problems and solutions

Ben Walker: OK, so we've got some common problems. Just conscious of time, wanted to give a good fifteen, twenty minutes to questions. So we can fly through these.

Yeah. So swamping the system, one party flooding with numerous early warnings. This is about education. Make sure that don't think by putting in fifty two early warnings on the first day. The first one, I remember it might snow was an early warning from a contractor issued on the second of May.

It doesn't change the liability. We can't do anything about it. Education. And after that, they were very good after that. They were worried. They thought it changed liability. It doesn't.

Over reliance on the systems. So train the team on the actual contract requirements rather than a system that might actually not have the process quite right.

No follow through. So don't just put the early warnings in and then sit back and think that's it. We need to make sure we're following through and the register, the meetings will pick up on those.

The blame. It's not as a liability shield, as you've already mentioned, Ben. This is about management, not whose risk is it, whose liability is it, which is why we don't have names and parties in terms of whose fault or whose blame.

Late missing notifications. Well, late early warnings can obviously again lead to potential financial issues if a contractor has not done it. So we need to make sure that we're getting those notifications in on time. And again, wrong folks in the meetings. Focus on solutions and focus on how we can improve for the project as a whole.

Don't be focusing on your own liabilities or sort of side or angle. Let's just, I always tell people, arrive at the early warning meeting, put your invisible hat on a hat stand and then arrive as a project person. And then when you leave the meeting, you could put on your contractor's hat or your client's hat and then outside the meeting think, well, that's an issue and whose fault was that or whose blame was that? But in the meeting, we're one project. We're one project team, and we're going to look at solutions to the problem. That should be the focus.

Ben Walker: Very much. And it echoes the boots argument, doesn't it? Get site input from people solving problems. And then we can put it through the commercial processes later. But why would we start with a narrow field of options when we can explore a larger one?

Time and time again, I've been really surprised just how effective this is when done properly. So get those practical minded people into those meetings. Don't have your commercial team dominate those meetings. You know, almost nervous to say what might be said. Open up the conversation, trust in the process.

Another one on the over reliance on systems, Ben, occurred to me is that I did used to find big pockets of practitioners thinking that you had to have an early warning before a compensation event. And that's obviously not true. And again, I think that might have been another, you know, you have to have an early warning and they always turn into compensation. That's simply not true. Another one is this idea of rejecting or accepting. There's nothing in the contract that precludes you from rejecting an early warning. But it does seem odd. It doesn't seem useful rather or practically useful to sort of say I don't want to hear any more warnings. So again that's probably resolved with a coffee, right? Why are you sending me this stuff? It's not helpful to the project. Can we phrase it slightly differently so that we can have an opening conversation? Actually add some value.

But yeah, I think we've got pretty much there now. I'm keen to open this to questions. I'm looking at the team. We've got lots of questions.

Q&A session highlights

Ben Walker: Perfect. So we've got some prompts here in case we don't have any. I think this is the first one, so bear with us.

We've got some technology that we'd like to try where we can ping questions directly up. So we've got a question on, ah look at that, thank you Phil. So Phil writes, potential key performance indicator relating to early warnings and clause sixty one five, targeting a low percentage of CEs where early warning could have been given but was not, resulting in an alternative assessment. CE would promote the use of them. So I think that's a great idea.

Yeah really good. So you're looking at compensation events and you're doing that kind of backwards audit I guess as a lesson learned. You know, where could we have got more value by leveraging that early warning process? Guys any comments on that?

Glenn Hide: Yeah, that's good. Yeah, we can just do a review of how many of the compensations was the accusation that you didn't give an early warning. So you didn't give an early warning, but you could have done. I guess it's not foolproof because you will have some project managers ticking the box yes every time, just in case.

Even that isn't foolproof. I like the idea, Phil. And if managed properly, that could be a good indicator. But a bit like the contractors who are trigger happy putting in an early warning, you could have a project manager saying, well, I'll say you could have given an early warning just to cover myself. I don't know if you could have done or not.

Why have we got KPIs? KPIs have to be useful. So I think if they're not measuring how many early warnings are replied to within two weeks is not useful. It's not telling us anything. I think this is an idea that would be far more valuable.

Can we bring another question in? Whilst we're waiting, I'll just look. Mark Haggerty said one earlier about multiple early warnings for the same event is an issue. Again, the answer to that one is just education issues.

So a little bit of discipline within the team to make sure you're controlling who's notifying the early warnings and having a little bit of internal governance where multiple people aren't sending an early warning at the same time and they then sort of duplicate a bit. But education should iron out those problems early. A valid point there, Mark.

Ben Walker: Yeah, we had another question, Glenn. Okay. What if you need to request a certain document or action from the client that doesn't necessitate an early warning meeting? Can that request be made within the early warning? What negative impacts can arise if this is not met?

Glenn Hide: Again I think this is the responsibility of a cloud based system where there is the right portal or the right form to raise the right communication. And that's where not all cloud based systems are the same and this is not a session where we're going to explore which ones we think aren't. But there needs to be the right place to do that.

So sometimes I have found that, oh well, early warnings are the only time you get an early warning meeting and then we get to discuss it. So I think it's just take that good approach you can have from early warnings and know that you can talk about other things in other places. So we want a form within the system that picks up some of these more minor stuff that doesn't necessarily need to be talked about at the early warning meeting. And don't forget, you're also allowed to talk to each other. So some of this stuff might just be a conversation and just asking for something might, you get that without formalising it.

But yeah, the system should have the right portal, the right flow for any communication that you need to raise.

Ben Walker: Absolutely. And I know the one, obviously I know well, we did introduce a kind of communication, general communication so that we can have those conversations for anything else. You know, it might be sharing meeting minutes or it might be things that haven't got a particular workflow built for them because they're just one offs or not used regularly.

And, you know, it strikes me that your question there might be one of those things that we wouldn't necessarily want to dilute the early warning register with so that we can keep our early warning meetings nice and concise.

So, yeah, no, I think the other thing I would say is be really careful. We perhaps ought to do another webinar on technical queries and early warnings and things like that, because, again, they're not in the contract, technical queries. I would say, though, that be really careful. Make sure your delegated authorities are in place properly and be really careful who's replying to these things if there is this feature to reply. What you sometimes see is that early warnings, you read through them and then you start seeing replies and actually it looks as though people are, are they changing the scope or not? They can't change the scope if they're not project manager.

But nonetheless, the communications and the actions following those communications appear as though the scope has changed. It's either changed or it hasn't. If it hasn't and someone's doing...

Closing remarks

David Allen: The question around KPIs. I wanted to come in at that point because setting a KPI has to be relative to the set that you're actually going to target. And so you need to make sure that it is an ad hoc set and you're not just leaning one direction or the other in terms of what you select, because that can provide you with the wrong sort of feedback if you're not doing a sort of an open review of what's coming through.

Do you understand what I'm saying, Glenn? Because I'm getting challenges elsewhere where people are being KPI'd on things once they've acted because of the information that's finally provided to them. And had they knew about that information at the beginning, they would not have even accepted to go to the next stage. And they're now being KPI'd on that. So you need to be very careful with KPIs that you've got the right baseline in there.

Glenn Hide: Yeah, absolutely. So there's two there. There's KPIs and also RFIs and TQs. And funny enough, you know, that stuff we've covered, David, isn't it, in our CECA bulletins? It might be something we chat about in a future webinar. But if people want more information on that, we have done a bulletin on KPIs. We have done a bulletin on how technical queries and request for information run alongside the NEC processes.

So we have got them running alongside that. So yeah, there's CECA bulletins on those two subject matters. We didn't even know you'd gone, Ben. That was fine.

The other thing I was going to add to all of those listening, the more rounded those feeding into that meeting are, the better. Because you're only going to get the proper outcomes if you're actually bringing in the right resource at the right time to advise on the challenge.

Actually, Mark's got a nice simple one. Perhaps a KPI for early warnings could be, has it mitigated the risk or made savings? So literally simple, with hindsight, yes. Did that early warning lead to something that solved a potential problem? That's a nice simple one.

We could just see what percentage of early warnings with hindsight we felt were beneficial and potentially reduced cost or avoided a quality issue.

David Allen: That's a great idea and very easy for the vendors to manage because you just have a portion of the quotation, which was over and above what would have been if you hadn't had the early warning. So I think that's a really nice one.

But again, I've come back to the point I made earlier. What happens if the number of early warnings you're putting in actually do lead to additional monies? Is that a positive thing or is that a negative thing? How are you weighting your KPI?

Ben Walker: Just a question. I think the money you have to spend on a project, I guess, is inevitable. And the one thing we can do is optimise what we do to reduce that. So I guess it's how much more would we have spent if we hadn't taken project management intervention and we'd simply been a passenger.

Glenn Hide: Yeah, and I think that's a really good one, actually. And a real opportunity to have the contractors to demonstrate the real value they're adding.

Okay. We're perhaps calling it late contractor involvement or during during the project involvement rather than early contractor involvement. But that early warning, yeah, absolutely.

The building had a power cut so that's why I disappeared for a little bit. We're just bringing the slides back up. We haven't catered for that enough. So there we go. There was an early warning there.

A couple of people have mentioned about TQs and RFIs. And actually, I think we do need to labour that point. So we have got the CECA Bulletin that talks about how they integrate with each other. So I would recommend people take a look at that one.

I'll try and look up the number in the background as to which one that is, because the trouble is otherwise people might think, well, we put all our TQs and RFIs through as an early warning and you don't want that. So we really don't want that. They are a separate role.

So number forty seven is the CECA Bulletin that covers how RFIs and TQs can work in harmony in a cloud based system in an NEC contract. So my simple advice is if it's a fairly small minutiae issue that could be an issue, we just need an answer, then put in as a TQ.

If it's starting to get urgent, you could then put that in as an early warning to say TQ number one needs an answer soon. So we don't want to swamp the early warning system with all TQs and RFIs, which is why they should be a separate system.

So George has said, is it realistic to think that early warnings can be part of a robust change management system strategy on an NEC contract? Well, I think the most important thing there is to emphasise that early warnings is not a commercial tool and it's not the start of a compensation process and some early warnings will prevent compensations from ever happening.

But equally early warnings might minimise the impact of compensation events going forward. So I think it's just important to understand the separation of early warnings from compensation events and seeing them for what they are. And they are not a merge system where they just go into each other. Absolutely not.

But, George, they are, in a sense, maximising your options for change. So they're giving us a bigger spread of options and opportunities for that inevitable change that we all know will happen. So, yeah.

Ben Walker: Great stuff. Well, thanks so much, everyone. We're coming up to the half past. I just want a couple of seconds just to advertise our next one. So several other topics in mind that would be good to do as the second one now. But I think we've landed on this.

So David, Glenn and I were thinking that we would perhaps do the second episode on notifying compensation events, so we'll explore that and the instructing of quotations. There's a little bit of nuance around there, around who can state assumptions about compensation events and things like that, who should be notifying them, what happens if we don't notify them. I'm sure we might have a chance to look at some interesting Z clauses that play with things a little bit with this and turn things upside down and inside out.

We'll have a look at those too. So the next session twenty eight days from today, sixth of October, Monday, same time. We hope you can join us. Glenn, David, anything to finish on?

David Allen: What I'll do is, from a CECA perspective, I hope that those that joined us today are actually finding this of some benefit. We think it's all about increasing awareness around the contract, the way we use it. It's ultimately down to behaviours at times. I know that our industry is under enormous challenge from resource.

And that doesn't help sometimes. But when the NEC drafting team developed the clauses that they've given us today to work with, they had an intent. So it's making sure that whatever we do is actually aligning with that intent and that will then give us or help us deliver the more positive outcomes that we're looking for and avoid some of the challenges that we sometimes face that don't really help with efficiencies of delivering infrastructure projects.

So we'll continue to do this if it's bringing value. And my thanks are to Glenn and to Ben for making this happen. As I say, this was the first flight. We're looking forward to many more.

Ben Walker: Excellent. Well, that was fun. That's all I think. That was great. So hopefully other people found that fun as well. Who'd have thought it? An hour's webinar on NEC could be fun. Thank you very much. I'll see you next month for another one.

Cheers, Ben. Cheers, David.

‍