NEC4 Option Z: How to Approach Additional Conditions | Gather

Good afternoon everyone and welcome to our 6th webinar in our series. If you're enjoying these, we'll keep producing them for you and we'll pick what we think is relevant topics. And if you've got some topics you want to see, do let us know. So a very warm welcome, number 6 as we said, and today we're going to be talking about Z clauses and how we should approach them and what purpose they're there to serve and how they can be thought about and maybe better used within our, our industry. I'll introduce these guys, going to introduce themselves, but David Allen from Seeker and Ben Walker from Gather, they'll do some introductions along the way. So today's topic, hopefully Hopefully you're going to enjoy this session, and yeah, we're getting into the deep dive of Z clauses and how they should be managed and introduced. David, do you want to introduce yourself from SECA?

Thank you, Glenn. Yeah, I'm back again. I'm David Allen, the Executive Director for SECA Southern, and obviously very keen to engage in this episode or this webinar around the Option Z additional conditions within the NEC4. Obviously, Ben and Glen will be best placed to provide an overview around this topic shortly, but first of all, I'll just remind you about SECA, what we do, and its place in the delivery of the UK mainland infrastructure. SECA Southern, the region that I look after, is just one part of a member-led trade association that represent organizations delivering and maintaining civil engineering across the UK. With 6 English regions, 2 devolved nations including obviously Scotland and Wales, and a policy office in Westminster, we're able to engage on industry issues with government and bodies that impact on our industry at both a national and regional level. And you can find out more about what we do on our website. However, we do deliver training and specifically around the NEC forecast. Contract, where again we look to increase awareness and seek to promote fair and equitable use of this tool. So it may be fitting that we are shining a light on the use of optional Z additional, uh, option Z additional conditions to the NEC in today's webinar. All parties do need to understand their duties and obligations under the contract, and the inclusion of smart and appropriate options and additions will help to support the respective understanding of the parties. However, those additions and amendments that potentially generate ambiguity, particularly given that they are often not— have not been tried and tested, or equally introduced inappropriate risk distribution, undermine the respective parties' understanding and therefore their confidence in being able to manage those risks. With our supply chain governance procedures becoming an ever greater part in determining their ability to engage with infrastructure client groups, those imposing more favorable T&Cs will find it easier to attract the supply chain that they need to deliver their infrastructure and to get the outcomes that they anticipate. Given the government's proposal to invest over £750 billion as part of its 10-year National Infrastructure Strategy, it is important that the NEC is delivered in a clear and equitable manner. That said, please feel free to add any questions in the chat as we go through the webinar, and I'll now hand you over to Ben at Gather.

Thank you, Glen. Thank you, David. Welcome everybody, and I guess we'll start with the why. So why Z clauses exist? So we'll have a good look at that. And the clue's in the name, really. So option Z, additional conditions of contract, which can of course amend things. And also be wary of NEC contracts which have already been amended as well. So something else we'll perhaps discuss. You know I like the etymology of these words, so I went and had a look at where amendments come from. And it comes from amendam, which is a 13th century Middle English term meaning to better, to improve, or to correct. That has some French origins, and even go further back than that. Emendare, Latin, meaning to free from fault. So there we go, perhaps that sets the scene a little. So we'll look at why perhaps we find fault and how to document the fault first. Then we'll look at more general best practice for approaching what some of the NEC colleagues call mischief, and how do we correct that and approach these additional conditions. Then we'll look at and ask ourselves the question, are there 3 types of Z Clause? Intriguing, so we'll think about that. We'll look at some Abrahamson principles around risk allocation and the impacts that might have as well on resourcing and how we really weigh up the context of a project before lifting our pen and starting to draft different changes. Glenn will take us through some style crimes, some copy and paste issues, and the topic of legalese and how that fits or doesn't fit with our approach. We'll sum up with some conclusions and hopefully point you in the direction of some useful resources and look forward to some questions and answers. As with all these, I have to say this webinar is not legal advice. I guess particularly this one, none of them are, but hopefully will spark a bit of debate and conversation, and that hopefully adds to, you know, the useful dialogue on these sorts of things. And I would say as well, in order to protect the innocent or the guilty, whichever way you like to see it, the various clauses that we've dreamt up tonight, we've dreamt them up with the help of AI, so they are not from real contracts, although they might well look familiar. Okay, so that's a quick run through what we're going to cover. We'll jump straight in and look at why Z clauses exist. So before we— in order to do this, we perhaps just need to remind ourselves of NEC's typical modular structure, and we have these core clauses, we have main option clauses for payment, We have dispute resolution options, secondary option X, which is internationally appropriate and covering 29 different options now, which we can pick and choose from to fine-tune our contract experience. Option Y, which are jurisdiction-specific and bring us into that jurisdiction law, if you like, the relevance of it. And finally, secondary option Z, which is all about these additional conditions of contract. And a little bit of trivia, if you're drafting a Z clause, and please be careful if you do, you'd start at Z 2 because Z1 already exists in the contract. So there we go. Now, for those of you who have been on one of my training sessions since 2007, I've always squeezed in this little helpful analogy. I like an analogy. Sometimes the sillier they are, the better and easier we remember the content. So I liken the core clauses to a mobile phone on the basis that if you don't have it, you haven't got it. So you need this. This is the foundation of everything that is NEC. And the starting point for that optional selection of choices. We then have a flexible approach to choosing a payment mechanism, and I liken this a bit to the tariff that you choose based on whether you want the value for money of, of a contract, if you're going to use it, or rather budget certainty that a contract arrangement might give you, versus the value for money of a pay-as-you-go. So really it's horses for courses, and it's down to your context and choice. My analogy doesn't stretch to dispute resolution, so I'm going to jump that and go straight to these option Xs. And the benefit of these are they're created by the manufacturer, aren't they? We go shopping for Samsung or Apple or whatever brand you use accessories, you know that they're going to work. The only surprise would be if they didn't work and you pick and choose them in combination to get your experience working for you. When we come to Z-closures, these give us ultimate flexibility. They allow us to take a screwdriver to our iPhone or our Samsung and perhaps ask somebody to make us a case of our own design, perhaps of a specific color and something ergonomic in our hands. So the point here is that we really, you know, we're off into the woods a little bit. These aren't tried and tested. There will be some degree of trepidation about whether or not they're going to work. And therefore we need to take extra care. And of course, in, in getting those things made or created or changed, we're going to need a bit of discussion and share our ideas and actually maybe state why the case on the shelf isn't a good fit for us. So I think the overall thing with this is there's no right or wrong, just more or less appropriate given the context and appetite for risk and resourcing of parties. So with that, little warm-up, I'll hand over to Glen who is going to take us through the best practice for drafting additional conditions.

