NEC4: Managing Effectively - Top Tips

00:00 - Introduction

Glenn Hide: Good afternoon, everyone, and welcome to our next webinar in this series, and we're at number 12 now. So there's 11 more to catch up on if this is your very first one, but welcome back to those of you who've seen some of our others. Today we're just doing a bit of a summary: managing effectively. I think, in all honesty, we were going to do 10 top tips and we couldn't help ourselves, and we've landed up with 14 top tips for you. So some of the biggest issues, or biggest elements, we just think everyone on the project needs to understand. We've just tried to condense this into one single webinar for you. So the 14 biggest single lessons we can give you for managing projects effectively. As always, I'm here with Ben Walker and David Allen. They'll introduce themselves shortly. But Ben, I think we should get going. David, I'll introduce you first. So introduce yourself from CECA, please.

David Allen: Hi there to everyone. I'm David Allen, Executive Director of CECA Southern, which most of you will already know by now is just part of the Civil Engineering Contractors Association, more commonly known as CECA. We represent and promote companies who work day-to-day to deliver, upgrade, and maintain the country's critical infrastructure. And amongst other things, we create a window between our members and those that influence our industry, in particular supporting the need for training and upskilling industry resources. You can find out more about this and what we do on our website, and obviously the address is on the screen.

David Allen: However, my own personal starter for today's top tips is the need to start in the right place, recognising the importance for each party to understand their respective responsibilities and obligations under the contract. The clearer the drafting of the contract document, the easier it will be in achieving its outcome. So I hope that following today's session, it will help to cement other aspects of NEC4 usage and make us more effective as an industry. So, want to hear a bit more? Over to you, Ben.

02:42 - What it means to manage effectively

Ben Walker: Thank you very much, David. And I'll bring up the first slide. Okay. So when I was putting this together, you know, I like to start with etymology, the true sense of words, because I think it's really nice to just connect with them. I found something really interesting out. I did ask Google how to pronounce this. It's four syllables. Maneggiare, or something, right? Anyway, my Italian is not very good, clearly, but to manage comes from the Italian, as you can see on the screen there, and it means to handle a horse. That's where it comes from. It's about handling a horse, with its origins in the Latin manus, meaning hands.

Ben Walker: And to be effective means to bring about, to make something happen. So it literally means, to manage effectively is to bring about a trained horse. So there we go. Who knew? Not write a report about the horse, interestingly. So management of projects isn't about writing reports. It's about keeping your hands on and getting stuff done. So I thought that was an interesting little intro there. And so with that in mind, and I think the late Dr Martin Barnes is my favourite quote on project management, about influencing the future, which is where we started the very first slide in episode one. So with those two things in mind, bit of trivia, and we'll make a start. Glenn.

04:06 - Opening poll: your last 10 submissions

Glenn Hide: Yeah. What we want you to do is just think about, on your projects, your last 10 submissions. And those submissions could be a compensation event quote, it could be a programme, it could be a payment application, could be a design submission. We just want you to think about how many were accepted first time. So just think about that for yourselves. You don't have to write it down or tell us. Just think honestly for yourselves how many were accepted first time, and we'll come back to that after our top tips. We'll reflect on what was your score and what does that mean for you going forward.

Ben Walker: Thank you, Glenn. Yeah, keep that in mind. And yeah, as we always say, this isn't legal advice. Do have a look at the Q&A as well. So if you've got any comments or questions as we go through today, please do use the comments bit, and we'll try and bring as many of those onto the screen later on as well. And yeah, look forward to explaining the next webinar towards the end.

05:11 - Tip 1: Treat the contract as a commercial manual

Ben Walker: So here we are then. Number one of 14. You're right, we could have made it 20, to be honest, but we'll keep it as brief as we can. So number one: treat the contract as a commercial manual. Open it, follow the procedures, and in that sense, this top tip is about having it with you. I've got mine here. I can't get it out, actually. It's propping a lamp up so that you can see me, but... Oh, there you go, Glenn. So just have it with you. It's always... I'm going to get it anyway. Right. Hopefully the light won't fall over. Yeah, mine's here. It is a manual.

Ben Walker: And if we think of it like that, rather than being an instrument of adversarialism or something else, it's really no different to how we approach anything else that is complex, that needs people to align around. And I was thinking about how the captain, the first officer, the crew and the passengers all collaborate in a spirit of mutual trust and cooperation, don't they? They follow the air law regulations and they collaborate towards taking a plane off safely. And the first officer, no matter how many times they've done it before, will pick up the guide, they'll open it, and they will read out the checklists every single time. And it shouldn't hurt our ego. It's not about signalling inexperience. It's about aligning and cooperating around a set of procedures. So that's the first top tip, Glenn.

06:31 - Tip 2: Mirror the NEC's language

Glenn Hide: Number two is making sure we're mirroring the NEC's language and also following clause 13, which is a whole series of clauses around communication flow. So try and use the right language. In the contract, we accept, we don't approve. The contract talks about instruct; we don't request. And we notify rather than inform. This is another example; we probably say it every episode about using a cloud-based system, only because it's so important. And generally the cloud-based system will help with this anyway, because it kind of forces the right language for lots of the elements, but not all. You've got lots of text boxes where you will write your own language.

Glenn Hide: So in those situations, follow them, but the cloud-based systems are trying to make sure they default the text. So the Project Manager, if they are asked to respond to a programme, there'll either be a tick in a box that says "I accept this programme" or "I don't accept this programme". So it doesn't allow the Project Manager to write "this programme is approved" or "not approved". It won't allow that to be done anyway. So again, the use of these cloud-based systems will help with that.

Glenn Hide: Also very important, when anyone's writing Z clauses, if they need to, that again we're following those same rules, that we're using the right language and not reinventing language, and sometimes capitalising new words that aren't actually defined. Because as we've said, capital letters means it's a defined term and it'll be listed in clause 11.2. Anything in italics can be found in the Contract Data. So anything project specific, like the name of the Project Manager or the period for reply, we're going to find those in Contract Data. So mirror NEC's language is our strong tip number two. And again, you'll notice for some of these slides we won't read them out every time, but in episodes 6, 7 and 11 we also emphasised this very important point.

