NEC4: A Positive Approach to Early Warnings!

We dig into the purpose and practice of NEC early warnings and show how to turn them from admin into a real project tool. Clear notifications, a live register, the right people in the room, and meetings that produce actions, not arguments.

• why early warnings are a positive project tool
• what to notify and when under Clause 15
• separating early warnings from compensation events
• maintaining a useful early warning register
• running frequent, focused early warning meetings
• using digital systems without letting them dictate process
• sanctions for late or missing notifications and how to avoid them
• common pitfalls like flooding, duplicates and blame
• smarter KPIs that reward mitigation and learning
• how TQs/RFIs sit alongside early warnings

Join us next time: “Notifying Compensation Events” — Monday 6 October, same time

View the webinar: https://www.gatherinsights.com/en/webinars
Join the LinkedIn Group: https://www.linkedin.com/groups/2893228/

Transcript

Welcome & Series Context

Glenn Hide 0:02

Good afternoon, everyone. Welcome to this our very first webinar. So we're very pleased to have you online. I'm Glenn Hyde. 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 Seeker, we've been publishing monthly bulletins. Hopefully, some of you have read some of them. Number 57 was our last published bulletin. And each month we're taking a look, a sort of 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 Seeker?

CECA’s Role and Training Purpose

Agenda: Early Warning Focus

David Allen 0:47

I certainly would. Thank you. Hi, I'm David Allen. I'm the Executive Director for Seeker 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, who will deliver the session. I'd just like to say a few words about Seeker and why we're doing this. The Civil Engineering Contractors Association, SECA, is a not-for-profit member-led trade association that represents and promotes civil engineering contracting organizations that deliver and maintain 70 to 80 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 seeker.co.uk. But in reference to today's event, this has been delivered under our skills and training call 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 organizations that they work for. As Glenn mentioned, uh 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, or 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 discussions with Glenn and Ben early this year is 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.

Why Early Warnings Matter

Ben Walker 3:12

Thank you very much, David. Um, welcome everybody. Really uh excited to be a part of this. And uh over this series of episodes looking at NEC, we hope to really strike a chord between uh 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. Um, so welcome. Uh a little bit of uh an introduction, why should you spend the next 40 minutes plus questions watching us today? Um, we're gonna cover uh why this topic matters, firstly, and um what is an early warning? So early warning is not a defined term, so it's got a literal interpretation. Uh so Glenn will take us through those two things. Um, next, I'm gonna look in a little bit of detail around actually giving early warning by notifying. And what does that mean? What do we have to put in the communication there and and how do we manage that then within the early warning register? Uh next up, then we'll look at uh early warning meetings, who should attend, how frequently should we have them, uh, and what's the real objectives there? Are we just sitting around agreeing that it's bad, or you know, or what do we do about it to take those early interventions? We'll have a little look at what looks good, uh bringing all those things together, and also by difference, those common problems, uh, perhaps some of them logistical, practical, systematic, and and actually quite often behavioural. So we'll look at those and and maybe ways in which we can uh um boil the wheels a little bit and getting things back on track. So a lot to understand about the intent of only means here, and then we have that nice long QA session there. Uh we really would like you to get involved. So please do use the chat. Um, I think we're only going to be monitoring the LinkedIn chat as it happens live, uh, 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. Uh, but we'll be uh mashing all the QA 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 uh 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 managers? We don't want to be project administrators, we are project managers and part of that function influencing the future. And early warnings, there's no better example of any C 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.

Defining “Early” and “Warning”

Glenn Hide 6:10

