NEC4 Clause 13 Explained: Communicating Correctly | Gather Webinar

Good afternoon, everyone.

Welcome to our next webinar. This is episode number 11. Sorry, we've had a little break for the summer. We've had a little bit of time off, but we're back ready and raring to discuss all things NEC in our monthly webinar. So number 11, and today we're going to be discussing communication. So Section 13 of the contract, we're going to look at the rules around communication flow. and give you a few tips and look at what's right, what's not right in terms of communicating, and also talk about these cloud-based systems that can help us do that. So I'm Glen Hynd and Ben Walker here from shortly, and David, would you like to do a bit of an introduction?

Hi there, yeah, thanks Glen. Yeah, I'm David Allen, as it says, the Executive Director for SECA Southern, which is just one part of SECA. The Civil Engineering Contractors Association, which is now in its 30th year and is a not-for-profit trade body that represents contractors that deliver, upgrade, and maintain a significant part of the mainland, mainland UK's infrastructure. Our CICA members deliver, deliver an estimated £30 billion of work per annum to the UK economy and directly employ more than 250,000 people, with many more jobs represented across our members' extensive supply chains. As I said, SECA Southern is just one part of this member-led association, which collectively delivers coverage across England and the devolved nations of Scotland and Wales, and through its policy office in Westminster. We engage with the governments and bodies that impact on our industry at both a national and regional level, delivering activity aligned to our member-led strategic core pillars, and you can find out more about that and our other activities on our CeCA website. This series of NEC webinars, NEC4 webinars, is aligned to our CeCA upskilling and training core pillar ambitions, and it's designed to provide an additional layer of awareness beyond the seminars and the bulletins that we already deliver around the NEC4, looking to increase the wider NEC for user awareness and the informed use of it to deliver more assured outcomes for all. Some of the CECA member feedback received in preparing for this webinar suggests that the NEC Clause 13 is often just viewed as an administrative clause, whereas in reality it underpins the operations of the entire contract. Many of the issues and disputes in our industry have not necessarily arisen because the parties disagreed on the technical position, but because communication procedures were not followed correctly. We'll obviously look at today's topic in more detail as Ben and Glen present to us, and there'll be an opportunity to ask questions during the discussion at the end. So I'll now hand over to Ben from Gather. Thank you.

Thank you, David. Good afternoon all. Hope you had a great summer. And those last couple of points David made around member feedback, they're captured in a slide in our final thoughts end as well for reference, because of course all of these webinars are available to rewatch through the various channels. I think we're live on YouTube and a couple of others. And so yeah, you can certainly go back and get them. If you access them through LinkedIn, you get the added advantage of being able to look at all the Q&A as well. And so we're hoping for some questions as we go today. Please do drop your questions in the chat there and we'll make sure we've got a bit of time towards the end to take as many of those as we can. I'd remind you that this is not legal advice, but we're hopefully exploring some practical hints and tips of how to apply this theory in practice. And do, of course, also take note of your Z clauses, because what we're going to be looking at today, as always, is an unamended standard NEC contract. Communicating correctly, our 11th topic. Having had a bit of a break, we're going to look through 8 little sub-clauses. They take up less than a page in the book, but as David said, we shouldn't see them as just administrative and pass over them. They're actually quite important to get to grips with. As always, another bit of etymology. So communication comes from the Latin communicare, and that means to share, to impart, or to make something common between people. And it's a sort of interesting bit of trivia, it's sort of— it's the reason why it has effect when it's received rather than when we press or put it in the letterbox. So we We're going to look at those. We're going to look at the form of these communications, the language that we use, and also when it has effect. We'll then look at some of the timings and the rules around timings and where to find out how long we have to do certain things and how we extend some of those periods as well. Very sensible if we've got a very complicated quotation to put together, ask for a bit more time. You know, we want to do it properly. Acceptance or reasons for withholding. It's a huge obligation on the project manager there to consider and accept various submissions and give really good reasons for why they might be withheld. We're going to look at notifications and certificates, and then we'll wrap up with final thoughts, and we'll jump into those useful resources and Q&A. Right, so I'll hand over to Glen for the first slide.

Well then, you said it's less than a page, and it is only 8 sub-clauses in Clause 13. So quite a small section, but some really simple yet pretty fundamentally important clauses to understand and get your head around within the contract. So important to prepare systems and governance to meet the format and timings required. Yeah, governance. So we talked about this at our London conference and how sometimes clients—

Sorry, can you say that one more time?

David, can I mute you? I was getting feedback there. Oh, that's better. So yeah, governance can actually prevent the actual timescales from the contract in working, which is pretty fundamentally wrong really, isn't it? Because a client's setting the rules or they're choosing the contract and the rules they want, yet their own internal governance prevents them from achieving that. So that may be a topic of another webinar. in the future. And as we've already said, it's more than just administration. There's some very important conditions that sort of govern acceptance and what it means if withholding acceptance, and it also is written in very specific language, and it's important we emulate that language throughout our responses in our own communications as well. So with that, we need to think about defined terms, identified terms, so don't make up your own. Let's continue to use the defined terms the NEC's got. Identify terms, those things like italics, and also verbs. We'll talk a bit of a grammar lesson partly as well today. And do check the scope for specific formats and requirements. So there may be elements in the scope that dictates exactly what format things have to take. So for example, the forecast of defined cost may have a little sort of a spreadsheet or a presentation to say how they want that presented each application. Design submissions could detail exactly what needs to be, how it needs to be put forward. Same for test inspections, programmes, and payment applications. And potentially, if it doesn't meet the requirements of the scope, then if this is something that's been issued for acceptance, for example, then it could be a reason for that submission not being accepted. Anything to add, Ben?