Okay, this is probably our most important slides of the night and there's a lot of context here, so we might have some questions on it as we, as we go through. We could pick up on the end. So this is best practice, this is kind of our recommendation, there's some industry recommendation as well. I think as an industry we've got a responsibility to try and police this. Ourselves. It's very hard for NEC, the authors of contracts, to police Z clauses because at the end of the day no client has to go back through NEC and get sign-off from NEC to have permission to change the clause. It's an inevitability that there will be some changes and we're relying on individuals, on industry, to then make sensible changes rather than just changes for the sake of it or change as an individual. Wants to make on their own. Myself and Ben are involved with advising NEC on amended clauses. Ben has in the past and I've done more recently. And we might propose what we think is an absolute nailer— oh yeah, NEC want to change this clause— but it goes through such a remit, doesn't it, Ben, of checks. And what we thought was, oh, that's an obvious clause, then we get— it gets tested and hang on, what about this, and that links to that. It's like, oh crumbs, hadn't thought of that. So NEC, you go through a lot of trial and testing before they will amend any of their clauses, and Z clauses don't go through that same level of scrutiny, and that's where sometimes the problems do come about. So here's some best practice. Think about why. Why do you need an additional clause or a change to the clause? What's the fault? What's the problem? What is the issue in the contract that's not being achieved that you need it to? What's the context of the project? How does this create this additional issue? What is it about the client supply chain appetite for risk or resources or governance that causes the need? So why do we need it? And the answer is sometimes it will be genuinely yes, you may need it. So then we've got to think about, okay, what are the options? So first of all, if you don't need it, don't do it. If we do need it, well, can this be solved in the scope with a constraint? Is this something that can be put into contract data as an entry, an additional CE or period for reply? Do we really need to change the conditions of the contract, and what would the risk and resource implications be on the pre- and post-contract teams? Because adding risk to a contractor would generally increase the tender price and increase the flow of communications that are needed. Flowchart it. So test it yourself. If you're adamant you think a change is needed, then flowchart it. NEC write— have written flowcharts. Now NEC4, they're available electronically. NEC3, they were a book. The flowchart's pretty useful because it takes you through any process within the contract from start to finish as to how it should work. And they mainly wrote the flowcharts, to be honest, originally because they wanted to make sure with authors that they closed all the loops in the contract, that they weren't creating problems that at some point it kind of stops, or hang on, there's no response, and the contract doesn't say what happens next. So if you are convinced you need it, then flowchart it through to a conclusion. Does it fit with existing processes? Because the amount of times that Ben and I see clauses that then contradict something that's already in the contract, and straight away you're creating an ambiguity, and that then causes other problems, and Actually, if a Z clause creates an ambiguity, the ambiguity clause says it goes against the party who created the ambiguity. So there is a danger a clause that's created instantly is nullified because it contradicts something else, and it should be found in favor of the one who didn't create the ambiguity, which would be the contractor's favor. That is, of course, unless they change the ambiguity clause. We'll come to that later. So there might be unintended consequences as a result of this additional Z clause. Function: how would I describe my approach to solving the problem in, in the why statement? So why do we want it? What other parts of the contract should the user be now aware of? Are there corresponding scope or contract data entries that are needed as a result? So by writing a Z clause might mean something else needs to be completed. How does this impact the day-to-day operation, risk, or insurance provisions that may be needed? So what consequences could come about because of this particular clause that's been written. And in terms of draft, what concepts already exist that we can use? So when you're drafting it, use identified terms that already exist. Don't make up your own phrases. Don't write a phrase that's capitalized and pretend it's defined when it isn't. So use the existing phrases we have, identified terms. Use verbs— registers, program. Make sure we're using the right language that we currently have within the contract. Have you followed the general drafting advice in the NEC User Guide Volume 2? So in the User Guide Volume 2, there is guidance in terms of how you should be putting these together. Have you followed the guidance written by the NEC? Have I, at each stage of this process, sense-checked? So get someone else to check it as well internally, you know, try and get someone else to at least check what you've done. You can even chuck it to an EC expert. We're more than happy, we're always very happy to speak to clients who want to run by, "Could you just check this from an EC perspective? Are we doing a good thing here?" There's any number of experts out here who can help you with your draft documents. So we've seen an increase, certainly within GMH Planning, we've had an increased number of clients recently who've given us their proposed Z clauses and said, look, 'Could you just run through this? Give us a sanity check. What do you think? Good, bad, indifferent?' And that's great because they're asking for advice. The trouble is they're the ones who are intuitive and recognizing the problems this could cause. The ones that don't think to ask are the ones that may be causing the bigger problems. Ben, anything to add on that monster slide?