Ben Walker: Yeah. And this is about more than being just pedantic. Clause 14.1 springs to mind, Glenn. I think we covered it in the last episode: when the Project Manager accepts a submission from the Contractor, acceptance does not change the Contractor's responsibility to Provide the Works or liability for their design. So who knows what happens if you approve a design, or you approve a drawing, or you approve a programme, or agree a compensation. But we're not really in that. I think there's only one approval and a couple of agreements. Things like quotations, well, when we're looking at it, we might agree to use rates and prices. I think that's 63.2, isn't it? We might agree to consider...

Glenn Hide: Yeah. And we can only accelerate, can't we, by agreement, if we're both minded to consider it, I think. But where the verb is accept, we've got to be careful, and of course notify as well. 13.7, isn't it? We've got to keep them separate.

Ben Walker: Yeah. So yeah, we've got to keep them separate. And there are a few informs now, I think, in NEC4, to soften that a little bit, so we can, you know, inform extensions and things like that. So we can do them in batches. And the index as well. Top tip, isn't it? If you've only got the paper version with you and you're not searching it digitally, then use the index. Because one of the things that NEC do in order to keep the language simple to follow is that it doesn't cross-reference clauses from other clauses. So a top tip is, if you're in the world of, I don't know, defects or something, then look up defect in the index and it'll tell you all the other parts of the clauses that deal with that. What else should we avoid in terms of defined terms, Glenn? So making our own up, that's probably not a good idea, is it?

Glenn Hide: No. Well...

Ben Walker: Practical completion, that kind of thing.

Glenn Hide: Yeah, practical completion, substantial completion. Yeah, they're sort of common ones. So yeah, I don't want to list them out. It will give people ideas.

10:37 - Tip 3: Put it in writing

Ben Walker: But look them up, right? Things like Subcontractor can mean something different to what you might expect as well. And on a similar theme, our third tip is to put things in writing. And lots of people think this is a point to make about verbal instructions. It's actually broader than that. The contract says all communications required by the contract. So anything that forms part of that formal contractual correspondence needs to be in a form that can be read, copied, and recorded. So it's all verbal communications. If we're talking to each other or asking each other questions, that's absolutely fine. But if the contract requires that communication, it needs to be in writing.

Ben Walker: Now, it definitely does not mean that we can only communicate via a system or via letters. Things get done through that cooperation and those conversations, hopefully as many face to face as possible. It's just that we can't rely on them. And so perhaps the one that Glenn and I have spoken about most is acting on a verbal communication. And to my mind, it was one of the reasons that clause 10.1 was split into two clauses when we moved from NEC3 to NEC4, because people were kind of trading this spirit of mutual trust and cooperation for acting as stated. They're sort of trading one for the other. And actually both things are true. We've got to act as stated and in the spirit of mutual trust and cooperation, and that means, by acting as stated, putting things in writing. Otherwise we run the risk of constructing a defect. So yeah, verbal communications, that's what makes the world go around, but if the contract requires that communication, we need to put it in writing. Anything to add there?

Glenn Hide: Just that clause 13.2 now follows on in NEC4 to say where the Scope specifies the use of the system, it's got to be in that cloud-based system. So if we are using whichever one you're using, whether it's Thinkproject or Digital Bee Hive, the existing system that has been specified for the project, it needs to be in that system. So emails, whilst they might get across something, can't be relied upon until it's actually in that system.

Ben Walker: Yeah. And meeting minutes the same, aren't they? You know, writing your meeting minutes down, and even distributing them through something like the early warning register, it's not enough. We need to actually make the individual communications additionally as well.

13:11 - Tip 4: Review the timescales before work starts

Glenn Hide: Yeah. Number four is review the timescales before the work starts. So make sure we fully understand the timescales involved and the level of effort that will be needed in order to do that, and build them into your programme. So internal governance, resourcing, Ben already mentioned. Whilst we don't generally like timescales being extended through Z clauses, if internal governance means that the Client's got to do that for some reason, at least if they've explained why they've done that, then okay, you can at least understand it a little bit more. So also, yeah, think about the resourcing levels. Understand which elements the period for reply would apply to, and others where timescales are built into the project itself. So the vast majority of processes within the contract have a set timescale built into the contract, but if it doesn't have a set timescale, then it reverts to the period for reply, and then obviously that's in italics. So you need to look at Contract Data to see what your period for reply is. NEC4 now allows different periods for reply for different elements, if that's been stated there in Contract Data Part One.

Glenn Hide: So think about the rhythm of your business. So how often do we think we might need early warning meetings on the project, the payment assessments, how often do you want the revised programme submissions and the forecast Defined Cost, and then show acceptances on the programme. Always a tricky one, particularly for design acceptance. So one thing is to show design acceptance, but is the design likely to go through first time? That's always a tricky one, because you don't really want to set up to fail, but equally, is it really likely that the design will definitely go through first time? You don't want to set up for six wrong submissions, because that just shows, you know... Obviously, you wouldn't do that, but to not have any resubmission could put pressure on the programme.

Glenn Hide: So maybe for certain critical things, one resubmission might be a sensible loop that we price a programme for. Obviously, that would need to be included as part of the tender submission. And we're not going to set up to fail, but we need to be realistic in all of our project management, and in particular within the programme.

Ben Walker: Yeah, it's a really important part of the tender really, isn't it? To look at the rhythm of business that the Client is setting out in their strategy and think about, well, what resources, when in that calendar month, will I have to be able to do these different tasks, whether that's the early warning meeting interval, the programme submissions, the payment applications. And that, together with the main and secondary Options, is going to inform you what skills and how many resources you're likely to need. Good stuff.