Absolutely, such an important topic. It's a very, 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, um, but there's still there's still room for improvement. And I think the survey we ran yesterday, but let's say last year, proved it. So we did an industry survey um through uh our group, and uh we asked people, what percentage of you are still finding people on your projects who think early warnings are a negative process and who view them negatively. And the result was that 53% of people still found uh 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 guys. Um, 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 um of these uh of this session. Why? Why are we still finding people who think this is negative? So we're gonna pick up on some fundamental points around the early warning process we need to know and understand. So it's a 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. Um and a collaborative approach increases project success. Um, that's pretty uh self-explanatory, I think. And then another quote from uh NET contracts where they quote the foresight applied collaboratively mitigates problems and tricks 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 15 of the contract. So all of the clauses within section 15, we're going to make sure we fully understand them. There's not too many, um, but we need to understand them. Uh, transform early warning from early warring. Um, must admit, Ben put that in. I quite like that. Um, and uh, yeah, so early warnings aren't about creators going to war. Um, in fact, we're peacemakers. Um, so the complete opposite of warring um is what the early warning process uh should be. We're gonna look to seek collaboration and problem solve and identify and avoid common pitfalls that tend to happen around um early warnings. So that's what we're gonna try and achieve um in this session. So, what's an early warning? Well, this won't take too long because there's only two words to analyze. 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 advanced 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, Bit?

Contractual Duties under Clause 15

What to Include in a Notification

Ben Walker 9:22

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 as what they're not about, which is useful to know, so that we don't fall down the hole of um, I don't know, in particular, I guess, conflating them with compensation events. They're 45 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, but so um it does have this literal, this literal sense and uh, you know, it's few words as possible, um, very NEC, very clear. So, yeah, I think then we'll probably start having had that literal 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 10.1 that we have to act as stated in contract. So this isn't optional, okay? 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 as soon as aware. So I think when thinking systems and and agility, uh, 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 there's sanctions for not doing it, but actually it's pretty safe to do it, very safe. Um, and it's which could so we're not interested in late notifications. This is early warning. So it's hasn't happened yet. It could in it could impact us. There's actually four bullet points underneath that first sentence. Um we've abridged these into three little icons here. Increase total the prices, uh, delay completion, there's a separate bullet point for delay and key date, or impair the performance of the works in use. Um, 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 a an option A um lump-term contract or a cost reimbursable contract, it doesn't know about the payment mechanism. This is the core clause, and yet we have this ability to warn about something that could increase the contractor's total cost. Now that that really should speak to us and communicate really what this is about. Um and it's saying to us that um it's saying to us that um that the if the contractor is is feeling some pain, then it'd be very short-sighted for the project manager to um to not um play a role there in helping you know address that pain and mitigate it. So even in a even in a lump sum, or as we call it, priced contract uh with an activity schedule, there's still the need there and the option to communicate um uh a risk or a pressure on the contractor. Bear in mind as well, uh, just to finish with slide, notifications are formal communications, so they do need to follow clause 13. And uh Glenn, do you want to say a few words about your experience from the project manager contractor? Do you find these are in balance? I mean, I'm I'm not so sure personally.

Glenn Hide 13:04

Yeah, it still tends to be the contractors uh would notify a majority of the early warnings. So to some degree, I think we're to expect that because they're the ones at the cold 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-subcontractor relationship. So, yeah, you do tend to get more from a contractor, but obviously, as you've uh 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 13:36

Yeah, and you know, it's not really believable to say that there aren't these things out there, right? That the project manager, the client are dealing with political pressures, um uh press, um, 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 collaborative comes in. We are trying to mitigate problems before they happen and maximise the opportunity for um intervention. So a few a few key points there. Um Glenn, in terms of giving early warning, um, do you want to take us through the rudiments of what we must do and what might be optional?

Managing the Early Warning Register

Glenn Hide 14:20

Yeah, so when when we, whoever we are, whether we're a project manager or contractor, so when we're notifying um an early warning, um 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 uh uh uh an essay, um a book, but nice and concise, but in enough detail that makes it clear what the issue is. We're not gonna solve it in the early warning. We just want to get across some information to know what we are actually talking about. The nature of the potential impact, just to some degree. So we don't want to solve it. Um, we don't want to um 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 minimize the impact, okay, we might slow some of those seeds just to again show that it's a very positive nature of this particular um early warning. Um optional content. Um to the next stage as well, so we've described what the thing is, and normally there'll be on a on a cloud basis, maybe a tick box as to what it could impact, the three bullets that Ben mentioned. And then do we need an early warning meeting? Not always. Um and often we'll have a meet, a regular meeting set up now, especially with NEC4. Um 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. Well, 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, we'll decide how important um that is. Um, 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. Um, 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.