It's a good slide, isn't it? But genuinely, this is like the thinking of many years of you know, looking at these things and trying to head off the problems. And the phrase measure twice, cut once comes to mind. And I think what happens is sometimes we bypass all of those steps and jump straight to drafting. And if you don't double-check the why with ultimately the client initially, and then really, you know, put that out to the supply chain and see how they feel about it, you're creating almost a an unexplained change which can set all sorts of hairs running. We'll look at a few examples of where the perception might be polar, polar different. I think I'd just say, Glenn, on the flowchart bit, if you're going to— if you've got subcontracts, then just be aware that if you're changing the timings to accommodate different guidance— sorry, different governance— if you're changing the timings, for example, then don't forget to be sympathetic down into the subcontracts as well, across to the subcontracts, as my friend Richard Patterson would say. So we want to make sure that it works as a system across the project, not just across the contract. The other thing I would suggest is when drafting this, if you haven't got immediate access to experts to check, if you're unfamiliar with NEC, then something I used to put in every examiner report for IC is use the index. If you haven't got the digital version which you can search guidance on, use the index because NEC is— one of the strengths is each clause is easy to read and digest. NEC doesn't do cross-referencing to other clauses, so that's a good thing, but you do need to take care that you understand the whole of the picture. So if you're in a defect workflow, look up the word defect, check that you've read all of the clauses that mention the word, and then you've got yourself a bigger picture. Check it on the flowchart. So it's just that thing about getting the whole picture. And again, I really think the big lesson from here is— and it would head off so many problems— is just publish your thinking. So initially internally perhaps, so talk to the client, I think we need— this is my why, I think we need a change. Can I test that with you? What is your appetite for certainty versus value for money? You know, check these things. We might find that we don't need to progress down through here, which as Glenn said is in our drafting experience certainly the case, that we find that some things are solvable in other ways. Okay, so I pose this question, are there 3 types of Z-clause? Well, the answer is no. Not officially, but I don't know about you, Glenn, I've always found it helpful to triage them on this basis. So when I look at a Contract Data Part 1 for the first time and at the bottom I go to Z clauses and have a look and see how many there are and hold my breath, I try to calm myself by thinking there are probably 3 buckets here and I only get really scared if the 3rd bucket is big. The 1st bucket I would put them in, I'll call them boilerplate, and these are a little bit outside of, completely outside of my skill set. So I would go and ask a professional to give me a view on the legal and insurance provisions and what's being tweaked and changed. And I'd probably extend that into if there's clauses around termination and, you know, insurance and things like that, the kind of boilerplate stuff that I just want, you know, someone to have a proper look at. And also one observation would be, I sometimes wonder, and again, I'm not a lawyer, so I wouldn't know for sure whether it's even necessary to start re-quoting large rafts of the law, given it's already law, but I don't know. But it doesn't really worry me. I don't lose sleep over it. I just make sure that those are treated in the right way. Then the second bit for me would be constraints, and largely these are unnecessary to put in the contract. I can see an argument if you're a highly regulated industry, maybe nuclear, where certain things just cannot happen and therefore they'll never be able to happen, so we're just going to lock them in hard, and that prevents the project manager from changing the scope. But it does shut down your flexibility, and Glen's going to pick up on that on the next slide. It's the third and final ones that worry me, and you know, the most, and these are the ones that I would look at most carefully, and these are the ones perhaps where we need the biggest explanation of why. Why are we changing the process? It might be to add a new defined term to make some concept work, it might be to allow us to work within the governance that our industry requires us to follow, and maybe there's some some internal governance, and that's all fine. And I think if we're transparent about that and the supply chain understand that and they make allowance for it, maybe we're going to take extra long getting a design submission acceptance back or something like that, then that's fine. I just think we need to, to be clear about the reasons why so that we can plan for it. If we can plan for it and understand it, then we can price it effectively and off we go. But there are also examples which break processes, and these are just ill-thought-out, I'm afraid. There's plenty examples of them where they're just ill-thought-out. They're not fully appreciating how an EC fits together as a proposition and therefore just go around breaking things. And we need to be extremely careful about those, and the way to catch those is to follow the best practice. Glenn, you've got an example of the second. We're going to leapfrog the first because I think they're fairly self-explanatory. Glenn, you've got an example of the second where, you know, do you put it in scope or do you put it in a Z clause? And then we've got a few of these third ones that Claude has created for us to discuss.

Over to you, Glenn.

Okay, so here we've got an example of a constraint: no work shall be carried out between 10 PM and 7 AM. So fairly common requirement that we might have. So in the scope: project manager instructs extended hours for a critical pour, that will be a compensation event for additional cost and the project adapts. As a Z clause, the project manager wants extended hours. Sorry, that's in the conditions. Contract deed of variation needed.

Delay.

Lawyers. Do we proceed at goodwill? So the point we're making here is that you can do changes with Z clauses, or things like this, the constraint. If you just put it within the scope, then there's more flexibility to change it. The project manager can give an instruction that changes the scope but they can't give an instruction that changes a condition of contract. So it's thinking about how we convey this information. So things like working hours, those just need to be constraints within the scope, and then there's much more fluidity there for the project manager to say, as a one-off, we want to be working, we've got permission, yes, you're out of hours, yes, that'll be additional cost. So all of that will now be a compensation event but we can do that nice and quickly. Whereas if you've got a Z clause now somehow constraining hours, you can't do that through an instruction. So try and keep constraints in the scope unless there's a genuine reason to lock them in, and they've got to be in certain environments. I don't know whether you're in a, I don't know, a prison environment or a nuclear. Okay, there might be certain things that you can never do, but most cases We can set them to just be exceptions by the rule, but then we can manage those exceptions through compensation events. Nice and simple.