Yeah, that's a good point, Glen, isn't it? How we don't always fully understand what scope is. We assume it's drawings and specifications, which of course it is. We may also know that it's constraints, which should cull quite a few Z clauses if we're using that appropriately. But what a lot of people might not know is it's also a collection of around 30 different statements that the conditions of contract rely upon. And the most obvious of those right at the front is the definition of completion, which points at scope. And in that list, you've mentioned a few others there. So really important that whether we're preparing scope or preparing tenders against the scope, that we go and make sure those statements have been made, because they're designed to give us that head start, no less in communication, and making sure that we're effective in that communication from the beginning. So yeah, go and have a look at those scopes. Depending on your main and secondary option choices, will be around 30 different entries that you're expected to write in the scope to make those clauses work properly. Jumping into number 1, a simple clause. It says each communication in a form that can be read, copied, and recorded. This relates to all communications required by the contract. We've got a little bit more flexibility when it comes to things that we're discussing that aren't contractually required. But the really important thing I quite often hear is no verbal instructions. Well, actually, it's broader than that. It's no verbal communications of any kind which the contract requires. So just an important point there. And look, I think again with these systems, the need for verbal communications is diminished. And also I hear a lot of people arguing, well, 10.2 says we should act in the spirit of mutual trust and cooperation. Why aren't you trusting me when I give you a verbal communication? Well, You can't sacrifice 10.1, which is do what the contract says. So let's not confuse those 2. And I'll go so far as to say, let's just get that feeling that it's almost antisocial to be giving verbal instructions and any kind of verbal communication, because particularly with an instruction, you're putting the Contractor in a position where they're effectively, if they act on what you're saying, they're technically building a defect. So we'll maybe have a look at that again later. So quite often another question we get asked is, does WhatsApp comply? You know, if I send a text message? Well, it's in a form that can be read, copied, and recorded. It's perhaps not the most practicable way to record and copy, but I think it— as we learn the rest of these 8 rules, because they are taken together as a collection, we might find that there are other things it might not satisfy, such as, has it been identified as the address notified by the parties for receiving communications? So It's, I guess, strictly possible as long as things are in place, but it's unlikely to be optimal. So, yeah. And, you know, even if we don't have communication systems, because we didn't used to have them, carbon triplicate pads, you know, there's an easy way of— I mean, I wouldn't advocate them anymore, but it used to be a way that we would avoid having to give verbal communications. We're not saying for a second shut down dialogue. We'll see that in a moment. So lots of conversation is still making the world go round. And writing, a very small point on this clause, but writing is in the language of the contract. That's an italicised term, it's an identified term, and that's something we'll need to look up in Contract Data Part 1, where it will tell us the language of the contract. Okay, Glen?

I think the worst one I heard on that, Ben, was one project, they were communicating via Snapchat. Now, if anyone knows anything about Snapchat, the whole irony of it is it self-destructs once you've read it, so it's about the worst.

Messages disappear in 24 hours, they disappear, is that the one?

Yeah, as soon as you read it, yeah.

Not very good for record keeping, is it?

No, I'm sure Gather would have a thing to say about that. So 13.1 is really clear, and in particular no verbal. Ben already mentioned, what about WhatsApp, might that comply? it is in a form that can be read, copied, and recorded, but it won't then comply with Clause 13.2. And this is specific into NEC 4, these words. So it says a communication has effect if a communication system is specified in the scope when it's communicated through that communication system. So where we've got the likes of Think Project or the Digital Beehive, where we've got systems like this that have been specified, it has to be in that system, and that's really important. We'll always talk about cloud-based systems, and it's for you to do your own homework, which is the best one for you, but the cloud-based systems are trying to make sure we comply with the rules and timescales and, and suchlike, and you want one version of the truth. So it'd be little point in having some communications on a cloud-based system we've agreed to use, and then other communications on WhatsApp or email, and then not— unless you've been copied in on that, you won't see that communication. So it's imperative that where we have been educated enough to want to use a cloud-based system, and to be honest, every project should be doing it because they're relatively inexpensive to the massive benefit they're going to bring. So once you specify the system, everyone needs to be using that same portal so we're all clear on the communications. If a communication is not specified in the scope, well, it's received at the last address notified, otherwise the address in contract data, which could be electronic addresses, and then we're into the worlds of email and suchlike. But what we've always said, in this day and age, we should be using a cloud-based system. But if it's really small, or for some reason we're not using a cloud-based system, then what you really want is, rather than just emailing and writing in the body of an email elements, you want to have a set of pro formas that in effect do the equivalent of the cloud-based system. And then you're emailing attachments, and those attachments, you'll have an instruction form, notification of early warning form. So if we really need to go down that road, then that's really what we, we're advising that we're doing. sort of pro formas rather than just bodies of email. And contract management systems, CMS, they often do more than the act of purely just communicating. It's also important to point out that it is specified in the scope, so it's not in contract data, it's specified in the scope. So if the project manager needs to, they can change it, whereas if it was in contract data, they can't unilaterally just change things In contract data.

Absolutely, and I think that's probably the answer to this question, isn't it, Glen? One of the nice things about it being in the scope is if it fails you, it's not quite for you, you want to swap it out or have an interim arrangement because something's not quite got in place in time, as per this very good question, then you can react quite quickly. It will be a conversation, but you can react quickly and make sure that those arrangements keep pace with whatever the reality of those communication systems are. So thanks for the question. I think that's probably the answer to it, is because it's in scope, you can change the scope, which would have immediate effect. So you could quite quickly put something in place, or if you were to remove it temporarily, I think you'd make the point that it was as per contract data perhaps, but, or make, you know, make some other arrangement. But it is within the project manager's gift to swap things around. Again, it's another reason it's not in contract data. Would you agree with that, Glen? I think that's the answer to that question.