Digital Tools: Use and Misuse

Ben Walker 16:31

Yeah, I'd echo that, Glenn. And I 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? Um I am I setting the groundwork to having that discussion, or are we are we making closed sort of beta compli statements where we're we're we're we're making assertions about one thing or another, or maybe prematurely trying to seek the solution? Um and I know you've got a slide in a minute around how digital tools perhaps um approach this with replies and things. I think that would be a really useful part of the conversation. Um, so yeah, um I completely agree with everything you said. There we 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 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 was a was a useful one. Okay, um mentioning the early warning register, so there is a requirement, um, an obligation on the on the project manager to keep a risk register, uh, or as NEC4 calls it, the early warning register. Um, and very simply, it's a register of all of the notified early warnings. Um so as soon as they're notified, they get put on the register. Um, and there is actually an opportunity to pump prime the register from contract data parts one and two. Uh, so there's an identical entry in contract data part one and part two, so that pre-contract date you can actually pump prime uh this register. I think importantly, I think Len'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. Uh, 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 provisional sum schedule. You'd you'd certainly need some some uh some careful Z clausing to bring that into effect anyway. So quite often we see these uh not often now, but now and then I still see a risk uh or an early warning register priced up as a kind of provisional sum tool. Definitely that's not what it's for. Um so what do we put on it? Well, uh the contract tells us um the register has uh you know 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. Uh, 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. Um, this is about getting the issues on the table in the register for conversation. Uh put a notification date on there just so that we know when they've been notified. Um, and the status. So, this status, again, this is just something that I've always done. Um, when putting uh CMAR together, I was I was wondering about this obligation to remove or deciding which risks could be removed from the register. I never liked to remove them because I think they're such an important source of lessons learned, and we can uh share them perhaps across the program 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 into live or avoided or passed. The other thing Glenn mentioned is we wouldn't price early warnings, and I think that's that's sensible, certainly in those opening notifications, but I think a lot of people wanted some form of of being able to prioritize and weigh them, and so um 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 that have likelihood and consequence and get a product of maybe the five by five matrix, bringing a bit of that risk discipline into these things. Um, but the really important bit on the register, I think, is tracking those proposals and solutions and actions. And remember uh that minutes to a meeting are not communications, so just because we've recorded the actions here, um, and 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 uh mitigation. If that requires, for instance, a change of scope, then the uh you must go and action that separately. So the minutes aren't enough, we need to go off and actually action those things uh properly. Anything to add, Glenn?

Glenn Hide 21:15

Um, only I think the 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, 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.

Ben Walker 21:43

Yeah, fair point. I think I'd agree with that. Um, and you know, talking about how people uh may systematically approach some of these um 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 galvanized 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, Claire?

Early Warning Meetings that Work

Glenn Hide 22:07

Yeah, I mean, look, generally cloud-based systems, there's a few out there, and uh 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 would come into it. So we're talking generally about systems, not sort of homing in on one in one in particular. Um, all of these, a lot of these cloud-based systems, just with regards to the early warning process, um, 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, um, you can respond, and some early warnings that uh don't need a meeting, they can be responded to and we don't need a meeting. And others, most of them, we're gonna discuss at the early warning meeting. And then when you update the actions into the register, that is the response that's quite that's required. So the slight frustration is that some early warnings, uh some cloud-based systems suggest that you've got to respond to an early warning within the period for apply, which actually 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. Um so it's really just a reminder, not so much just the problem with the cloud-based systems, but um that you don't have to respond to an early warning. Um, but some early warnings can be responded to, which might then mean that we either don't just need to discuss it at the meeting or that it's a very quick discussion. Um so that's just one uh 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 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 24:21