15:55 - Tip 5: Blunt correspondence is not adversarial

Ben Walker: Yeah, I guess this is broader than just solving a problem of politeness. This has just amused me, because I had a few real examples where people have banged tables and made noises about the litigious tone of correspondence, only to be very relieved when they realise that, oh, that's just a system. Oh, thank goodness, that's okay then. But it did strike me as being a real problem, especially as we're all trying to embrace this sort of modern contracting spirit of mutual trust and cooperation, working together, to then be so blunt and unambiguous and objective in our correspondence. But the two things can coexist. And again, it was really just another nod to whatever system you use. I think David, at the very beginning there in the intro, said about having the right knowledge.

Ben Walker: And I think you couple that with, when you know what you have to do, you couple that with the right culture, and then the systems can give you a discipline to keep up with it. Because I think quite often we can see, to Glenn's last point, number four, know the timescales, sometimes those timescales can be engineered in a way that makes it very difficult for teams to achieve their own compliance, perhaps within a certain strict time frame. So at tender, setting yourself up to succeed, making sure we've got the right knowledge and the right resources in place that fit the exact strategy. It's no good coming off a main Option A project and going onto an Option D with the same resources. We're going to need a very, very different set of resources. And then having those systems calibrated to those Z clauses to give us that discipline to keep going, but also using those verbs, using the defined terms, and being clear. It's not an adversarial thing.

Glenn Hide: Just going to say, just coming in very quickly, I mean, it is a tool for delivering a function. Provided we're following the rules to use it, then whether you're online or whether you're using it face to face or hard copy, as it were, it's the tool, and the language is already there in the documentation, so...

Ben Walker: Yeah, as long as we do that, then it shouldn't be adversarial.

Glenn Hide: No. And as we've said several times, we're using it to formalise things, right? Hopefully this isn't the first time we've looked at this submission, which is kind of going to be our call to action, I suspect, at the very end of this, when we reflect on how many of them are accepted first time. You know, we might be compliant, but we might not be being effective, right? Because we can be compliant, can't we? We can be compliant and eke out every day of every possible time frame and still have a very poorly run project, albeit we've ticked all the timely compliance boxes, but we're still going around in circles and burning energy. So yeah, absolutely.

18:58 - Tip 6: Agree the conventions before you need them

Glenn Hide: Okay, let me change the slide. Number six: agree the conventions before you need them, not during the event. So wherever possible, just think about the rules. Obviously, the contract says something, but then there might be more than one way of actually being able to do that. In one of our previous webinars, number eight, it was about adjusting the Activity Schedule. So myself and Ben presented two different ways that you could actually adjust the Activity Schedule during the life of the project. So maybe talk it through between the Client and the Contractor and agree which one works better for the parties, because we said both of them were compliant.

Glenn Hide: And to me, one of them was more obvious than the other one, and then vice versa. Both are compliant. So from the project team, think about, okay, not so much when, but when we are going to adjust the Activity Schedule, how are we going to present it? Also, demonstrating the delays for compensation events: think about how you're going to demonstrate that. Clause 62.2 requires alterations to the Accepted Programme to be included in the quote, but then doesn't go into massive detail on how it should be presented. Again, in episode three, as early as that, we shared how you might go about presenting it. But try and agree these things before they actually become an issue. Another one would be your CE quotations. So maybe talk about the format and the layout of the CE quote, how the parties are planning to present that.

Glenn Hide: And I always find that agreeing these things before they're actually an issue is so much easier, because when there is an issue, people have got sight of... they're already thinking about the outcome, and if they agree to that, this is how it's going to go. Whereas if we agree these before they happen, when things are a lot calmer and there's not a concern about the monetary outcome of where this will lead, we agree the approaches by mutual agreement and then look to apply them. So run some dummy scenarios. Say, if this happened, this is how we deal with it. If this happened, this is the way we'll present it. And the more you can agree that up front, then hopefully the smoother it will go on your projects. Ben, do you see that acting out really? Have you seen that acting out well on projects?

Ben Walker: Absolutely. Where I've done it myself, it's been immeasurably better. My mentors always said to me that half the problem is principle and the other half is quantum. So let's get the principle sorted out before we start looking at how much and to what extent things go. And it could be something as simple as aligning on how we're going to deal with, I don't know, a tenth of a day's delay. If we've got lots of little changes on a project, do they all just get lost, or do we have a principle that we're going to manage them in a certain way? How do we approach that? How do we approach calculating the preliminary elements of a delay? Are we going to do that from first principles throughout the whole project, or are we going to look at it periodically and agree a rate or lump sum, as 63.2 allows us to do, and use that? So what can we do to make things easier? How are you expecting to see my submissions in a way that speaks to you and speaks to your audit function?

Ben Walker: And also speaks to our cost capture, and do we need to do anything really radical to satisfy what you're going to want? We can have a look at that before the contract, can't we? Because you presumably know how you want to see these things. And things like the Society of Construction Law Delay and Disruption Protocol, really good sources of useful thinking and methodologies in there, which episode 3 drew on. And like you said, Glenn, you and I can debate which we prefer as an approach to adjusting the Activity Schedule, and we might have our preference, but if we put that under real commercial strain, we might each favour one or the other, and that might be the source of an unnecessary dispute which we could have just ironed out before we started. So I think using the Scope to document some of this where appropriate as well. There's lots of places in the conditions of contract that say "as stated in the Scope".

Yeah, I think that again comes back to having effective early engagement between the parties. If you're doing that, if you know these things are potentially on the horizon, you sit down collaboratively and you just map out the route that you would follow. So it all points back to talking to each other more collaboratively earlier.

23:37 - Tip 7: Boots and shoes: bring everyone together early