Yeah, totally. It's a great point from Sian. It's something I hear a lot, that project teams just don't have it set up at the beginning. And it's crazy because, you know, Ben, these systems shouldn't take long to set up at all.

No, you should do it over the weekend. I could get one live by Monday morning.

So yeah, so the amount of times I hear projects, they're weeks— oh yeah, weeks in, or oh yeah, I haven't got a license yet. Project teams need to understand that and cut through that and make sure everyone has access from day one. They're not difficult to set up. There's no excuse for not having it set up at the start of the project.

And if you are convinced that one's not for you for whatever reason, then the place to find a set of those performance notes would be Volume 4, How to Manage an ECC Contract, of the guidance notes. There was some performance notes at the back, I think, in the appendix. And if you want a guide on how to write scope, which is my popular piece Most popular piece of guidance, I think, is Volume 2, How to Prepare a Contract. It's in Chapter 3. So if you're listening back to this, there's some useful reference. Okay, let's turn our attention then to when the communication has effect. So we know whether or not we're going to use a communication system set out in the scope. And a couple of other really important things, we've got to make sure that who's Who we're writing to and who we're writing from is correct. A couple of top tips. So check your conditions of contract, check the contract data. Project Manager is written in italics, Supervisor is written in italics, Contractor is written in italics because we're supposed to find out who they are in contract data. They're not defined terms, they're identified. They have a data value. Ensure the communications are being sent to the correct individual and don't assume just because it's to do with defects, it's got to be to and from the Supervisor. That duty switches to the Project Manager for accepting defects. So, you know, just double-check things are configured as you expect them. Check for delegated actions. Again, another beautiful thing with these communication systems is a lot of them will embody that delegated authority and allow you to print that out as a report. So it makes that convenient. And there we go. And then make sure when we're writing these communications, ask yourself, am I the right person to be doing this? And try not to sign off with your job title or your job description because they're quite often different from your capacity under the contract, which just saves people being confused. So small points, but perhaps worth making. Okay. Remember as well to check your ZEG clauses. We said that already, but there may be some ZEG clauses that move those express duties around and give them to other people. What's next, Dan?

And again, the cloud-based systems by default, only people who have authority to write certain communications will be able to send it in the system. But manual systems, obviously, it wouldn't have that same control. So even if you're not using the cloud-based system, make sure that you're not trying to give authority that you don't have. So only the project manager or the delegate can give an instruction to change the scope. So contractors need to be very careful, as Ben said, to know who that person is and make sure they're taking instructions from an authorized— the authorized person under the contract.

Just to cross the T's and dot the I's on that, Glen, we should nonetheless on day 1, once those delegated authorities are reflected in the system, we should produce some kind of report of that. And it would be— it was one of the communication types under general communications that we created under Clause 14.2 that you could then notify that. So you should be notifying under your delegations at the start of the contract for them to really bring them into effect. So make sure that you've You've given that notice effectively as you turn it on, and then if you change it, you should reissue that. And it's a hygiene check, I guess. Yeah, yeah, absolutely.

Great advice. Users are not required to quote clause numbers. It is common practice and it is helpful, and even you could say courteous, but it leaves the other party in no ambiguity as to the condition that you are following. The cloud-based systems will tend to do that for you. So without you knowing or asking, a lot of the forms have a dropdown and you look through for the reason that you're communicating and click on the one, and naturally that system will then pick in, pull in the clause number. So it does help because it kind of reinforces why you're saying something. It's, for example, if you were to notify a compensation event but didn't quote under which clause you're notifying it, If the client's project manager didn't think it was one and you've not explained why you think it is one, they might say no. Whereas at least if you pointed to the reason within 60.1, or some of them are dotted elsewhere in the contract, you're making it clear under which clause you are notifying this. And it speeds up the decision, the process, that the project manager can then go to that clause and see, do I agree with that, rather than a bit of a needle in the haystack. Well, where in the contract Does it say that? You know, one of the other positive things, I think we cover it in a while, is the project manager needing to explain the reasons why they're not accepting something, whereas previously they could have been a bit more vague. But we'll pick up on that again shortly. We do have defined and identified terms, so don't invent new ones post-contract. So make sure we're using the established defined terms. Obviously, Z clauses can have extra defined terms, and that probably does warrant, depending which sector of the industry you're working under, that is probably an area where I would be expecting some Z clauses where we have a few extra defined terms that are sort of sector-specific or environment-specific. So define them well and use similar language to NEC and make sure we're using the Contract Data Entries. values in there as well. There is no requirement to keep registers or number events in MATTR, but again, very sensible and typical to do so. The cloud-based systems will kind of do that for you. They'll generate unique numbering so we can then refer to what we're talking about. So early warnings, you'll naturally just do a natural sequential numbering system so you can refer to early warning 17. We all know what we're talking about. So yeah, although it doesn't mandate that, It's just so sensible, and I think that is something that most people would naturally do almost without thinking. You're on mute there, Ben.