Yeah, I'll echo that, Glenn. Might even be able to shed a little bit of light on how on how one system uh uh did adopt this. Although um quite often you'll find a um a box or a tick or a setting that will say this isn't necessary. Um but a lot of clients do want to see that the early warnings have been acknowledged. Um, 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 uh 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 and that's okay because okay, I need I know I need to reply to a quote where I need and and they kind of sit there and persist and go amber and red until you deal with them. Early warnings are different though. You know, the all the authors of the contract, they they're not gonna take us, I guess, an average time frame for avoiding a risk. You can't, can you? And price adjustment for inflation might never uh um uh be avoided or passed, it's uh it's an ever-present risk. So, so it's not appropriate to reply to it and then it disappear off your radar. So the the the risk register, um, sorry, the early warning register uh and and maybe the program register are you know things you really want on your dashboard and keeping keeping them in mind. The last thing I would say as well, and and 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 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 um proposal solutions and actions and how many of them there are relative to the perhaps the risk score. So so you can see whether you're taking a proportionate um measured uh approach to those things. So, yeah, all good points, and um yeah, the system.

Sanctions and Behaviours

Glenn Hide 26:17

Yeah, and I I haven't thought we haven't talked about this, but here's a question we can ask our uh our viewers. Um, is there a valid KPI to do with early warnings? Because I've never thought of one. Um, I have seen people try and write KPIs. How many open early warnings have we got? Uh that should be irrelevant. You could have not many or you could have lots, but you could have a project that doesn't have many, 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 cities 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.

Ben Walker 27:08

That's a really good point. And you know, maybe the the vendors of the software could come forward with some of the things and share those as well, um, 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 that's the point there. Okay, uh moving on. So much to talk about on this one on this one topic. Um, we'll talk about early warning uh meetings next. I think uh I was going to talk through this slightly.

What Good Looks Like

Glenn Hide 27:33

Uh I can pick up this one. So who can call the meetings? Um, so contractor or the project manager. Uh a lot of contractors, I've 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 wasted time. A lot of them put their hand up. And I said, Well, you do realize 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, uh, one instruction, in fact, that the contractor can give in the whole contract. So either party can instruct the meeting. Um, 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 um being being made. Also with NEC4, we've got this minimum early warning interval that the client's now forced to think about um in terms of uh 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 or monthly uh we will be having an early warning meeting. And sometimes I've seen that set at two weeks, occasionally a week. Um so that's very useful, introduced with NEC4. And then just really focus on the meeting objectives, which is covered in clause uh 15.3. So cooperate in considering the proposals, look for solutions in terms of who it's going to affect, decide on 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 of the open early warnings and see if there is 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. Um as long as we keep reviewing it, it's doing its job. Um so there should be no measure or uh 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 uh 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 um to have those as um as uh As a discussion at the meeting. Anything to add on that one, Ben?

Ben Walker 30:05

Uh yeah, just one thing. Um, I was popping into my head. I was delivering a training course a couple of months ago, and uh one of the delegates said something every day is a school day, right? On the 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 uh ingenio or meaning uh clever and later ingenuity uh engineers derived from this. It's about problem solving and uh and coming up with clever ideas. 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, as MEC calls them, the uh main contractor, the client, the designer, are all together discussing the program. Hopefully they've got a contemporaneous program 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 on the original pass of the program. 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 um, and I know this debate has raged uh elsewhere as well, whether we're missing a trick and we should be thinking about opportunities as well as warnings. Um, and I think again, having that mindset is probably helpful.

Glenn Hide 31:49

Yeah, definitely. Um, I had another person in a training session recently say, I don't really like the word warning. That feels a bit confrontational. Um, 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 uh a heads up? And I did laugh, um, 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.

Common Pitfalls and Fixes

Ben Walker 32:11