Ben Walker: Absolutely. Yeah, this is my favourite one. I think someone said it in one of the training sessions, Glenn, a while back. They didn't say boots and shoes, but they kind of said about having that ratio of engineers to commercial people, and it really made me think, oh yeah, they're absolutely right. I couldn't get AI to draw me even numbers of boots, which was a shame, but at some point you've got to move on. So yeah, this is about bringing everyone together early, and this top tip is about thinking about opportunities as well. Although the clause isn't called early warnings and opportunities, I often think that it could quite easily be mapped to opportunities as well, and giving early warning by notifying it. We really need to be in that opportunity mindset: maximising options and time for intervention. Back to Dr Martin Barnes and his quote, project management is about influencing what hasn't happened. Everything else is admin.

Ben Walker: Do we want to administer the project and write a report on it, or do we want to be hands-on, influencing the future and maximising those options? Which means getting in there early, and it's going to be the most economical time to act as well, as soon as we become aware of something, rather than letting those options narrow. And yeah, I think the point that the delegate was making was that engineers, the word comes from ingenious. It comes from ingenuity, from finding solutions to problems. And so whereas in the past I've approached early warning meetings with almost a bit of a fait accompli, "Oh well, this is the way it's going to be, there's nothing we can do about it, we may as well start thinking about limiting exposure commercially," what you do is stymie this whole world of potential options that open up.

Ben Walker: And I think one of the biggest top tips with engaging this, aside from making sure you have the right people at your early warning meetings, is speaking in the right order. Let the practical thinkers go first and the commercial people can follow. And you can say, "Oh, that's not going to work, that's not feasible." Great, let's discount it as an option, but let's at least hear the options first. Plus, you're building that loop between the office and the site team. Recognising their inputs, they're more attuned to what records they should be keeping then, and how they can be feeding back and exploring options. It starts to highlight programme thinking: what's that box plan doing in the next two or three weeks, and is there an opportunity there to mitigate? So the whole thing starts to come together.

Ben Walker: Where we suppress it sometimes is in the very opening notification. We will say something like, "We notify you of this. Isn't it terrible? If it happens, this, that and the other will happen, and it'll cost you this much," or cost us this much. And we're leaping to that kind of commercial closure rather than opening the conversation.

Ben Walker: So whether it's well intended or not, maybe you're a Contractor and you've got a great idea for solving the risk that's ahead and avoiding it altogether, just be really careful putting that in the notification of the early warning. Personally, I would say your ideas, solutions, proposals, I would bring them to the meeting with you. I would be very careful putting them in that notification, because sometimes that can backfire. The other party reading it, they've not got you in front of them, they're just looking at the letter, and it says, "Oh, if this happens, X, Y and Z," and you think, well, they've leapfrogged the whole process here. We've gone straight to commercials. I was looking forward to having a conversation. So even if it's well intended, I'd be very careful doing that. Try and open a conversation. Anything to add there, Glenn?

Glenn Hide: No, just really understand the early warning process for what it is. It's a potential problem. It's a chance to discuss it and agree actions to move it forward. We've got our NEC people conference coming up in Cardiff, in conjunction with CECA Wales, on Wednesday this week. We've done a survey, and I'm going to share some of the results of the survey. One of the questions was, do people still think the early warning process is a negative process? And I think it was more than 50% who still think this is not a positive process. So it's really understanding it for what it is: that it's a potential issue, and it's a chance to be able to minimise the impact it's going to have without focusing on whose fault it is and how much it will cost.

Ben Walker: Exactly. Exactly.

28:13 - Tip 8: Keep the Contractor's ideas in value engineering format

Glenn Hide: Number eight. If the saving is the Contractor's idea, keep it in the value engineering format. Well, we were gifted in NEC4 our new value engineering clause, called Contractor's proposals. So it's really important that we understand how that process works and what it is. Before NEC4, if we're instructed without a clause 16 proposal, the quotation returns a Defined Cost plus Fee saving and the Contractor's share in the saving would be nil. So basically the Contractor's scratching their head: why would they suggest that under NEC3 when they got nothing out of it? And then they'd stop coming forward with these good ideas, which seemed to really not be a very positive approach for our industry.

Glenn Hide: So if it starts off as a clause 16 proposal under NEC4, the Contractor's come up with an idea, if there was a change suggested by the Contractor through clause 16.1, then the quotation will be offered, and then through Options A and B we've got this new thing called the value engineering percentage, stated in Contract Data, and that will confirm how much the Prices are reduced by.

Glenn Hide: The default is 50/50. It's about the only thing that defaults in Contract Data. If there's no entry, it's 50%. Any other number, a Client can put a different number in there. If it's C or D, then we don't have a value engineering percentage, but that will then just be sorted through the pain/gain mechanism that we have with Options C and D. So it's really important that we understand that clause and therefore keep it in the right format. Do not use design submissions to submit alternatives to Scope, because clause 20.1 would prevail. Again, we've covered this on other workshops, where if you were to change, I don't know, a specification as a Contractor and submit that, and the design's accepted, well, clause 20.1 still says the Contractor's got to Provide the Works in accordance with the Scope. If we haven't captured this properly, then it still wouldn't be valid or right.

Glenn Hide: And then the last point we've got there: a good idea raised at an early warning meeting can land in the early warning register as a dedicated action and simply get done. The benefit to the Contractor then disappears with it. That's not a reason to hold back ideas, but be prompt with clause 16 alongside clause 15. So again, with early warnings, understanding these separate processes, which are distinctly different from each other.

Ben Walker: Yeah, that last point is probably... We said don't necessarily put any solution in the original notification. Open the conversation. There'd be no harm in putting your notification of an early warning in, and then a couple of clause 16 proposals alongside that, maybe, so that you could look at them at the meeting. You're still cooperating in the meeting. You're coming to the meeting with proposals, solutions and actions, aren't you? But if they have got that added bit of being proposed changes to the Scope provided by the Client, then don't forget they could well be value engineering proposals. And yeah, of course in NEC2 and 3 you could do value engineering for Options C and D, but there was no explicit clause at the front.