Absolutely. And just to remind everybody, the definition of scope— I've got out my trusty book, which definitely needs repairing now, it's in bits, I need another one. So definition of scope is information which specifies and describes the works. We all know that intuitively, right? Drawings and specifications. Or states any constraints on how the contractor provides the works. And it's that that we're talking about. And the gut feel is to stick them into Z clauses. But don't forget that definition of scope. It's a really helpful thing. So I think exactly as Glen's just pointed out, if you're working in the prison environment, there's certain things the contractor just cannot do, then that's never going to change. Then absolutely hardwire it into the contract. But As Glenn said, you know, if it's in the scope, we've got a predefined mechanism for unilaterally deciding that we're going to change it, and then a predefined mechanism for valuing and assessing that impact on cost called compensation and process. So it works really well. And yeah, why would you tie your own hands for things like lobby movements or, you know, working times or noise levels or whatever else it might be? Okay, good stuff. Glenn, I think this one is probably up there with ones that don't fit in our minds, at least with NEC approach. I'll just give you guys a second to read that one and we'll, we'll explain what it's saying. So this one effectively makes the contractor liable for client mistakes made pre-contract. So it's saying that the contractor is deemed to have examined all of the scope documents, so all of those documents that specify and describe the works. And satisfied itself as to the completeness, correctness, and sufficiency thereof, and shall have no claim whatsoever arising from any error, omission, ambiguity, inconsistency, or inadequacy contained therein. I stress this is not guidance on how to write these, okay? No one take screenshots of this. This is bad, not good, okay? Or less good, perhaps, is perhaps the more diplomatic way of putting it. And then what you'll see then is you'll see an extra exception added. In 60.1(1). So it will say the following: our conversation events, the project manager gives an instruction changing the scope except changes to correct errors that were always there from the beginning pre-contract that you didn't spot or that you're deemed to have spotted. And you know, a slightly soft version of this might be a materiality clause. So you might say the following: our conversation events, project manager gives an instruction changing the scope unless it's an insignificant or immaterial change And again, we just introduced loads of flexibility, loads of subjectivity into that. It's just a breeding ground for argument. I wonder what the message really being communicated here is if we were to sort of translate that. And it probably reads something like, we aren't that confident in the accuracy and completeness of our scope. We want you to take this risk. We understand the prices and fee percentage may increase to cover this. We prefer cost certainty over the compensation mechanism that deals with errors if and when found. So for me, that's almost the mischief statement. It's almost the, as Peter Higgins would call it, the mischief statement, the thing that's broken, the problem, the thing we're trying to fix. We're saying the contracts approach to identifying errors and correcting them via the compensation mechanism is not for us, and what we prefer is to sell that risk for some budget certainty, albeit it's going to cost us some extra money. And of course, what we hope doesn't happen is people gamble. And, you know, I think the other thing we have to think about is the asymmetry of time and opportunity to information that the parties respectively had when approaching this. You know, you might think that the clients perhaps had months, maybe longer, to put the scope together. Perhaps the contractor's only got a matter of weeks or a month to actually review it. So again, I don't think we're here to say this is right or wrong. We're just pointing out that this one appears to deal with the sale of risk, if you like, in favor of certainty. I wonder if a client was actually made aware fully of this, whether or not they would say, hang on, that's not what we want. We will keep contingency for errors in the scope, and we'll only spend it if we need to. We don't want anyone gambling or pricing risk up front. So again, that's the sort of tension there. Glenn, I don't know about you, I've never seen a clause, a procurement strategy that absolutely guarantees 100% certainty of outcome and 100% value for money. I just, I think this is all about choosing an optimum on that scale with the context.

Balance, isn't it? Yeah, I'm at Parliament today, so I've run a session for Parliament and I'm still in the building now presenting this this webinar. And obviously from Parliament, as a client, it's really important they have cost certainty on projects, absolutely. But we also then talked about, but at what cost? Because they've also got a responsibility to use our taxpayers' money wisely. So there's a balance, as you said, of cost certainty and also value for money. So what cost is it going to be to put all of the risk of contract documents onto the contractor is going to be massive. So Parliament don't only want a guaranteed price, they want best value, and this is not going to bring best value.

Go ahead, David. Just coming in on this, Glen and Ben, this is the sort of clause that really does raise issues within our industry because how do you actually define the risk around that? clause, how all that said clause in terms of the what it's asking you to do as the contractor, as part of the supply chain. You're going to have to realistically consider that, but if you don't have all the details, you weren't responsible for developing the design, doing the investigation and whatever, you don't have time to do that, what sort of additions are you going to have to consider against the risk profile or do you actually look at it and think, well, this is something that we can't really engage with when we're looking at our governance, when we're looking at the potential that might come out of this, then maybe this is not one for us. And then the client isn't just at risk of paying more for having the work delivered, they might, might actually lose the supply chain that they need to deliver that infrastructure in the first place. So that is a big challenge for industry.

This—

I have seen this clause in action, and it is, it's a difficult one to actually manage. And you wouldn't ideally walk into this unless, as a contractor, you'd had the opportunity to steer the investigation, the development of the design from early stage. If you really want the contractor to take all the risk on, then let them have the time to fully develop that, manage the design process, the site investigation risk assessment, etc., etc., and then you'd get a different outcome. But 9 times out of 10, the, the contract setup, the procurement process, will not allow that to happen. So this does cause some challenge within the industry.

100%. So it increases the tender price, it limits the supply chain, it increases distrust between the parties potentially, because now a contractor is worried about you know, the liability and how suspicious they are, because no, no client's gonna, gonna write that if they're confident in their documents. So they are potentially wary that there might be some inaccuracies. And yeah, it's, it's asking for the contractor to price the risk. Now, in theory, nothing wrong with this. A client has the choice to do this, but it's, it's questionable as to whether it gives the best optimum value, cost certainty, and we're trying to balance all of these things, aren't we, as an industry?