Absolutely, yeah, yeah. And we come on to that sort of slightly pedantic bit about verbs, and this isn't sort of nostalgic, so avoid the erosion of accuracy or anything like that. This has got real practical important. So I want to stick to the verbs in the contract and really more broadly emulate the language of the contract. I remember, despite sort of authoring one of these communication systems, I still had the contract open whilst I was drafting communications through it so that I could see the template, the pro forma that was going to harness what I was about to say. But I would try and use the language, and that again, it's courteous, but it's also effective. It reduces that ambiguity, improves clarity. And again, if, you know, if the conditions of contract were like sheet music, we want everyone to play the same song, don't we? We don't want people sort of drifting off and misunderstanding where we are in the process. So trying to bring those clause numbers in, but also emulating the language helps us to do this. And it's something that graduates do really well. It's something that people like us who've had experience of other forms of contract, we almost have to unlearn some of those things, otherwise, things like, I don't know, practical completion or substantial completion or things like that, or snagging. These things start to creep in, which is actually quite dangerous for numerous reasons. We try and achieve that objectivity. Verbs is another one. So never substitute verbs for alternatives. So if the clause uses the verb accept, notify, instruct, submit, propose— under EC4, we've got inform now to soften those notices to information, which is very helpful in some places where we can batch them up. Let's stick with them. What we— so as contract practitioners, we're saying, you know, the verb is accept. You accept a design, you accept a programme, you don't approve a design. If you're doing that, I don't think we'll be able to answer the question. I don't think a lawyer could. I think a judge would be able to answer that question. Well, I've been approving designs. What does that mean? What does it do? Well, we can't. So who knows? But what can be we can be confident about is what the clause says. And it says, for example, 14.1 says acceptance by the project manager does not change the Contractor's responsibility to provide the works or liability for their design. So we know what it doesn't do. So really important we stick to that. Notification is quite important under 13.7, is that if we start using raise or alert rather than notify, so it's not raising early warnings or raising compensation, it's it's notifying them. If we depart from that language, do we run the risk of forgetting to keep them separate? You know, so there's good reason to this, and NEC isn't unique in having that rule around keeping things separate. Other contract forms deal with it slightly differently, but nonetheless it's fairly typical. Anything to add there, Glen?

No, other than we keep coming back to cloud-based systems, but they will naturally already have those hardwired in. So you tick a box to say, yes, I'm happy with this. It then writes the right language for you. So, I accept this further to Clause 31.3, I accept your programme. It won't allow a project manager to use the word approve because by ticking a box that says, yep, I am accepting this programme, the default text is written for you and you can't really go wrong. And then when you do have a text box, obviously it's to Try and avoid then using different language as well. We're talking about cloud-based systems. Here's a few screenshots. They're probably pretty small on your screen, but just to get a flavour of these contract management systems. So generally, whichever one you you've chosen or has been chosen for you, you'll have some kind of dashboard, project dashboard, and normally that could be configured to suit yourself. So it would give you useful information like. how many unagreed compensation rent quotes are currently in the system compared to how many have been accepted and implemented, when was the last accepted programme. So it will give you some— what value of agreed compensation rents have we got. So this is all valuable information that will give you as a headline on the dashboard. You can click on the various registers, the early warning register, compensation rent register, and then generally within these systems You click on the New Form button and it will list the forms that you can generate within that system. And most of these systems have thought about, okay, what communications do we need in order to be compliant with the contract? So the pro formas are there for notifying an early warning or notifying a compensation event or issuing a program for acceptance. A lot of the forms will have stuff filled in already for you, and then there'll be certain text boxes where you're going to fill in additional information, maybe add attachments, and then click submit. And then the cloud-based system will then count down where this timescale requires a response within a certain timescale. Then it will do that for you, and then both parties can keep track on what, what is the priority, what do I need to do. I've got a lot on Let's have a quick look at the system. Oh, I've only got 2 days to respond to that. I really better get on with that right now. Something else, I've got a little bit longer. I don't want to, I don't want to take the maximum time I'm allowed, but it can help me prioritize the communications I need to get across to the other party or respond to the other party. It's not the panacea. It won't solve all your problems, but it's still manual input and manual monitoring, but it just does a lot of the work for you. and keeps you on the straight and narrow to complying with NEC.

Yeah, they're all the better for a good input of records as well, Glen, but that's another story. And yeah, absolutely. And on that point about how helpful they are in various ways, I know you're getting the videos soon for your London conference, Glen, and Nick Woodrow and myself did a talk on something we coined called the Bennett Triangle. And it looks at knowledge, culture, and discipline. So knowledge, behaviors, and discipline. And we think that these systems actually provide a bit of all of that. They can help you through the knowledge of what you have to do next and how to do it. They kind of give you that cultural bit of a shared truth, a single truth, and that then the systematic discipline to keep up with what you have to do next. So obviously, that's partly governed by what resources you put in place. And, you know, one of the things when you're tendering is to have a look at things like the period for reply for certain communication types, have a look at those Z clauses if things have been changed and adjusted, and ask yourself, do I have the resources to meet those governance or those timing requirements? So this is by no means supposed to be a sales pitch for these products, but they are genuinely useful mediums through which to communicate and track the broader project management piece. Okay, where do we go next? Yeah, okay. One of the things I've often thought is that people sometimes avoid language like I instruct, because we're all very terribly polite, aren't we? And it comes across as a bit abrasive. I instruct you to attend a meeting this afternoon. I don't know. So I call this the problem of politeness. And another thing that having a set of performers, or a system, but equally a set of performers. It takes the heat out of this correspondence. I remember configuring CMAF for a client way back, probably 10 years ago, and I was sat with a contractor and the client walked past and they saw us in the room and the door flung open and the client said, is this how it's going to be? We've only been in for 2 weeks now and already I've got 13 letters from you and they're all written by lawyers. And the contractor sat next to me said, Oh no, no, that's not the case. That's Ben's fault. We were— we just turned this system on. And the relief on this guy's face. Oh, thank goodness. So it's not a team of lawyers, it's just the system. And again, it's the standard performance, the standard stationery that helps, allows us, almost gives us permission to be contractually clear, unambiguous, but without having that sort of tone of the old-school adversarialism that sometimes used to creep in. So there we go. Another little benefit there not to Not to push the point too much. Glenn?