Absolutely. And and above all else, I think we've got to break that adversarial connotation. Um, you know, if I had another anecdote off the top of my head, I would I would remember the one about the client banging the table at the commercial meeting. Um, you know, I don't want to see another early warning this month. Uh, you know, you may or may not have experienced that yourselves. Um, but that just smacks of totally misunderstanding the process. And it might not all be the client's fault, you know, if the if the contractor is weaponizing these uh and and they become tedious and only about future conversation events rather than genuinely mitigating problems on the project and achieving a better success for all. Um yeah, and and equally when the contractors 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. Uh, 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 or not spending at all. Project management, not project administration, project management. Um, so when to hold an early morning meeting, I think uh Glenn, you briefly covered this already. Um, in under NEC4, there is now an early morning meeting interval. Um, and this is uh identified in contract data part one. And I think really there's no harm in maybe setting this weekly. Um, it probably is a nice uh agenda item on on a progress meeting, um, and it just keeps those fresh. I've seen these happen really well. Um, I could mention many clients who have them on a whiteboard uh projected straight from the system and they're running through them, deciding whether or not they can tweak the uh the likelihood or impact score if they if they do that, uh, and really um adding proposals, solutions, actions, and managing it live collaboratively around that system. So, you know, I talk about culture, knowledge, and discipline. Again, those systems, however you do it manually on a spreadsheet or on a system, you know, get around the table, use it for the project management tool that it is. Um what else have we got on the slide? Uh so yeah, uh when the issues are complex or unclear, um, multiple parties are affected, uh, creative solutions are required. So, yeah, this is about perhaps dealing with the more complex stuff. Um meetings are not needed, perhaps if things are very clear and obvious, or if a simple response can close out the matter. Um and uh yeah, but you know, when in doubt, there's no harm. And that kind of uh interval of early warning um does allow you to keep that cadence and that rigour. But remembering what Glenn said as well, it's the 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, would you mind terribly meeting with me to discuss this problem I might be having? Just instruct it. Uh, and again, there's another benefit of these web-based tools because they they handle the language for you. So the problem of politeness perhaps isn't there. Uh, but um, we'll perhaps say a couple of other things about these systems not becoming a barrier, right? We don't want to be um using them to hide behind or to stifle actual human conversation. So, again, perhaps we'll missed 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 formalization, right? We can submit and accept on the same day, and all the better if we've had that workshopping in the background on on things like conversation events, quotations, that sort of thing. So program 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?

Q&A: KPIs, TQs/RFIs, Practicalities

Glenn Hide 36:07

Well, uh, timing. So notified as soon as the potential issues identified. The clue is in the word, it says early, not uh, well, fairly early or well, not as early as we might have done, but not as late as it might have been. Um, before the matter becomes critical, when we still got a chance to be able to minimize the impact uh of that happening. Uh content. So I think we've said, you know, clear, concise description of the matter. Um, don't be too wordy, but just make it nice and clear what the thing is. You know, you could you could draft an early warning and give it to a colleague, say, I 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? So that's always quite a uh quite a good test. Um constructive tone, focusing on opening up the conversation. So don't start with, oh, this is the problem, it's gonna be a right load of money. This is gonna cost you. Um you need to try and be positive with this thing and uh make it clear that it's an issue and we've got a bit of time to be able uh to do something about it. Um and yeah, don't put the early warning in and kick back and think, well, that's it. Um we've got the regular requirement now for early warning meetings, the early warning interval. So it's more likely that we're gonna have these regular meetings anyway. Um, 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 um in terms of that um that early warning um sequence. And 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 um who's been there, what the actions are, the fact that clearly it's being uh regularly reviewed and updated. Um, 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. Um then you can think about how that sort of um links to program management, compensation discussions. Um, 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, uh notify it, then we're gonna 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 CEO.

Ben Walker 38:37

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. Um, yeah, and uh well, let's just briefly talk about those. So there is a sanction, and sometimes I'm asked why it was the sanction only on the contractor. Um well, so that let's just 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, um, then uh the project manager will will notify you of this. And then later on, if a compensation does arise and um 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 it actually crops up in the disallowed costs as well in option C, D and E. So that's a really big one. And and you know, the kinds of things you might imagine there. Well, if we had had early warning a couple of weeks before, um, 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 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 we're 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 1 contractor and making sure that those 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 should there perhaps should be a sanction on the PM. Um, there is a breach of contract, isn't there, which is compensation event. Um, but you know, the the the contractor's reputation might might suffer as a result of the project manager not saying something, which which uh giving early warnings or something they knew about. Um, but really the sanction is pretty natural, right? Because you just forego that opportunity. And I think this is one of the reasons I think clients should should be looking at you know how many early warnings are my project managers notifying. And I and I wonder whether one of the things, Glenn, is is maybe a retrospective review of compensation events and asking as a team which of these could we have early warning on and actually could we have taken some intervening measures on? Because not all of them do, um, but some of them might.