Yeah, I don't think our intention tonight is to preach one way or the other or to say something is good or bad. I think probably easier to say it's more or less optimum given the context and the client's appetite for risk. You know, that's really what we're talking about. But also, of course, the supply chain's appetite for risk. If we're putting something out there— I had a good conversation with David earlier this morning— and, you know, we're putting something out there that is is, you know, untenderable, then we're going to get maybe not the full range of bidders and, you know, value that we might otherwise unlock. So I think it's worth just testing the why before we commit to a clause like this and any variant of it, you know, and really scrutinize why we think this is the right approach. And of course, then we see other flavors of this, don't we? Orders of precedence being written in and and all sorts of other things. And okay, fine, so why not, why not say why we think an order of precedent might work better than the contra preferendum basis? I used some Latin there, didn't I? The contracts approach, which is based on this sort of concept which favors the party that didn't create it, create the problem, you know, why aren't— why do we think that's better than the other, you know, and have the conversation, at least to your point, Glenn, about trust that's in the open, we're putting our cards on the table and everyone can understand our reasoning behind it. You know, why gives you energy, doesn't it? It answers so many questions if we know why something's happened.

One of the questions I'd throw in there as well is why don't you actually talk to the supply chain and find out what they would think if you introduced a clause like this? But, you know, get that real-time feedback to better inform any decisions that you then go on to make.

Absolutely. Okay, Glenn, I think you're going to talk us through this one.

Sure. So here is a fairly common— not fairly common— an amendment we see not infrequently. So delete 61.1, amend 61.3. So here, if the Contractor doesn't notify a compensation event within and normally it's 8 weeks, but it's now been reduced down to 4 weeks. The prices and the dates are not changed, and then it normally says, unless the project manager should have notified but didn't. So what this very subtly is now doing is, first of all, reducing the timescale the contractor's got to notify a CE from 8 weeks down to 4 weeks. Now it's interesting, if you go back as far as NEC 2, NEC used to say 2 weeks here, and it was the legal fraternity that said to NEC, 2 weeks is not legally enforceable, it won't stand up in court if it ends up there. So after lots of toing and froing from NEC2 to the publication of NEC3, NEC took the advice of the legal industry to say 8 weeks is enforceable, 2 weeks wasn't. Now in truth, somewhere between 2 and 8 may be enforceable, but NEC erred on the side of caution to say 8 weeks definitely would. So this particular client thinks they knows better and saying 4 weeks is legally enforceable, they might be right, but they'll have to go to court to find out Certainly NEC didn't take that stance and they went safe with 8 weeks. So first of all, we've reduced the timescale by half, so that may or may not be enforceable if it did end up in court. And now all compensation events are responsibility to be notified by the Contractor. So normally the ones the Project Manager should notify, the Contractor's not time-barred on those ones, but they're now notified Sorry, they're now time barred on all the C/Es, the ones the project manager is obliged to notify as well. That's going to add admin problems, cash flow implications for A and B. And also, what if it's a negative compensation event? If the contractor is obliged to notify and it's a saving and the project manager can't notify anymore and the contractor doesn't notify, well then the client doesn't get the saving. So what was trying to solve a problem from a client's perspective has caused another problem and created a lot more admin, a lot more issues that are going to happen, you know, on that project. So again, fully understand how the clauses interact. If you change core processes, you need to explain why and model out those consequences to make sure you're not causing other problems. You solve one alleged problem and create 2 or 3 problems that you didn't know you just created.

Glenn, on this one as well, in addition to the example that you're giving here where the, um, time has been reduced from 8 to 4 weeks, we're actually seeing the opportunity or the time for the project manager to respond is often extended. So you are getting the worst of both circumstances here, which doesn't help And in the long run, if that is something that is embedded in the contract going forward, then you're going to have to build up the resource to actually manage this process. So you're not actually reducing cost from the teams, you're actually increasing the risk profile on the contractor and actually delivering the workload because the risk of actually missing something that is significant, um, grows. And that will have to be considered when they're actually looking at procuring the work as as to whether this is an environment that we actually want to be delivering in.