Yeah, so sometimes these softwares can be misused, so we need to assist with understanding to formalise communications and records. It's not going to replace human interaction, so it's not just like everything— well, everything does have to be via the system, but it doesn't stop dialogue, it doesn't stop meeting face-to-face in shared offices. shocks and surprises will always, always erode trust. Having said that, we also don't want to be too afraid of using the systems. I had— I've had this a number of times on training where if we take an early warning, very simple principle, an early warning is notifying something that could be a problem. So let's get it on the table so we can talk about it. But I've heard people saying we don't send the early warning until we've spoken to the project manager first. Now, in first thoughts, you might think that's a great idea, so don't let it be a— don't let it be a shock. But we're now having to give an early warning that we're about to give an early warning. And also, if we can't speak to them immediately, we might delay the early warning being submitted. So I think it's more about thinking about the language we use in the communication, and then we can send the communication straight from the off. So if you are constructive in how you write an early warning, When the project manager opens up that early warning, they should read it and see that it is trying to highlight a potential problem, and yet already there's maybe some ideas of what we might be able to do about it, and already they're, they're taking that in a much better way than otherwise they might. So we're not saying don't talk, and you can still talk, and we can have a lot of interactions, but the communication tool is formalising those elements, but equally we don't need to be afraid of using them. You can be very adversarial in how you write a communication on a cloud-based system, but using the system does not need to be seen as being adversarial. Would you concur, David?

That's a great point, Glenn, and it goes back to what I was saying about knowledge, culture, and discipline. So you can vary— if one of those is slightly deficient, or if we haven't fully understood the concept of what an early warning is, we might become timid and our behaviors might not quite come through in the way that was intended. And also the discipline of how we are— we go back to governance again, how we're governing this. And that can drive odd behaviors and maybe even conflict with the knowledge. Take, for example, the propensity on early warnings, the one you mentioned, to sort of track how quick we are in replying. Whereas actually, you know, it's not about how quickly we've responded. It's about do we keep that early warning alive? And I guess we would point people to our first webinar, Glenn, the first one we did. Where we were making the point, and I know both you and I train in this, is to, when you're notifying an early warning, open the conversation, don't close it down, and make room for those dialogues. And EC4 has formalised that in the early warning meetings. So yeah, it's, yeah, it's a great point. And yeah, it's one of the ways in which we don't want this to sort of hinder the experience. We want it to augment it. Any other examples, Glen, of software like that?

What, how it, how it can be misused, or—

Yeah, I was thinking about the sort of Friday afternoon, uh, nice surprise over the wall, as it were.

That, that, that, that came up only a couple of weeks ago on a training session, and someone said cynically, oh yeah, the contractor, um, always all these communications coming on Friday afternoon. And I said, well, so what? To be fair, you know, they've been on site all week, and yes, Friday afternoon is maybe the last that they get back in the office and they realize, oh crumbs, I've not done that. But at the end of the day, if they send you this communication on Thursday afternoon or Friday afternoon, you've got 2 weeks to respond, whatever that may be. So what if it's on a Friday? Don't think that is a ploy. At the end of the day, they should notify as soon as they can, but if that's Friday afternoon, I can't think of anything that's less than a week in which you need to respond in the whole contract. So unless you're on holiday, but then Even if you're on holiday, well, there should be someone with delegated powers because life goes on whilst you're on holiday.

Absolutely.

Yeah, it's important to remember. And actually, on that point of sort of cooperation and collaboration, let's not confuse contractual timings as being the be-all and end-all. Because if you think about coming back to a broader topic of communications, what you've got in front of you there is perhaps a Contractor Notified Event on a Friday afternoon. Contractor's maybe got an access issue and they've notified it to you whatever day of the week, and the project manager's got a week to reply. And in this little record here, we can see the project manager replied within a week. They've given the thumbs up. Yes, it's a conversation event. And then the contractor's then got 3 weeks to submit a quotation, which they did. The project manager used the full 2 weeks to reply. Unfortunately, it wasn't quite right, and they gave their reasons and instructed a revised. So then we went into another 3-week submission period. and then a further 2-week reply. Is there anything non-compliant about this? No, absolutely not.

It's—

the auditors would be very happy, but I wouldn't be happy if I was a stakeholder on this project and this was what was happening. Does it— is it contractually compliant? Yes. Am I thrilled by it? Absolutely not. Way prefer this. And there's nothing in the contract that says you can't do this. Remember, the contract has to have a set of reasonable timescales. The one that's most obvious that I think about when we talk about this is the 8-week time bar. You know, from a point of courtesy and momentum, we would like it to be a week. But from a legal point of view, it needs to be sufficiently safe before removing someone's entitlement to be a fairly robust timeframe. Let's— that's the compliance bit. Let's collapse all that down to what's actually effective. And many clients and contractors teams, what I went to go and see over the years, the best did it like this. They sat around a whiteboard, the project manager and the contractors manager sat next to each other facing out at the room, and they brought their teams in, in their various pairs, whom had been working on half a dozen compensation events each, or a few this, a few that. Maybe the programmer and the client's person looking after they would come in and they would, they would present the work they'd done that last week, and we would submit, submit, accept, accept, submit, accept. And so you can see the timescale underneath being collapsed, and where the odd one needed a bit more time, there were extensions given and so on. So I would suggest that let's not lose track on the basis that the communication timings and the rules of communication are the maximums, they're not targets. We can do better than that. And the other thing that we achieve by doing this is we get things right first time. So there's nothing in the contract that says you can't talk to each other and evolve the work together such that the submission is successful first time round. Anything to add, Glen?

