A Positive Approach to Early Warnings!

Sam. Okay, we're live. We're live. Glenn, excellent presentation.

Good afternoon everyone. Welcome to this, our very first webinar. So we're very pleased to have you online. I'm Glenn Hydes. I run a company called GMH Plan 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?

I certainly would. Thank you. Hi, I'm David Allen, I'm the executive director for Seeker 7 and thank you for joining us here for our first NEC contract webinar series. Before I hand over to Ben and and Glenn from their various companies, we will deliver. We will deliver the session. I'd just like to say a few words about Seeka and why we're doing this. The Civil Engineering Contractors association is a not for profit member led trade association that represents and promotes civil engineering contracting organizations that deliver and maintain 70 to 80% 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@seca.co.uk but in reference to today's event, this has been delivered under our skills and training called Pillar and 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 discussions with Glenn and Ben earlier this year has 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.

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 40 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. And 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 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 behavioral. So we'll look at those and maybe ways in which we can oil the wheels a little bit and getting things back on track. So a lot to understand about the intent of early winners here. And then we have that nice long Q and A session. We really would like you to get involved. So please do use the chat. 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 and 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 managers? So 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 an EC 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.

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 yesterday at Lester 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 review them negatively. And the result was the 53% 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 guys. 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 these 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'd think. And then another quote from NEC contracts where they quote the foresight apply 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 15 of the contract. So order the clauses within section 15. We're going to make sure we fully understand them. There's not too many, but we need to understand them. Transform early warning for from early warring. Must admit, Ben, put that in. I quite like that. And yeah, so early warnings aren't about create 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. 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 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?

It's very simple, Ben. 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, 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. It's not a defined term, so it does have this literal sense and it's few words as possible, very nec, very clear. So, yeah, I think then I probably start having had that literal acknowledgement, 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 the 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 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, 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's hasn't happened yet. It could impact us. There's actually four bullet points underneath that first sentence. Now we've bridged these 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. It's saying to us that, that the. 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 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 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 13. And 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'm not so sure personally.

Yeah, it still tends to be. Contractors would notify majority of the early warnings and to some degree I think we're to expect that because they're the ones that 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 subcontractor relationship. So yeah, you do tend to get more for 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.

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 collaborative comes in. We are trying to mitigate problems before they happen and maximize 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?

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 minimize the impact, okay, 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 is once we've described what the thing is, and normally there'll be on a cloud basis, there'll Be 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. 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 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?

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 had 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 think actually NEC4 recognized 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. 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, 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 provisional sum schedule. You'd certainly need some careful Z clauding to bring that into effect anyway. So 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 kind of 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, 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. I think it's administratively helpful to number the early warnings. Note that I have 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 CMAR 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 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 them to live or avoided or past. 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 prioritize them or 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. So maybe five by five matrix bringing a bit of that risk discipline into, 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, 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 to 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?

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, 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.

Yeah, fair point. I think I'd agree with that. 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 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?

Yeah, I mean, look, 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 would come into it. So we're talking generally about systems not sort of homing in on one. 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 quiet, 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 responded to, which might then mean that we either don't need to discuss it at the meeting or that 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 contractor 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 and meeting at the appropriate time and then driving the actions will be recorded in the register itself.

Yeah, I'll echo that. Glenn might even better shed a little bit light on how, 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 being 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, you know, the authors of the contract, they're not going to take a guess at an average time frame for avoiding a risk. You can't can you price adjustment for inflation might never be avoided or past. 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 program register, 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 action and measured 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 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 conversation Fence, I think they missed the point, maybe stop the Cs 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.

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 it. That's a really good point there. 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 through this slide Glenn to remind me.

I could 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 waste of 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 any C3, 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 any C4, 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 15.3. So cooperate in considering the proposals, look for solutions in terms of who it's going to affect, decide in 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 long as we keep reviewing it, it's doing its job. So there should be no measure or 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?

Yeah, just one thing I was 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 train, 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 morning 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 is it that the Latin ingenium, meaning clever and later ingenuity engineers derived from this. It's about problem solving 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, NEC calls them the 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. And 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 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.

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.

Absolutely. And above all else, I think we've got to break that adversarial connotation. You know, 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. You know, I don't want to see another early warning this month. You know, 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 weaponizing 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 giving you early warning about a risk to their overall cost, you're obligated to give more than just sympathy. 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 behavioral 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. 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 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, 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. And yeah, but you know, when in doubt, there's no harm. And that kind of interval of early warning does allow you to keep that cadence and that rigor. 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. Or 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 politeness perhaps isn't there. But we'll perhaps say a couple of other things about these systems not becoming a Barrier. Right. 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 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 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 log 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?

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 minimize 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, I'll 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 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. And what are your indicators? Well, regular priority 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. Then you can think about how that sort of links to program management compensation discussions. 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.

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. Yeah. And. Well, let's just briefly talk about those. So there is a sanction and sometime 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 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 and E. So that's a really big one. And there's 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 behaviors around early warnings where we just blanket everything rather than think through the individual risks. 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 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 compensation event. But, you know, the contractor's reputation might suffer as a result of the project manager not saying something, which giving early warning or something they knew about. But really the sanction's pretty natural. Right? Because you just forego that opportunity. And I think this is one of the reasons I think clients should be looking at how many early warnings are my project managers notifying? 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 warning done and actually could we have taken some intervening measures on? Because not all of them do, but some of them might. So, yeah, yeah.