I think you hit a great point there, David, and it goes back to something we've covered before on previous episodes, which is about the empowerment and authority of the project manager. If clients are appointing project managers and then tying their hands, that's problematic. And I struggle to see why we need more than the 1 week under Clause 61.4 to make that decision, because it is an objective decision. And there's nowhere in that decision where— I understand people need to go to boards for acceptances, but this isn't really an acceptance. It is an acknowledgement that a compensation event has occurred. So it's not like we can say, oh, hang on, I'll check with the board. Oh, I've heard from the board now, 2 weeks, 3 weeks later. Unfortunately, I can't accept this as a compensation event. We can't afford it. You know, that ship sailed. There's either a physical condition or there's a weather event or there's an access issue or there isn't. So really it's a very objective test. Did it happen or not? And, you know, I think we encourage people in our training, Glen, to, you know, try and give that 1-week reply, try and give that the same day if you can, because why would you hold that process up, particularly for a contractor who's operating on Option A or B, where that compensation event implementation, that commercial process to finalize the price change, That's the only way they're going to get paid for that extra bit of work, because it's that change to prices that gets included in the next assessment. And so really, a project manager acting to promote spirit of mutual trust and cooperation is one that is trying to do that rapidly. And again, I think we've said it many times, these timescales are not targets, right? They're maximums. So let's see if we can beat them. Um, yeah, okay. So this is another one, and again, not right or wrong. Incidentally, on that last one, I think I'll just add that, you know, you can see the plausible thinking behind this. We want all CEs notified promptly, so it's, it's, it's not necessarily from a bad place. It's just we need to understand why, because there might be better approaches in order to fit. And sometimes I've seen really big organizations through my work in the contract management system world when they actually presented with the data, those big organizations revisit that governance and say, well, actually, we've now got empirical data that shows that because we've turned the governance up here, it's costing us money here, and they're much better to find an optimum. And it's an interesting piece of work, Glenn. Perhaps we could explore that in the future, how big data helps us make better empowerment decisions of project managers and governance overall. The other thing I used to find was that the more people in a chain of sign-off for something, the quality can sometimes drop because everyone's thinking everyone else is looking at it. So there's a lot of human behavior back in all this stuff. This one's a brief one to explain. The client here wants to delete certain things around the client, around the project manager or the client, you know, getting back with communications on time, withholding exceptions, pieces for reasons not in the contract, not doing things by the date they said they would do. And again, this might come from a kind of genuine place of uncertainty. So let's play that out. We're saying, look, we have a complex project with strict governance and we need more time and flexibility to administer it how we see fit. There may well be occasions where we're not going to be able to provide something for the date shown on the programme for providing it. Okay, so it's a strategy, and without saying it's good or bad, it's a strategy. Again, what we're saying is, is we don't want to constantly have to administer compensation events and constantly be charged, in our mind, more money when these things happen. The reality though is bidders will interpret this as a client and a project manager who are likely to be very difficult to work for. They're going to change their mind without warning or thought for our operations, and we'll need to allow significant disruption in our program and pricing. It might not be worth bidding. A perhaps more optimum approach to this would be to elongate some of those periodical replies, to maybe Z-clause some of those reply periods and other things so that the governance is more sympathetic. The contractor can plan up to that level pre-contract so they can allow for it. You'll pay a bit more money, but okay, it's closer to reality. And then just allow the compensation mechanism to kick in. That will give you that balance of degree of certainty but a degree of value for money where you're only paying for these things if you fail to provide something. Or if you fail to reply on time. And, you know, give early warning as well. Dear Contractor, I notify early warning that I might be late replying to this design submission. My reasons for this, let's chat about it. So I think, you know, we don't have to see this as adversarial, but at the same time, there might be an optimum way of doing it rather than just deleting the clause entirely. Anything to add?

No, spot on. It's always about what cost is this going to come? So at what cost are we— what are we going to achieve? And as you said, contractors are now wary, they're going to allow more program time, that increases cost. So yeah, that's not potentially the best solution to that problem. So keep these in, and occasionally there might be a compensation event, but there's other ways of managing, better ways to deal with this than to delete them. And then elongate the process, which is a big risk for the contractor.

Yeah, if we know our governance is complicated, then price for it or tone it down, you know, and then draw on that contingency as and when you need it. The alternative this appears to do is to try and chuck that contingency at a certainty in advance, which can't be good value for money, can it? But anyway, we could debate.

It goes back to I agree with the argument though about having that collaborative engagement at the right time and the behaviours around the contract and actually addressing issues that arise. So if you've got a contract, you know where some of the complications might arise. If you're actually engaging with that during the procurement process and engaging with the parties that are all taking part in that procurement, at least you are communicating the intent you're providing clarity and people can look at it in a more objective way. Quite.

And talking of behaviours, this next one's an interesting one, Glen. Well, I mean, where do we start on this one?

Let's, uh, should we just leave it at that, shall we? So, uh, delete 10.2, the obligation to act in a spirit of mutual trust and cooperation. I mean, look, on training we talk about 10.1, the obligation to act as stated in the contract, and the very useful addition of 10.2 almost creating, creating like an obligation, a culture as to how we should be, which is to act in this spirit of mutual trust and cooperation. Now whilst I think it is important, 10.1 is even more important to follow the rules of the contract. Whatever you think of this, to actually say you're going to take it out, then what message does that bring? That you're intending not to act in a spirit of mutual trust and cooperation. We've written a SECA bulletin on this, I think it's number 14 from memory, what it does mean to act in the spirit of trust and cooperation and what it doesn't. But certainly don't take it out. It's a nice reminder, and that's it really, but to delete it gives the very wrong message.

Great. Okay, this next slide, and I think it's the last but one, is just looking at risk, resourcing, and context and some Abrahamson principles can help here. So there's 5 things really. A risk should be allocated to a party if they have the most direct control, they can transfer economic risk, they stand to gain the most, placing it there aids planning and operations, or the loss falls there naturally. So you've kind of got this 'stand to gain the most' or 'the loss falls there naturally' is kind of like the first order of who's dealing with it and where it naturally sits. And then you've got control, economic— sorry, control and efficiency, which are kind of related there, I guess, and whether or not it can be insured. So I think that's a useful lens to look through, useful way of dimensioning the matter and whether or not which party should carry it. Now, again, this is, you know, I would suggest some well-thought-out thinking. By Max Abrahamsson. So something that perhaps we might want to have a look at. I think what this translates to then, before drafting a Z clause— so having gone through, or about to go through, that second slide that Glen talked us through right at the start, sort of the process for developing to the point where you've got a Z clause— this is perhaps some of the thinking that we do in the background. So what is the context, size, complexity, sector grounded— ground conditions, and has this thing been done before? What are the client's goals? In particular, a question that seems to keep cropping up with this is what's the client's risk appetite, financial risk appetite? But let's not just assume that means budget certainty. Let's think about that dynamic, that tension between certainty and value for money. What insurances are typical and available? What resources do I have pre-contract to actually Maybe improve the scope if we think it needs a further review, maybe do some more ground investigations. And what resources have I got post-contract who might actually have to— you know, if we ask for 1,000 more things that are crucial to the operation of this new Z clause, then someone's got to check those 1,000 things or fail against doing so. So, you know, what are the implications on our post-contract management resources as well? And then to David's point, he's— I think he said it twice, uh, what's the market telling you? Have we asked? Have we gone out and said, I'm thinking of doing this, what does everyone think? Is everyone still interested? You know, have a two-way conversation, um, and find out what the market thinks, because, you know, this ultimately should be a collaboration. We want to work together towards a common goal. Someone wants to be paid appropriately, so, uh, let's, let's work together on it. And is it fair? 'Would I sign this if the positions were reversed? What might I object to or put a comment against?' And that putting yourself in the other party's shoes, of course, is not just empathy, it's commercially sensible, I would suggest, because it helps you understand the dynamics of it. And I think this final point, Mr. Abrahamsson, we would say a perverse combination in the construction industry of a few words breathed out about risk in time to save loss, but a gale of words when it's too late. And this reminded me very much of the late Dr. Martin Barnes's quote about project management is about influencing what hasn't happened, everything else is admin. And, you know, pre-contract we can influence what hasn't happened by setting it up appropriately, and I think that's perhaps something else to mull on.