No, other than it's a shame that doesn't happen more often, isn't it? And time just adds muddiness and subjectivity. to things. So I always imagine people thinking, oh, with time the clouds will part and this beam of sunshine will shine through and everything's suddenly clear. It doesn't happen, and other stuff will have happened that now confuses maybe that situation. So yeah, the sooner we can agree these things, the sooner both parties know exactly where they are. They're not going to agree like something easily, but equally, if both parties can Get across that, yep, this is—

But I think this comes back to Ben's point about having those early and open communications, because I think that sets the context of what you're trying to achieve, and that's what sort of makes people maybe work in a common way to get things resolved. When you're working to the strict timelines that you've set out in the contract, yes, you can do that, as you said, Ben, that's fine. You're working, you're complying, and all the rest of it, but what do we actually collectively need out of this? What are the— what's the realistic position that we're in, and what are we trying to achieve? And if you just totally rely on putting the information on the cloud-based system and going through those sort of formal communications, you might miss some of the nuances around the situation you're trying to resolve. So yeah.

Yeah. I think it's the informal collaboration that the stakeholders of both parties expect of their team. That for me smacks of a healthy culture.

A good team will— that if they're working well as a collaborative team, that's what will be happening and you're going to get a better outcome.

Yeah, absolutely. And the real indicators of that cultural success are things like how many times do we accept first time? And is there a real pattern of not accepting first time, of doing lots of project managers' assessments, lots of instructions and revised quotations, lots of programme pushbacks, lots of disallowed cost? You know, we've got all the data to this. It'd be a really fascinating bit to do with the contract management system vendors to have a look at that right first time piece and try and find the gaps to culture and whether there are practical things people can be doing. And again, Volume 4 does set out a little bit of this in terms of how to run project startup workshops. It's, yeah, it's one of the reasons that scope asks you to set out the format you want things in so that we're likely to start off successfully. So yeah, it's an important one. And again, the contract doesn't spell it out exactly what, exactly how you must do things. It says what we want you to achieve and the minimums. And then, and I guess the other thing is try and build in a first look. So rather than look at something on day 13, which we all struggle with, of a 14-day period, try and build that cadence in, that rhythm of business of giving yourself a first look at stuff. And if it's obviously missing something, then you've got that time to ask for that so that you're doing that early rather than late. So we're not—

we're not—

I know that sounds naive perhaps, so we can look at everything straight away, but at least try and give it a little initial look, try and spot the things that are missing so that we, we can use that time frame to get the submission acceptable first time round. Okay, good stuff. Glenn, this is a bit of a topic, isn't it?

Other, yes, or general communications. We need to be very careful with these. So where the contract requires a communication, we need to act as stated. The contract doesn't prevent you communicating on anything else. So we can still share the program. The Clause 31.2 gives a big list of what should be shown on a program, but it doesn't stop you showing other things. So it's just saying almost like the minimum requirements that we do need. Systems then have separate modules, registers, workflows for every possible contract communication. So it is desirable to keep that system intuitive along the way. And some systems put less frequently used communications into a SIGINT module together— things like certificates, termination, meeting minutes, reports. So yeah, we want somewhere where these can be done separately. The other, or general label, speaks to communicators not having their own system module, not necessarily a contractual communication of itself. We've been quite vocal on systems that have a general communication form. And across the different systems, some of them are more dependent on that general communication form than others, and some of them have a lot of contractual requirements within those general communication forms as well. So we're generally advising rather than general communication, we have it some kind of other communications and things like meeting minutes, reports, maybe safety bulletins there is a way of communicating those and it be clear within the system how they are being shared. What we don't— if we have the danger with the general communication form otherwise is people could use that just because, oh, I've got free text, I can write anything in here, and sometimes we get people writing instructions on a general communication form just because they can, so clearly not how it's intended to be used.

Yeah, it's absolutely not a genre of communication in its own right. That's not the intention. It's a mop-up for all of the things that don't exist in explicit modules for those particular processes. And I think I have some sympathy with that. You know, it's, it would become a very unintuitive solution if you had a modular register and a form for absolutely every communication, some of which we might only use once at once, like the completion certificate, would be unwieldy. Plus, I also think there's a really strong argument for keeping peripheral correspondence in a tool where it's audited and logged and gives a richer context and narrative to the things that are formally being said, like meeting minutes. But, you know, as you said, Glen, one of the biggest errors is to— would be to use an other communication type of miscellaneous, if you call it that, to notify an early warning, almost certainly a separate workflow for that expressly for early warnings. And of course, that just sort of misses all the reporting. It doesn't hit the dashboards. So yeah, it's something that I would be very cautious delegating authority to use in a kind of system permissions way. And, you know, maybe only give it to certain members of the team who understand how the rest of the processes do Yeah, great point. Good stuff. Okay, this next bit's easy. It's just a note on timings for reply. So Clause 13.3 tells us this, unless otherwise stated, we reply within the period for replies. So what we'll find is each of the clauses, each of the conditions of contract will contain the express duties of the project manager, the contractor, and part of that is replying in time. And if the timings are given to you by the Condition of Contract, then clearly that is the timing that you have to adhere to. If the timings are not inside the clause, then the period for reply kicks in. This does have limited application, if you like. You can see the period for reply is identified in Contract Data Part 1. It's one of those things as contractors we should be looking at if we're tendering to make sure that we can meet those timings. And also, if we are a project manager working, particularly working on behalf of a client, maybe we're in separate organisations and we're signing another professional services contract perhaps to provide that duty, we need to be checking that the governance that the client is requiring of us is compatible with those periods for replying and the resources that we have available. So it's an important bit to look at, and you can dimension those out in Contract Data Part 1 to map them to the different types of communication. But yeah, governance check is probably wise. And then we have extensions, Glen.