Glenn Hide 41:11

So yeah, um 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 uh the project manager.

Ben Walker 41:30

Absolutely. Okay. Um, so the right approach, I think we've kind of said it. Um 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? Um, once the events been uh 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 um certain mitigations that might need instructions. We could use clause 65 for that and the instruction of proposed uh changes to the scope to understand what sort of commercial impact one thing or another might have. Um, so and we might more broadly just discuss those and think about you know approximate costs and impacts to program 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 beta company 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 a um that fixation. There we go, we did mention it. That fixation with clause 615637, which are those sanctions. There's also one of the disallow costs, which are those sanctions for not giving early warnings. Um, 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 they do not change liability. Um, that's all later, 45 clauses later, and then a bit more in clause 80. Um, so it really and maybe you need to do this with a coffee to check early on in the contract startup workshop, perhaps. We we have got the same interpretation of early warnings, right? We know that they're a management tool, we're gonna use them productively, and we're gonna have this open conversation because it can't harm us. Um playing cards close to the chest, there's sanctions. If we're open and we're generally trying to uh mitigate the problems um in the ethos of what we've got set out in front of us with those procedures, then we're on the right track.

Glenn Hide 44:02

Uh anything to add, Glenn? No, I think you cover that uh very much so.

Ben Walker 44:08

Okay, so we've got some common problems. Uh, just conscious of time, wanted to give uh a good 15-20 minutes to questions. So um we can fly through these.

Glenn Hide 44:18

We'll fly through. Yeah, so swamping the system, uh, one party flooding with numerous early warnings. This is about education. Make sure that uh don't think by putting in 52 early warnings on the first day. Uh the first one I remember it might snow was an early warning from a contractor issued on the 2nd of May. Um, 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, but it doesn't. Over reliance on the systems, uh so train the team on the actual contract requirements rather than a system that might actually not have the process uh quite right. Uh no follow-through. So don't just put the early warnings in and then sit back and think that's it. Um we need to make sure we're following through and the the register, the meetings will pick up on those. Uh 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, uh, which is why we don't have names and parties in terms of who's fault or who's blame. Late or missing notifications, well, late early warnings can obviously um again lead to potential financial issues if the contractor's not done it. Um so we need to make sure um that we're getting those notifications in on time. And again, wrong folks in the meetings, focus on solutions and focus on um how we can improve for the project as a whole. Don't be focusing on your own liabilities or um sort of side or angle. Let's just I always tell people arrive at the early warning meeting, put your invisible hat on a co on a hat stand, and then arrive as a project person. And then when you leave the meeting, you could put on your contratter's hat or your client's hat, and then outside the meeting think, well, that's that's an issue and whose fault was that or whose blame was that. But in the meeting, we're one project, um, we're one project team, and we're going to look at solutions to the problem. That should be the focus.

Next Topic Teaser & Closing

Ben Walker 46:10

Very much, and it echoes the the boots argument, doesn't it? Get get get get sight input from people solving problems. Uh, and then we can put it through the the commercial processes uh later. But why would we start with a narrow field of options when we can explore a larger one? And 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, um, you know, almost nervous to say what might be what might be said. Open up the conversation, trust in the process. Um, another one on the over-reliance of systems, Glenn, occurred to me is that I 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 events. That's simply not true. Um, 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, babe. But it doesn't seem useful rather, or practicably useful, to sort of say I don't want to hear any more warnings. So again, that's probably resolved with a coffee, right? Um, why are you sending me this stuff? Uh it's not helpful to the project. Uh, can we phrase it slightly differently so that we can have an opening conversation and actually add some value? Uh but yeah, I think we've got pretty much there on now. I'm keen to open this to questions. I'm looking at the team, we've got lots of questions. Perfect. So we've got some prompts here in case uh we don't have any. I think this is the first one, so bear with us. Um 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. Um, so Phil writes uh potential keep performance indicating relating to early warnings in clause 615. 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 early warnings. I think that's a great idea. Yeah, really good. So you're looking at um conversational events and you're you're doing that kind of backwards audit, I guess, as a lesson learned. You know, where could we have got more value by by leveraging that early warning process? Um guys, any any comments on that?