Anything else, guys? Yeah, just on that, the last two points, I think they're probably the most important points, uh, in green about before drafting the ZID clause. The bottom one in particular, it says, is this fair? And really, I mean, we're looking for clarity. We— if people have surety of what's being asked for, what the objectives are, then it makes it easier to actually assess the risk. If it is deemed to be unfair, fair, then that doesn't help. That sort of probably develops the wrong behaviours, as it were, around it. But if it was reversed, what allowance would those draft— or about to draft— actually put in there? How long would that piece of string be? And that really would make you think twice about some of the clauses that are being put in.

Absolutely. Okay, Glenn, over to you on a few style crimes.

Yeah, just a few final thoughts really, just to pick up, you know, remember NEC is written in straightforward plain language, it's written in present tense, active voice, fewest words and syllables possible, so they've kept the word count down, no more than 40 words, ideally no more than 20 words. We're trying to make sure that these are readable, they're understandable, so just think about how you're writing. Just looking at the red there, we won't even justify reading that one out, so look at what you're trying to achieve. Generally avoid Latin. I did a year of Latin when I was at school, but I've forgotten all of it. So NEC is trying to be a stimulus to good management. Another key virtue is clarity, so let's make sure that people reading it can understand the written words and we don't add in mutus, mutandis, and inter alia, example, even force majeure. So we need to try and avoid those things, which you'll have to Google and look up, see what it says. Avoid copy and pasting as well, so don't just copy and paste stuff from one into another because inherently that causes problems. You bring in something that was relevant to another project that's not relevant in this one. So it is a kind of false economy. If you are going to do it, then obviously just check what you've brought in and then rewrite it, but don't just copy and paste because we see this so often that some elements are brought in that are just— they even refer to another project altogether or something like that, which is clearly complete nonsense and again creating ambiguities by trying to allegedly save yourself time.

It's a real dangerous time to be lazy, that, isn't it? Effectively, you're leapfrogging all of this by copying and pasting. You're leapfrogging everything there, and, you know, it's just very dangerous practice.

Yeah, another sort of point really relating to the copy and paste and also to the words that you sort of spoke about at the beginning when you were defining what, uh, sort of the amendment actually meant, you broke that down. We have had instances of contracts being let under a framework where the conditions have had to be amended in the end for the particular supply chain to be engaged because the T's and C's didn't quite actually match up, and then a repeat contract would then go out for for procurement, and there was no learning. The, the Ts and Cs that were removed and understood and accepted needed to be removed were all put back in, and it's that learning doesn't necessarily happen, and that doesn't help the process. That's just taking up a lot of time and energy in rerunning the arguments, rerunning the process, just to get to the same outcome.

So that's very true, and I think, Glenn, you made the point about Stimulus to Good Management, and you know, this is a guide for practitioners to follow to get commercial success on their projects. So it absolutely is jarring, isn't it, when you are in what was a 10-word sentence— the contractor provides works in accordance with the scope— to suddenly have 200 words injected in the middle of it. So I think absolutely, okay, um, I think that brings us to, uh, I don't know if Will is still with us, sort of harvesting the questions and comments in the background. We should have said, well, sorry, we didn't say please, please do engage through the comments and chat facility if you have any questions. We'll come to those in a moment. We'll sum up then by saying that Z clauses are there to provide the ultimate pre-contract flexibility. So Option Z, additional conditions of contract, the ultimate pre-contract flexibility. We hope though that NEC4's sort of parameterisation of the different clauses through the contract data, its modular approach with core, main, and secondary options, covers most needs. We hope that people will adopt the drafter's methodology of why, flowchart, function, design, and finally drafting, and share that Publish that why, open it up and explain it, get the engagement of the market, reduce their perception of risk and the money that we spend running around trying to understand things. Check the risk allocation and resourcing implications make sense for the context. That's that Abrahamson's principles bit. Copy and paste is dangerous. Set an optimum strategy for every project. It doesn't take long, a procurement team, once they've learned how an EC fits together, together. The whole point is we can tailor each project or contract as it comes along. Style matters. If it doesn't sound like NEC, then ask yourself, you know, are the people going to be able to use these amendments easily? Does it make sense? Is it coherent? Is it intuitive? Transparency builds trust. I think we've seen that a lot through what we've talked about so far. So check your intentions, if you're helping a client draft this, check those with the client and the supply chain to kind of gauge reaction and reduce the uncertainty. And because you'll get a better price, it's short-sighted not to, right? Then let's, let's get the best, uh, the best price and the closest engagement we can. So that brings us to the end. Um, questions and answers, uh, plus this, uh, little reminder there of the read and follow the general drafting advice there on page 49 of, of the user guide. And this one is Volume 2, Preparing an Engineering and Construction Contract. There's one for each of the forms in the family. Just to advertise, I think we're going to put the link for the next one, Episode 7, which will be Understanding the Role of Contract Data. So if you found today's webinar useful, join us on Monday the 2nd of March for for the next one in the series, which will be a good look through contract data and understand how to approach that. But I think that leaves us, guys, to take some questions.