Ben Walker: You had to kind of know how the mechanics of clause 63 worked, and you had to know to get that implicit proposal in writing. So it was all kind of inferred rather than dealt with explicitly. And of course, if you were on an Option A or B, there was no incentive for sharing your good ideas. You'd just reduce your turnover and your profit. Whereas, as Glenn says, this is very attractive: although you reduce your turnover by a bit, you obviously increase your profit massively using that value engineering percentage. So yeah, one to definitely have a look at. I think that deserves its place as a top tip, Glenn.

Glenn Hide: Yeah. No, I'd definitely say so. Just going back to that alternative to Scope, obviously it's really important that if a Contractor wants to propose a change to the Scope, they should do it separately, before the design goes in, rather than as part of the design submission. Because even if the design's accepted, acceptance doesn't supersede the original Scope. It now creates an ambiguity, and because the Contractor created the ambiguity, the ambiguity clause says it would go against the one who created the ambiguity.

Ben Walker: Yeah. Yeah. I think it's good clarification, Glenn, and on this slide we are kind of dealing with two separate things there. It's just that on occasion I've seen potential for people to try and share a good idea, or should we say share a more convenient idea. If you're on a lump sum contract and something's a little less expensive for you to procure if we vary it slightly, that has to go through clause 14.3. We can't let it come through clause 21.2, can we, design submission acceptance. There's no way the Scope changes without a clause 14.3 instruction. And we already talked about acceptance by another name, didn't we? So acceptance doesn't change that Scope. It doesn't change the responsibility to provide the Scope. So that was the kind of pitfall that we wanted to just temper that with. But yeah, value engineering is very helpful.

Ben Walker: And I guess, just kind of coming back to early warnings a little bit, we're dealing here again with keeping your communications separate and understanding how distinct they are, before we look forward onto some of the other processes.

34:06 - Tip 9: Don't conflate early warnings with compensation events

Ben Walker: Number nine is don't conflate early warnings with compensation events. Actually, to Glenn's point a minute ago, it's one of the reasons that we're probably hovering around the 50%. I don't know what it is, so I'm not stealing your thunder on that, Glenn. But I remember previously half the audience was thinking early warnings aren't necessarily very helpful for us, because they're seen as... not so much that they're seen as adversarial, perhaps, by either somebody in my team or somebody in the other party's team. And that's a shame, because that's absolutely not the intention. And I think some of that perception comes from people conflating the ingenuity with the commercial, prematurely. Rather than letting that play out at an early warning meeting, we're conflating the two.

Ben Walker: And there is a little bit of a trap as well that I've heard some people fall into, so I just wanted to put that on the slide so that it doesn't happen, which is thinking that an early warning stops the clock on the eight-week time bar under clause 61.3. It doesn't. So you might be aware of a risk matter that then may later come to fruition, and the fact that you've notified an early warning on that matter doesn't stop that eight-week clock ticking. And of course we want to check our Z clauses, that that eight weeks isn't four weeks or whatever it might be. I think it's seven under the subcontract, isn't it, Glenn?

Glenn Hide: Yeah. But we need to be careful.

Ben Walker: And have a look at episodes one and two for that. Yeah, anything to add to that? Well, that's a fairly quick one.

Glenn Hide: Yeah, I'd agree. Just the other one is, sometimes people notify the compensation event in the early warning, and think they've notified it within the early warning, and again, they haven't. So the time bar could now kick in, because as far as they're concerned, they've notified the CE, but they've only notified it within an early warning. So it's understanding the difference between those two as distinctly different.

Ben Walker: Yeah. And to share a kind of client's perspective, that conflation of the two processes can be quite wearing, and that's perhaps where we get a little bit of pushback on early warnings, which is a great shame, because it kind of creates this perception of them as being something they're not. But we've both got responsibilities. Both parties have got responsibilities on this. Project Managers, we should be notifying plenty of early warnings, right? There's plenty of things Project Managers can notify their supply chain of as early warnings. This is not just the Contractors. There's plenty of land issues, planning issues, funding issues, stakeholder issues that the Contractor may very much benefit from knowing about.

Ben Walker: And so notifying in both directions breaks that link from the money being about compensation events. Also, Contractors notifying early warnings that are anything but... you know, "Well, I thought I had to do it in order to get a compensation event out." Nonsense. You don't need one before the other. You should have one before the other if you're able to give it, but if you weren't able to give it, and a risk and a compensation event has occurred, there's very little point in notifying an early warning for something that's already happened. I don't think it fits the literal sense, does it? And these sorts of practices can kind of distract from what it's all about. Over to you on that.

37:24 - Tip 10: Update the programme regularly

Glenn Hide: Yeah. Programme, really important. We've done whole episodes on programme, more than one. And just making sure we're updating the programme regularly. Yes, you've got to submit a programme, and if the interval is four weeks or monthly, that doesn't mean a planner should rock up once a month and, within a couple of hours, update the programme and then expect to be able to submit it. If you're using the programme as a management tool, which NEC is trying to encourage... I used to be a planner and a planning manager. I'm updating the programme daily, right? You're only submitting to the Client every four weeks or every month, or if you've got compensation events where you enter them in, but if you're updating the programme pretty much daily, then it won't be a big deal when you have to do that formal submission at the end.

Glenn Hide: If you can do it together, then that's great. I have been on projects where literally there was so much change going on that the two planners were sat with each other, literally updating every day, and the critical path was changing. It's quite rare that you'll have to take that to the extreme, but nevertheless, it can occur. So it's really important that we're putting the time and effort in, and the programme is going to be updated. I'd always say an absolute minimum of weekly, rather than four-weekly or monthly, because if you're a Contractor who's going to use your programme as a true management tool, then it's got to be updated, because things change, right? So you want to be able to share with your project team what has changed, if they are using it as a management tool. They will need it much more frequently, plus it's going to be easier to agree compensation events progressively as well, along the way. So really put in the time and effort it really does take for updating the programme, much more frequently than the actual Contract Data might suggest. That's how often you need to be updating it.