Yep, so we can extend the timescale for replying. So Clause 13.2 The project manager may extend the period for reply if the project manager and the contractor agree before the reply is due. So the important thing there is it's if the project manager and the contractor agree, and then the project manager may do that. One slight failing I've seen with some cloud-based systems, and I do get it's hard to do within the system, But some systems in effect allow the project manager to extend the timescales without the express permission of the contractor. So it's really important that we don't hide behind that, because contractually, if that went to dispute and there's no one on the system that said, well, you didn't agree this extension of the contract, although the system said you had longer, actually you didn't have longer, and maybe you're time-barred, or maybe the answer might be something different now. So really important. that we don't abuse that power just because a system seems to let us do that.

So of course the agreement could be had in a different format, couldn't it? And the agreement might be batched up in, in some meeting minutes somewhere and exist elsewhere. And I think it's very sensible and prudent if you are going to be exercising an extension, particularly for yourself as a PM, that you point at that agreement, that it's clear. If it's not, inherent in that communication workflow within the system that you're pointing at it, so it doesn't later get challenged.

Yeah, and as it says at the bottom there, so certain other clauses might also have timescales for extension, the obvious one being Clause 62.5, so extending the time for a quotation submission. I mean, arguably, because it's already cut— I know there was a discussion in LinkedIn about, well, if 13.5 already says you can do that, Why does 62 do it expressly? But, you know, it is there as a reminder, if nothing else. I think that that's an important one that might be required to be extended because some of these CE quotes are big and you can't maybe do the CE quote within 3 weeks when it's a very big one.

Yeah, and of course, don't forget it's the period for reply, not the period for providing or submitting. So that's One of the reasons that the 62.5 expressly deals with quotations. Good stuff. 14.1 is relevant. Again, we talked about this. So 13.4, massive obligation on the PM for accepting or explaining why they are not accepting. 14.1, very relevant. Again, on the verb acceptance by the PM does not change the responsibility of the Contractor to provide the works or liability for the design. The reason we use the verb accept. Submissions can't be ignored. Reasons must be given where the reply is non-acceptance in enough detail to correct. And then we have the period for reply to resubmit. Now, don't get caught in a trap if you've been doing NEC for a while, wondering, looking at this clause thinking, well, hang on, I have the period for reply to submit, but in the compensation event quotation clauses it says that the Revised quotation is another 3 weeks. They are different things. There's an intentional difference in the language. It's a point for the geeks. 13.4 applies to things submitted for acceptance, submitted for acceptance. So examples would be things like designs, subcontractor appointments. 62.3, submitting a quotation, is just submitted. It's not submitted for acceptance, and that's how the clauses deal with the difference. So geeky point, but it's there as reference if ever it comes up. You might want to win a pub quiz with that or something, I don't know.

I've never found a pub quiz that does NEC. I keep looking, but yeah, it's not happened yet. Who Wants to Be a Millionaire is the closest we get, I think, at our conferences. 13, the final clause within Section 13 is accepting and withholding acceptance, and it empowers the project manager to withhold acceptance of a submission by the Contractor. So they can withhold acceptance. Now, it does make it clear within the withholding, for reasons stated in the conditions of contract, is not a compensation event. So if it is a valid reason for not accepting, for example, a programme submitted by the Contractor is not practical, uses that word, but if the project manager considers it's not practicable, then that is a valid reason for not accepting that submission. But equally, they can withhold acceptance for any reason whatsoever. So a common one might be design. The design might fully comply with everything in scope, and some people on training have said, well, the project manager has to accept then and then afterwards instruct something different.

No.

So the project manager has the right to say, no, I'm not accepting that design. Now I can see how you've done it. I'm not accepting that design. But if the reason they're not accepting is not a valid reason under contract, then it just then becomes a compensation event under 60.1. It just makes the decision quicker. So the project manager has decided they're not happy with that submission, but the reasons they're not happy isn't something the contractor could have known about. So it is going to be a compensation event, but it does allow them to instantly say no, this is not accepted. Yeah, anything to add on that, Ben?

No, I think that's, that's it. I just don't get caught in that trap as a contractor of telling the PM they have to accept, because it's not always the case. But do watch out for the compensation event if if they, if they do end up withholding acceptance. Okay, quick one, notification certificates, just for completeness. There's these 2 clauses. 13.6 states who issues certificates to whom, and that you do so kind of simultaneously. So this is something that systems need to be mindful of, as there is more than one recipient. So just check that your, that your system is doing that if it caters specification. Clause 13.7 is concerned with avoiding the buried notification. So we covered that one earlier. That's the one that says we must keep notifications separate. Don't rely on meeting minutes and things like that for conversations. Always put your notifications separately and in proper communications. You know, oh, I didn't see the notification because it was on page 4 of an instruction or on page 6 of another notification. is a real argument that might be made at dispute. Okay, and David, a few final thoughts. Do, if you're musing on things or unsure about something we covered, do drop a question in for us, and we'll just hand over to David for a few final thoughts.