Glenn Hide 48:27

Yeah, no, I think it would be that's that's that's good. Um yeah, we can just do an or do a do a review of um how many of the compensation was the accusation that you didn't give an early warning. Um but uh you 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. Um, and if if managed properly, that could be a good indicator. But um, a bit like the contractors who tricky happy putting in an early warning, you could have a project manager saying, Well, I'll 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.

Ben Walker 49:09

So KPIs, right? KPIs have to be useful. So um I think you know, if they're not measuring how many early warnings are applied to within two weeks is not useful. It's not telling us anything. I think this as an idea would be far more valuable. Uh can we bring another question in?

Glenn Hide 49:28

Whilst we're waiting, I'll just look Mark Haggerty um said one earlier about multiple early warnings for the same event is an issue. Again, the answer to that one is just education. Um so a little bit of discipline within the team to make sure you're controlling uh who's notifying the early warnings and having a little bit of internal governance where you know multiple people aren't sending an early warning at the same time and they then sort of duplicate a bit. But education um should iron out those problems early. A valid point there, Mark.

Ben Walker 50:02

Um I think David, you're uh you're on mute, David, if you wanted to chip in there.

Glenn Hide 50:12

There was another question flashed up.

Ben Walker 50:14

I don't think we can hear you. Just just just whilst we're we're thinking about that, David, I'll just see if we can get you on on off mute again. Um yeah, we had another question, Claire.

Glenn Hide 50:26

Okay. Uh what if you need to request a certain document or action from the client that doesn't necessitate an uh early warning meeting? Can that your request be made within the early warning? What negative impacts can arise if this is not met? Well, again, I think this is the responsibility of a cloud-based system where there is um 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. Um, but there needs to be the right place um to do that. Um so sometimes I have found that, oh, well, early warnings uh the only time we get an early warning 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 um 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 might you you get that without formalizing it. Um, but yeah, the system should have the right portal, the right flow for any communication that you need to raise.

Ben Walker 51:43

Absolutely. And I know the one, obviously, I know well, um, we did we did introduce uh kind of communications, general communications, 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 and you know, it strikes me that your question there uh might be one of those things that we wouldn't necessarily want to dilute the early warning register with, um, so that we can keep our early warning meetings nice and concise. Um, so yeah, no, I 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 who make sure your delegated authorities are in place properly. Um be really careful who's replying to these things if there is this feature to reply. Uh what you sometimes see is that early warnings you 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 a project manager, but nonetheless, the the communications and the actions following those communications appear as though the scope has changed. It's either changed or it hasn't.

Glenn Hide 52:55

If it hasn't, then someone's doing I don't know if everyone's lost Ben, but I've uh I've got Ben frozen there. Uh any other questions?

David Allen 53:12

Can you hear me? Can you hear? Yeah, okay. Sorry about that. This is our first webinar, and we're having we're having a few challenges, and this is one of them. Um, 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 then? Because I'm I'm getting challenges elsewhere where uh people are being KPI on things once they 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 yet 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 54:19

Yeah, absolutely. So there's two there's KPIs and also RFIs and TQs, and funny enough, you know, that's stuff that's stuff we've covered, David, isn't it, in our in our Seeker bulletins. Um it might be something we chat about in a future webinar. But um, if people want more information on that, we have done a bulletin on KPIs. Um we have done a bulletin uh on how uh technical queries and requests for information run alongside um the um the the the NEC processes. Um so we have got them uh running alongside that. So yeah, there's uh uh speaker bulletins on those um two subject matters. We didn't even know you'd gone, Ben. That was fine.

David Allen 54:59

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

Glenn Hide 55:20