Ben Walker: Absolutely. We could have put episode three in there as well, couldn't we? Because you just reminded me of 63.5. I mean, you were a massive advocate of this happening. It was amended so it was more prescriptive about updating the Accepted Programme current at the dividing date with known progress to the dividing date, and its impact on future works, before you model the effect of the compensation event. And again, if we've got regular programmes, we're making that a lot easier, aren't we? Especially if you're a Contractor and you've had a really good couple of weeks, or a really good week, and you've brought planned Completion back and you kind of want to bank that. In theory, if we're looking at compensation event assessment, we would still be able to demonstrate that and then see the delay, but isn't it an easier starting point to have updated your programme regularly, so that really we're modelling the compensation almost straight on to the current programme, rather than having that sort of double task?

Glenn Hide: Yeah, good stuff.

40:16 - Tip 11: Get the programme accepted

Ben Walker: Oh, my slide must have jumped ahead. And similarly as well, if you are struggling to get your programme accepted, here are some top tips. So if you're struggling to get your programme accepted, well, the first one is not even on the slide. Let's put it in Contract Data part two. If you're a Client procuring works, even if it's Option E, why? Honestly, no one has convinced me yet, in however many years, that there's a downside to getting a programme submitted with a tender. If you can think of one, then let me know and I'll stop being so insistent, but I really think there's no downside. So that's the first one. If you're trying to get it accepted and it's just clunky, then here are a few top tips. Firstly, show the Project Manager the things the Client is responsible for where, if they failed, they'd incur a compensation event. So compensation event number two, number three for the Client not providing something, number five, the Client or Others not working in accordance with the programme.

Ben Walker: So you can see on this, you might not be able to see, but in this little thing here on the image, the green and the purple are the Client and Others. So we're showing that information on the programme, which we've got to do anyway. But the top tip is, alongside that, as part of your submission, maybe have a little schedule that shows how those things specifically have changed since last time. It's a really big top tip. Clients, if you like that, put it in your Scope, because you can say, "And as part of my programme," I think it's the penultimate bullet point in clause 31, "can I also have a schedule showing how the things that the Client and Others are to provide have changed since last time?" It really helps the Project Manager see what's going on.

Ben Walker: Also, Project Managers who are new to this need to be aware that the programme is not a gateway which they're signing off so the Contractor can start. The Contractor is responsible for their programme, and so acceptance of the programme does not change the Contractor's responsibility to Provide the Works in accordance with the Scope. So again, we're not complicit in a failure. We should check it properly, of course, and we're there to add value, but as a Project Manager, if we get it wrong, it's not like we're complicit in a Contractor planning things incorrectly.

Ben Walker: But we do need to know, obviously, as mentioned already, about the Client and Others and their work that the Contractor's expecting. And then finally, as Project Managers, we need to know that finding a technicality to withhold acceptance of the programme in order to buy ourselves another month's worth of breathing space doesn't work. If we withhold acceptance of a programme for a reason in the contract, we automatically assume the role of assessing the compensation events. And that's not a may, it's a must. It's you, the Project Manager, who assesses the compensation events. So yeah, which is not a smaller job than getting the programme right.

Ben Walker: Glenn, you got...

Glenn Hide: No, that's it. It's just, yeah, what is the consequence, or what is the benefit, of not having an Accepted Programme? So, yeah, Project Managers shouldn't be looking for reasons not to accept the programme, but if it's not good enough, then obviously they should not accept it, for one of the valid reasons. But it certainly won't help them to not have an Accepted Programme.

43:36 - Tip 12: Agree the form of the application for payment

Glenn Hide: Number 12. This is a more detailed one from our point number six. So decide the form, the format of the application for payment before you start, especially on your cost reimbursable type contracts, the Option Cs, the Option E. You will be paid based on, obviously, your Defined Cost plus fee. So agree what you want to present, or what's easy for you to present, and what does the Client want to see. I wouldn't recommend you ask clients what they would like to see, because their answer will be, well, everything. So think about, as a Contractor, what evidence you can give easily, the way your accounts are structured, and then suggest: this is what we're planning to submit to you, would this be sufficient? Do you need timesheets? What do you want? Which type of invoices do you need?

Glenn Hide: If you present it in a way that you can give nicely and concisely, yet thoroughly, then it's more likely that it's going to be accepted. And remember, especially with our cost reimbursable contracts, the first Disallowed Cost provision is cost not justified by the Contractor's records and accounts. So if we can't present it, then you won't be paid it. So really important, a bit like we talked about agreeing the format for a CE quotation, really important is to agree the format of the application: what you can give, what is overkill, and mutually agree what is going to be the format that works for both parties.

Ben Walker: Yeah. And then, a bit like we just said, there's nothing stopping us looking at what's happening on site yesterday, today and tomorrow and updating the programme. Why not build the Activity Schedule in the same way? And actually the two things are highly related, aren't they? Especially if we're on Option C, D or E and we've got Disallowed Cost. And the other thing, of course, with Options C, D, E and F is we are forecasting to the next assessment date. So if we're coming up to the end of October, we are applying for everything through into November. So how do we set out those accruals? Well, we look at the programme. We say, well, this is what we've been doing. You know, our best prediction of the future is what we can evidence in the past. So maybe there's certain elements that we can bring forward and show run rates, measured miles, that kind of thing on. So it's really getting into that cadence again, isn't it? It's that rhythm of business, making sure we've got people to do it. Okay. Sorry, Glenn. Was there anything else on that one?

Glenn Hide: No, I think that's, yeah, nice. That's simple. Just, yeah, just agree it before we get too far into the job.