Yeah, really, I mean, obviously looking at the timing ourselves at the moment, collaborative behaviours are extremely important, and I won't sort of go chapter and verse on this, but the— obviously we're following Clause 13, and the crux of the matter is that if we're actually communicating clearly and promptly, the issues that we're dealing with generally get resolved earlier, and there's less likelihood of commercial escalation, and that's basically what we're talking about— collaborative behaviours, working together and unlocking some of the challenges that we've got there. The other thing that we need to take on board is that, and as we've sort of spoke about earlier, or sort of alluded to earlier, the teams that we've got working on our projects are often very technically capable, but they can be insufficiently trained when it comes to some of the contractual communication requirements, and it's understanding that means that if you're going to deliver early project briefings and periodic refreshers, then you're certainly going to improve the delivery of the contract that is so reliant on the form of communications that we use. So in a nutshell, that's just, you know, putting some effort and time into getting training done Getting refreshers done on a routine basis will make a difference. And it was something I picked up in my opening statement that SECA member feedback suggests that the NEC 4 Clause 13 is often just viewed as an administrative part of the contract, but it doesn't. It really does underpin the contract, and if we don't forget that, then that's one thing.

Yeah, all good points, and a lot of what we talked about, we built, certainly was echoed in that member feedback that we had, that we— you do a little bit of a straw poll, don't you, David, before we go live with the content?

Yeah, I mean, you have to get it right formally, you need to use the right systems and the right forms and all the rest of it, but you need to to be having collaborative conversations as well, because that puts everything in the right context.

Absolutely. But we covered a lot today, but don't forget it's 8 simple rules. And when we bring that back to reference material like this, we kind of covered pretty much all— I'm struggling to think of other things we could have put into here. We've got a good follow-up question from CN, so thank you for that. It's a bit of a A teaser, isn't it? I did say you changed the scope, but you correctly point out there that if there's no system in the scope and there's no— then you wouldn't be able to do that. I guess maybe the addresses of the parties would be the fallback, because I think you complete them anyway, wouldn't you, Glen, in Contract Data Parts 1 and 2? And then the scope would be in there as well. But hopefully it's a situation that's not too typical there.

Yeah, we don't hear of them going down very often and for long. So yeah, I mean, old school, you know, yeah, a communication email, a letter, basically trying to— the advice would be try and keep it in the same format as you know it would be on the system. And then basically you can email each other what this thing is, both with an understanding that as soon as the system's live again, we will then upload those same words into the system. So we're just trying to find a workaround something that hopefully won't happen, happen too often. But again, apply the same rules: in writing, separate forms of communication, and then make sure those get backloaded into the system when it's up and running again.

And if that's delivered in an open and collaborative way, then that's going to work, isn't it?

Absolutely, yeah. And another one— thank you very much for all these good questions— this is a good question, it's a great question, and again it comes down to the wording. in the condition of contract. It is done on purpose. So where the clause says submitted for acceptance, then 13.4, the parts of 13.4 apply. So for a quotation submitted for acceptance— sorry, the quotation is just submitted— this clause doesn't override the— what would that be?

62.3.

so it isn't compliant to withhold acceptance and argue something else like information's missing. We'd simply say your assessment is incorrect or incomplete, and then I'd have one of two options. I'd either instruct revised or I would notify I was going to make my own assessment. So hopefully that, that answers that question. One thing we didn't say out loud, don't forget withholding for a reason in the contract isn't an easy way out. There's no way to kick the can down the road with NEC. There's always that momentum. So thinking about, for instance, withholding acceptance to a programme, that doesn't just put it back in the other— the contractor's court there. PMs, if you're withholding acceptance to a programme for a reason in the contract, don't miss Clause 64.1, the last bullet point, which talks about having to assess the compensation events. So there's, you know, there's— we're always looking for that momentum in NEC, aren't we, to kind of keep things moving. Okay, anything to add, Glen, David?

No, just echoing, yeah, that last point you made. It's, you know, if you don't look for, right, I'm going to find a reason why I cannot accept this submission, we should be looking at it with a view of I'm going to accept it if it's good enough, and if it's not good enough, then I will explain clearly why it's not good enough. And yeah, as you said, Ben, do that on day 2 or day 3. If there's a few things in it you already know you're not going to accept it for, let them know those reasons and you're going to carry on looking for other things, because it then gives them the chance to put that right within the 2 weeks you're reviewing the rest of the submission.

If the resources are right, to your— to that point, Glen, If the resources are appropriate, then anything other than acceptance first time, you would ask yourself at least, is that because we didn't collaborate enough on the process of working the detail through? And if not, how do we correct that? It's probably a reasonable final thought.

Yeah.

I think that takes us to the end. We're at half past 5, we're on time as unusual, and well done to all of us. Pat on the back for making it on time. The next, the next episode is going to be managing effectively. So we've by no means run out of topics, but there's been lots of sort of hints and tips over the last 11 episodes, and we wanted to just bring them together into a bit of a melting pot. I definitely think get in touch with David if you've got things that you want to share, and we'll get them in. So if you've got some top tips for NEC, Get them into David and, uh, and that will— Glenn and I, and we'll, we'll bring them together in the next episode and try and look at some practical hints and tips as well, uh, for, for just generally approaching things. Um, anything to finish on, guys?

No, I think that was very good. Thanks. And I think the, the top tips refresher is what we need anyway. I think we've covered so much ground that it's worth bringing it all together again.

Yeah, and yeah, any ideas for topics for episode 13 onwards, we're all ears. So look forward to seeing you all. And yeah, welcome back for those of you who had been off during the summer. See you next time.

Thanks, everyone.

Cheers. Thank you.