I think the obvious sanction on the project manager is that, well, if you don't give an early warning about 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 function against the project manager.

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 event's been. 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 morning meetings and 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 65 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 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 that fixation. There we go. We did mention it. That fixation with clause 615:63:7, 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. 45 clauses later and then a bit more in clause 80. So really. And 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 generally 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?

No, I think you covered that. Very much so.

Okay. So we've got some common problems. Just conscious of time. Wanted to give a good 15, 20 minutes to questions so. So we could 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 52 early warnings on the first day. The first one I remember it might snow was an early warning from a contractor issued on 2 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 who's fault or whose blame. Late or 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 focus 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 coat on a hat stand and then arrive as a project person. And then when you leave the meeting you could put on your contraptus 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 with one project, with one project team and we're going to look at solutions to the problem, that should be the focus very much.

And echoes the boots argument, doesn't it? Get sight 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? And time and time again I've been really surprised, 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, 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 conversation. 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 behavior. 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? Yeah, I think we've got pretty much there now. I'm keen to open this to questions. Looking at the team, we've got lots of questions. 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. So we've got a question on. Ah, look at that. Thank you, Phil. So Phil writes potential key 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 conversation events and you're doing that kind of backwards audit, I guess, is a lesson learned. You know, where could we have got more value by. By leveraging that early warning process? Guys, any comments on that?

Yeah.

That'S good. Yeah, we can just do an. Or do a. Do a review of how many of the compensation events. Was the accusation that you didn't give an early warning but 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. And if managed properly, that could be a good indicator, but a bit like the contractors who 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 right? KPIs have to be useful. So 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 is an idea would be far more valuable. Can we bring another question in.

Whilst we're waiting? I'll just look. Mark Hagerty said one earlier about multiple early warnings for the same event as an issue. Again, the answer to that one is just education. 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 you know, 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. Valid point there, Mark.

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

There was another question flashed up.

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

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? Well, 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 we get is 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 mornings 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 morning meeting. 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 get that without formalizing it. But yeah, the system should have the right portal, the right flow for any communication that you need to raise.

Absolutely. And I know the one, obviously I know well, we did introduce kind of communications, 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 even contract technical queries I would say though, that be really careful who 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 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.

I don't know if everyone's lost Ben, but I've. I've got Ben frozen there. Any other questions? Can you hear me? Yeah, yeah.

Can you hear. Yeah. Okay. Sorry about that. This is our first webinar and we're have. We're having a few challenges and this is one of them. 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, Lynn? Because on 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.

Yeah, absolutely. So there's two there, there's KPIs and also RFI and TQs. And funny enough, you know, that's. That's stuff we've covered, David, isn't it? In our. In our seeker 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 a seeker bulletins on those two subject matters. We didn't even know you gone, Ben. That Was fine.

Where were you?

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 good, nice, simple1. Perhaps KPI for early warnings could be. Has it mitigated the risk or made savings? So a 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.

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. That's a really, a really nice one.

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

I think they're never. The money you have to spend on a project, I guess, is inevitable. And the one thing we can do is optimize 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? Yeah, and I think that's a really good one, actually. And, you know, real opportunity there for contractors to demonstrate the real value they're adding. Okay. We're perhaps calling it late contractor involvement or during project involvement rather than early contractor involvement. But that early warning. Yeah, absolutely.

Sorry.

Really? 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 hadn't catered for that.

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 labor that point. So we have got the seeker 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 Morning. And you don't want that. So we really don't want that they are a separate role. So number 47 is the seeker 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, even 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. 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 picked up.

Okay, last question. I think we've got time for one more.

So George has said, is it realistic to think that early warnings can be part of robust change management system strategy on NEC contracts? 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 event process. And some early warnings will prevent compensation events 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 merged system where they just go into each other.

Absolutely not. But George, you know, they are in a sense maximizing 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, 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 a second one now, but I think we've landed on this. So David, Glen 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 conversation events and things like that. Who should be notifying, 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. So we'll have a look at those too. So the next session, 28 days from today, 6th of October, Monday, same time. We hope you can join us.

Glenn.

David, anything to finish on?

Yeah. From my perspective. Sorry, Glenn, do you want to what I'll do from the seeker perspective? 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 under an 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 I'll thanks. My thanks are to Glenn and to Ben for making this happen. As I say, this is the first flight. We are looking forward.

I just add up. Excellent. Well, that was fun. That's all. I think that was great. So hopefully other people found that fun as well 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, David. Thanks.