Ben Walker: And if we followed the how to write Scope guide in volume two of the user guides, it's chapter three of volume two, How to prepare an ECC contract. Chapter three in there, how to write Scope. There's a codified structure for how to set out your Scope. And in there, there's about, I think in NEC3 it was 28, I don't know how many there are, maybe 30 places where the conditions of contract actually reference something in the Scope. The definition of Completion is the first one. So if you haven't made those 30 entries in Scope, your contract's going to run rough. It's going to run like it's on three cylinders. So, you know, it's not too late, is it? Because the best time to do it is before you start, but we could go and have a coffee tomorrow morning and audit our Scope for those statements, like the form of the application. And if the form of the application is not in there, maybe now's a good time to sort out what it should look like, so that we can have a smoother run into the future as we get going.

47:00 - Tip 13: Assess compensation events with a double assessment

Ben Walker: Okay. This is quite a big one to attempt in a small amount of time, so I'll keep it brief. There's plenty of information on how to do this, with lots of different worked examples, in episode four. But assessing compensation events: the top tip here, and Glenn's already kind of mentioned it, is this kind of double assessment, and how to set it out. So again, we're thinking about how we're going to present things. Maybe we should take some cues from this. I remember seeing something not so different in Managing Reality as well, the books, the box set there. So this idea of a double assessment.

Ben Walker: So let's just take this quick example. Option A project, 120 million quid. It's that whole industrial estate there; you can see everything you can see in the picture. And the Client's trying to save some money, and they've identified this little storage facility that they think they might delete from the project. It's got an Activity Schedule price of a quarter of a million. And so they want to delete it, and so the revised drawing shows this. And the Contractor, in preparing that quotation for this compensation event, knows that this is going to reduce the prices.

Ben Walker: And so they get the Short Schedule of Cost Components out, because clause 63.1 tells us about the change to the prices. We're going from 250,000 to something else; the quotation shows us how we get there. And 63.1 says that we look at the impact on Defined Cost. So the Contractor's got their Short Schedule of Cost Components out and they're doing their first principles build-up, and they're saying, well, it's going to cost a few quid in people time to administer the compensation event. We've not got any equipment now, so the cost of that is nil. But there is a little bit of drainage we had to restock, because we'd already ordered that, so there's a few quid for that. And we'd just signed a contract with the subcontractor, so we terminate that, so there'd be a few quid there. And it comes out at £10,000, round numbers, £10,000 Defined Cost. Now, it would be a mistake to add the fee to that, 10%, to make that £11,000. We would not put £11,000 in that red circled area. Okay? The reduction to the prices is not 239,000.

Ben Walker: All right? That would be the wrong way to do it, but lots of people still approach it this way. That's not the right way to do it. The right way to do it, 63.1, top tip: do a double estimate, a double assessment. The change to the prices is assessed as the event's effect upon Defined Cost. So we need to know what the Defined Cost would have been had we not had the event. So what would the building have cost us today in Defined Cost if we were going to do it? If we were going to build that building when we planned to build it, what would the cost be in Defined Cost? And we get the same template out, we work through the same rules of the Short Schedule of Cost Components, and we do a first principles estimate of people, equipment, plant, materials, subcontractors and so on, design, manufacture, fabrication and so on, until we get the figure, and it turns out perhaps it's 160 grand.

Ben Walker: So the compensation event impacts the prices. The effect of the event on Defined Cost is assessed as: it was going to be 160,000, now it's going to be 10,000. That is, the event's effect on Defined Cost is a reduction of 150,000, and the resulting fee, 10%. So we come up with a total change to the prices of 165, a reduction of 165. So when we model that on our Activity Schedule, the message here is we've established the impact to Defined Cost of deleting that building from the works, and it turns out it's going to be a saving of 165,000 from the prices. And that's how we'd approach it. So if that's new or unsettling, and you preferred the other way that I mentioned, which was not the right way, then do have a look at webinar number four, because we go into a few other worked examples of that where we can explore it. But hopefully that's enough to whet your appetite on that one, and go and have a look and make sure we understand it fully.

Anything to add on that one?

Look at episode four. Yeah. So, go...

51:34 - Tip 14: Assumptions are stated by the Project Manager

Glenn Hide: I think, last one. Yeah, last one is an important one: assumptions stated only by the Project Manager. So the contract says if the effects of a compensation event are too uncertain to be forecast reasonably, the Project Manager is required to state assumptions for the Contractor to assess against. So that's covered in clause 61.6. The Project Manager's assumptions, if they prove to be incorrect, will be a compensation event under 60.1(17).

Glenn Hide: Unfortunately, currently there is nowhere in the contract that says if the Contractor puts their own assumptions within a CE quotation that, somehow, magically, if the PM accepts the quote, they become PM assumptions. There's nowhere that says that, and there's nowhere that says that you can revisit a Contractor's assumption. So currently the only thing the Contractor can do, therefore, if the Project Manager is not forthcoming in giving assumptions, is suggest the assumptions for the PM to agree, but they'd have to be agreed in writing before the Contractor can rely on them. Otherwise they need to price the risk themselves. Now, there are rumours, and I don't want to spread rumours, but in future editions of the contract there may be some changed wording on this. So watch this space. Let's see what happens next year, but let's deal with what we've currently got, and that is that the Contractor cannot put their own assumptions within a compensation quotation under the ECC contract.

Glenn Hide: Interestingly, the Short Contract allows provisions for it, but not the ECC contract. They'll be forced to just put their risk within the CE quotation. It is an underutilised clause. Would you agree, Ben, that Project Managers are not really forthcoming and then wonder why they get big, expensive quotes from the Contractors?

Ben Walker: Yeah, I would. I think it is underutilised. I think sometimes perhaps Project Managers think it's something that they're being generous to give, which is not the case. It's a requirement to give it. And in my mind, the simple question is: without the assumption, is the risk allowance proportionate to the risk, to what we're doing? Is the risk allowance proportionate to the event? And this is a fantastic post-contract mechanism. We're not trying to eradicate risk; we'd be on a cost reimbursable contract if we were doing that. To a certain extent, we're trying to, with a load of extra admin. So we're not. And I think that's why my view of it is it's right as it is. I think it's human nature, if we're the Contractor putting a quote together, to want to not lose any money, and so we're keen to not take any risks at all. Whereas the contract's saying, well, in order for us to put this to bed and be done with it and move on to the next one, we're going to allow an element of risk allowance, which is exactly the same as in the tender, isn't it? We don't get halfway through a lump sum project and go, "We're running low on money. Can we have some more, please?"