Yeah, I can see, well, we've got some comments. Yeah, there we go. There's one from our very good friend Richard Patterson. He's still on the phone on his photo. So Richard said, and rightly so, if a contractor misses the time bar on a 100 £100,000 change in the scope that is now not required to be notified by the project manager, will the contractor really get that for free? So where they've deleted the requirement for a project manager to notify any compensation events, and now the contractor's obliged to notify, that Z Clause suggested that if they don't notify within 4 weeks, they're time barred and they can't now claim the compensation event. Really? Is there any world the client really thinks that they can get that for free because the contractor was a day late in not notifying a compensation event they'd normally be obliged to notify? Now, there's an argument to say there's a set clause that's changed that. If that went to court, I cannot imagine any lawyer, any judge, who will agree that the contractor is time barred. So I'd certainly say that would fall in the category we're not lawyers. Of an unfair clause, and that would not be enforceable in a court, I would imagine. I cannot see any world where that would— they get that for free. But so again, it doesn't work.

Who knows, right? That's the problem, isn't it? So we're— I mean, by the black and white of what's written, it looks like the intention is they wouldn't. But we're talking here, the context to Richard's question is if we had that, that said clause we flashed up earlier, I think I think it's the second one, wasn't it? I mean, this is a bit like when people say to me, oh, I've been approving or agreeing design submissions. I've not been accepting them, I've been approving them. Have I accidentally taken some liability? I mean, the answer is I don't know. I know what the clause says. It says accept them. It says acceptance doesn't change your responsibility to provide the works or liability for design. If you start approving them, I think all of us have to serve in harmony, say we don't know. A lawyer won't know, only a judge will tell you. So I think similar with these clauses, we start departing from what is understood, there's the risk, isn't it? And I know, Richard, you'll have your own view on this, so thanks for the question.

Um, can I just add a bit in the chat what you think? Yeah, can I just add a bit on that? I mean, I think Richard's sort of question in the round probably also alludes to behaviors that might that then ensue around that. And I think if you're looking to work in a collaborative manner in a way that's going to deliver the best outcomes, then you need to be sensible with the clauses that you actually embed, because missing out on that for one day will create significant ripples within the overall scheme of things, and as I say, it does impact on behaviours.

So, but let's write what we mean, right? And then act as we've— act as we've agreed. Yeah.

And this comment picks up the same. So again, uh, Camigello is talking about adverse adversarial tone from the start, um, and then it does beg the belief about, well, why choose NEC in the first place? If, if you're going to write Z clauses that undermine some of the key principles of NEC, then yeah, why, why choose it in the first place? So That is a very inherent problem, and yeah, I agree, it is demoralising. NEC was brought up to improve things, to save money to the industry, to create better relationships, to create transparency, and sometimes their clauses can undermine the very principle that NEC was brought in to do in the first place.

I just wonder whether though, Kamakura, you think that perhaps there's some of these clauses that the perception is that, but actually they come from a perfectly good place and they've just not explained the why. And once you find out, oh, it's to do with governance and it's complicated and you have an opportunity, perhaps even better to influence that, then that might soften it a little bit. So, or they might not have even got that far because someone else would have told them that it was a bad idea for X, Y, or Z. So I think that's true for some of the time, but there'll be plenty of clients writing things that they're not intending to depart from the NEC spirit, they're just, they're just doing so potentially in an uninformed way. And whatever the reason, we probably can agree that we need to get it right.

And that's why it is absolutely important that there is clarity around the clauses, there's an explanation to explain why we're going down this route so that everybody knows, and then you have the opportunity to manage that circumstance.

Okay, I think we've got time for one more question because I'm keen that we finish one webinar once on time, so maybe it's today. So from Sean: with the above, how would you reflect that in a program?

I think again it's more of a question, is it? And when he says with the above, yeah, everything we've gone through today. So yeah, all of those extra risks that you're putting on, if we're putting more risk on the contractor for ambiguities and documents and things like that, all of that is going to have to be reflected in the programme. So as well as price, it's also going to reflect in the programme. And obviously time is money, because if it's going to take longer on the programme, that increases prelims as well. So yeah, with difficulty, but again, it will be reflecting risk.

And that— absolutely.

So yeah, absolutely. And of course, the scope, you know, we can explain that risk again in some of the scope and that can come out through some of the information, some of the scope templates explain our governance and things like that, and the management processes. That might be very helpful to communicate and have a conversation on pre-contract so that we can get the expectations aligned. I know, David, final word.

No, I think we've covered a lot of detail here, and I think it is about behaviors, it's about what outcomes we're really trying to achieve as a collective, and If there was greater clarity as to why we're having to put these clauses in, all these options in, then at least that would be the starting point. But it's really how they impact on the risk profile of the project that needs to be considered, because at some point you won't have anyone lining up to actually engage.

And let's, let's let Jennifer have the last word. She said it, not us. So some of these amendments seem to be intended to protect clients from their own delinquent project managers. Jennifer, what a wild, crazy statement that is. Yes, we'll leave you with that thought. We couldn't possibly comment, Jennifer, on that at all. Gentlemen, time's beaten us, so thanks everyone for joining us online. Thank you, David. Thank you, Ben. Always great to have these discussions and hopefully food for thought. That's why we're doing them. We're trying to help everyone think about how we can improve our industry, and these webinars just go a small way of trying to do that. So thank you for joining. This will be online shortly, so if you missed or want to replay anything, or you want to recommend this to some of your fellow colleagues, obviously the recording will be made available tomorrow and you'll be able to watch it again. So the next session, as Ben's already said, 2nd of March, we'll be talking all things contract data. So thanks again, and we'll see you in 4 weeks' time.

Cheerio.

Thank you.

Thanks, everyone.