Actually, Mark's got a nice simple one. Uh, perhaps a KPI for early warnings could be has it mitigated the risk or made savings? So a literally simple with hindsight, yes. Um, did that early warning lead to something that solved a potential problem? Um that's a nice simple one. Um, we could just see what percentage of early warnings with hindsight we felt were beneficial and potentially reduced cost or um avoided a uh a quality issue.

Ben Walker 55:52

That's a great idea. It's 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 warnings. So I think that's a that's a really a really nice one.

David Allen 56:04

Well, and but again, I've come back to the point I made earlier. What happens if the number of uh DWNs 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? Just a question. Yeah.

Ben Walker 56:25

I I think there are never the the money you have to spend on a project, I guess, is is inevitable. And the one thing we can do is optimise what we do to reduce that. So I guess it's it's how much more would we have spent if we hadn't taken project management intervention and we'd simply been a passenger server. I think that would be Yeah, I think that's a really good one, actually. And and you know, real opportunity there for contractors to demonstrate the real value they're adding. Um okay, we're perhaps calling it late contractor involvement or or during during the project involvement rather than uh early contractor involvement. But that early warning, yeah, absolutely. Um really the the building had a power cut, so that's why I disappeared for a little bit. We're just bringing it bringing the slides back up. We hadn't catered for that inevitable.

Glenn Hide 57:10

Oh, so there we go. So there was an early warning there. Um, a couple of people have mentioned about TQs and RFIs, and actually, I think we do need to labor that point. So we have got the speaker bulletin um that talks about how they integrate with each other. So I would recommend uh people take a look at that one. I'll uh 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've 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. Um so number 47 um is the speaker bulletin that covers how RFIs and TQs can work in harmony in a cloud-based system in an NET contract. So my simple advice is uh if it's a fairly small minutiae issue that could be an issue, we just want to get an answer, then put in as a TQ. Uh if it's starting to get urgent, you could then put that in as an early warning to say TQ number 71 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 a few of you have picked up.

Ben Walker 58:23

Okay, uh last question. Is it we'll try to one more?

Glenn Hide 58:29

So George has said, is it realistic to think that early warnings can be part of a robust change management system strategy on an ET contract? Well, I think the most important thing there is to emphasize that early warnings is not a commercial tool and it's not the start of a compensation event process, and some early warnings will prevent compensation events from ever happening. Um, but equally, early warnings might minimize the impact um of uh 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 merged system where they just go into each other.

Ben Walker 59:05

Absolutely not. But George, um, you know, they are in a sense maximizing your options for change. So they're giving us a bigger spread of options and opportunities uh for that inevitable change that we all know uh will happen. So yeah. Great stuff. Well, thanks ever so much, everyone. We're coming up to the half past um, I just want to a couple of seconds just to advertise our next one. So um I've got uh several other topics in mind that it would be good to do as the second one now. But um, I think we've landed on this. So uh David Glenn and I were thinking that we would perhaps do the second episode on notifying compensation events. So we'll explore that um and the instructing of quotations. There's a little bit of nuance around there, around who can um uh state assumptions about compensation events and things like that, um, who should be notifying, what happens if we don't notify them. I'm sure we might 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. So we'll have a look at those two. So the next session, um uh 28 days from today, uh 6th of October, um, Monday, same time. Uh, we hope you can join us. Glenn, David, anything to finish on?

David Allen 1:00:17

Yeah, from my perspective. Sorry, Glenn, do you want to what are they? Go ahead. From my from the Seek perspective, um, I hope that those that have joined us today are actually finding this of some benefit. We think it's all about increasing the awareness around the contract, the way we use it. It's ultimately down to behaviours at times. I know that our industry is is under an enormous challenge from resource, uh, 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 um we'll continue to do this if it's bringing value. And I'll thanks, my thanks are to Glenn and to Ben for making this happen. As I say, this was the first flight uh we are looking for.

Glenn Hide 1:01:22

I just add up, I think. Excellent. Well, uh that was fun. Um that's all I think. Uh that was great. So uh hopefully other people found that fun as well who'd have thought it. An hour's webinar on NET could be fun.

Ben Walker 1:01:37

Thank you very much. Uh see you next month for another one. Cheerio. Cheers, David.