Ben Walker: These are like mini tenders, but instead of commercial competition, we've got a prescribed rule book for pricing, and this allows us that little bit of flexibility where things are too uncertain. So it's not generous. It's necessary where the risk allowance is disproportionate to the thing that we're trying to assess. And I think that is probably the test for me. But, yeah, interesting. I don't know of any planned changes, so you're ahead of me on that one, right?

54:55 - Great records, healthy projects, fewer disputes

Ben Walker: Just very quickly then: great records, healthy projects, fewer disputes. So I think that old mantra, records, records, records, is still very much the case. And if we can build those into working together, acting as stated, then we should find that we get, well, hopefully, acceptance more often. And I just saw a couple of the questions, so Glenn, David, I don't know if you want to sum up whilst I just bring a few of these questions on the...

55:43 - David Allen's summary

David Allen: Yeah. Glenn, should I just jump in on that?

Glenn Hide: Sure.

David Allen: As I say, the message all the way through this: we started off by talking about checklists. We talked about identifying collectively, as a project, what we are expected to see, and all of these things make sense. As I said at the beginning, in my intro, having that engagement even from the off, when you're looking at what sort of contract you are going to deliver, what you're going to put in in terms of Z clauses, it is really important to get that sorted, to work collaboratively and understand what the impacts are of some of the decisions that are going to be made.

David Allen: And ultimately, we just talked, at that last one, about the Project Manager's instructions and their considerations within the contract. You need to put that in there. You wouldn't use AI without having any control or any framework around what you were trying to find out. And if you're looking for the Contractor to give you a price on an item of work, then surely you need to give some sort of parameters as to what you're looking for and what you're expecting. So it all comes back to managing the risk, and making sure that you're only looking for the right party to hold the right risk in terms of what you're asking them to deliver. And I think that comes out around that: if you start in the right place, you're going to come out with the right sort of outcome.

57:09 - Audience Q&A: early signs of a breakdown

Ben Walker: Absolutely, spot on. Yeah. And thank you, Newman, you're absolutely right. So: when disputes arise under NEC4, what are the early signs that collaboration is breaking down, and what interventions are most effective? I actually think it's probably the poll we did. I think if people are resistant to early warnings, that's a sign. And the way I would diagnose it is something that we probably did put in one of the webinars: it's called the Bennett Triangle. Go and have a look at the Bennett Triangle. I would think about: is it cultural? Is it knowledge, to David's point at the very start, or is it discipline? Where's it breaking down? And actually, my experience is most people do have the right behaviours. It's just that they don't have the knowledge to fuel those behaviours in the right directions, or they're so lost in governance, or maybe there's not enough governance, that they're not having the discipline to keep up that rhythm of business. So, I don't know. I think probably the acceptance bit is a really good indicator, isn't it, Glenn? We might be very compliant, but we're not getting anywhere. We're replying on time. It's just rejections all the time rather than acceptances.

Glenn Hide: Yeah. The early signs are: when was the last Accepted Programme? If it's been months since the last Accepted Programme, then something's not right. The number of open compensation quotations and the length of time they're taking to agree: those are very quick measures that, yeah, we're not doing things right. And again, these cloud-based systems can do lots of checks for you. You know, how many times are people not responding within the timescales? We can do these analyses, and doing them early in the project, rather than waiting till there's problems, is another good thing, I think. You know, audits, health checks, we've talked about these, and it's definitely something that we want to be doing effectively, progressively.

Ben Walker: Yeah, and thanks to Sarah there for her point on X15 as well. It's a really interesting one when we're talking about value engineering proposals, because quite often the Client might say, the Project Manager on behalf of the Client might say, "Yeah, actually, that's a nice design, that's a nice suggestion, but we don't really want to take responsibility for it." So we will delete the original part of the Scope and add in a new bit, but that new bit, rather than specifying it fully, simply says the Contractor is to design and provide a solution. At that point you want to be checking you've got X15. I don't know whether I've read your point quickly there, Sarah, I don't know whether that was an additional bit. Yeah, there's lots of conversations going on. I'm trying to find some more questions.

59:48 - Back to the poll: how many were accepted first time?

Glenn Hide: Just whilst you're looking, Ben: the very first poll question we asked you was how many of your submissions have been accepted. So how many out of 10 would you say have been accepted first time? And we just want people to think about that number. If you're up in the eights, nines, nine and a halfs, then you're doing pretty well. I don't know how we can have half a submission, but, half an acceptance. But if you're up in the eights, nines, tens, then obviously that shows you things are going pretty well. If you're at the fours, fives and sixes, well, there's definitely room for improvement, and hopefully some of these tips we've gone through today might just start helping you edge towards getting higher numbers. But remember, it's a team effort. You know, in the best world, if one party's doing things right and the other isn't, then it's not going to work. We want everyone to be understanding the rules and working together for a common goal.

1:00:38 - Episode 13 preview: Scope

Ben Walker: Absolutely. Well, Glenn, David, thank you very much. I hope everyone's found this useful. Thank you for your time. Just before we close the call, just to advertise our next one: we're coming back on the 9th of November, Monday the 9th of November, same time, to look at Scope. We're going to deep dive into Scope. We're going to look at what it is, what it isn't, how to set it out. We're going to look at outcome versus output drafting styles and the implications on risk they have, and some of those 28 to 30 places where the conditions of contract rely on it. So, really, hopefully a practical and useful look at Scope there. So that's me. We've overrun very slightly, so I'll say goodbye there. Glenn, David...

Excellent. Thanks, everyone.

Thank you. Yeah. Cheers. Bye-bye.