The NEC4 Brief
Hosted by Ben and Glenn, The NEC4 Brief is a monthly podcast that unpacks the ins and outs of the NEC4 contract, one clause, one issue, one real world example at a time.
Each episode takes a practical look at how the contract actually works on site, not just on paper. From compensation events and early warnings to risk allocation and programme management, Ben and Glenn translate legal jargon into everyday lessons for contractors, project managers and quantity surveyors.
It’s straight talking, experience led insight from two practitioners who’ve seen how NEC4 plays out in the real world: the good, the bad and the “that’s not what the contract says.
The NEC4 Brief
NEC4 Communication Done Properly
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
Treat NEC4 clause 13 like “just admin” and you set yourself up for slow decisions, muddied records, and avoidable disputes. We dig into the practical reality of communicating under NEC4: why contract-required notices must be written, what “has effect when received” really means, and how quickly a casual habit like verbal instructions can put a team on the back foot.
We also get specific about systems. If the communication system is stated in the Scope, that is the route that gives your message contractual effect, which is why mixing portals with side emails or messaging apps creates risk and fragments the record. We talk through real-world questions teams keep asking, including whether WhatsApp fits the rules, why disappearing-message tools are a disaster for record keeping, and how to cope when a system is not live or temporarily fails.
Language and roles matter too. We share tips on using NEC identified terms, keeping to the contract verbs (accept rather than approve), checking delegated authority, and making sure notices go to the right person. We also explore how good teams collapse timelines through collaboration, treat reply periods as maximums not targets, and keep notifications separate so they cannot be “buried” in minutes or general correspondence.
If you want sharper NEC4 contract administration, fewer misunderstandings, and faster agreement on submissions, this one is for you. Subscribe, share it with your project team, and leave a review with the communication habit you want to fix next.
View the webinar: https://www.gatherinsights.com/en/webinars
Join the LinkedIn Group: https://www.linkedin.com/groups/2893228/
Welcome And Why Clause 13 Matters
SPEAKER_00Good 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 rearing to discuss all things NET in our uh 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 Glenn Heid and Ben Walker here from Shortly. And David, would you like to do a bit of an introduction?
SPEAKER_01Hi there. Yeah, thanks, Glenn. Yeah, I'm David Allen, as it says, the Executive Director for Seeker Southern, which is just one part of Seeker, 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 Seeker members 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, Seeker 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 at our Seeker website. This series of NEC webinars, NEC4 webinars, is aligned to our Seeker 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 seeker 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 will obviously look at today's topic in more detail as Ben and Glenn 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.
SPEAKER_02Thank you, David. Good afternoon, all. Hope you had a great summer. And those last couple of points David made are member feedback, they're captured in a slide in our final thoughts at the end as well for reference. Because of course, all of these webinars are available to re-watch through the various channels. I think we're live on YouTube and a couple of others. And so, yeah, you can 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 QA as well. And so we're hoping for some quot some questions as we go today. Please do drop your questions in the chat there and we'll we'll make sure we've got a bit of time towards the end uh to take as many of those as we can. I'll remind you that uh this is not legal advice, but we're hopefully uh exploring some practical hints and tips of of how to apply this theory in practice. And do, of course, also take note of your Z clauses because what we're gonna be looking at today, as always, is an unamended standard NEC contract. So, communicating correctly, our 11th topic, having had a bit of a break, we're gonna look through eight little subclauses. 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.
Communication Errors That Trigger Disputes
SPEAKER_02And it's uh sort of interesting, bit of trivia. It's sort of the reason why it has effect when it's received, uh, rather than when we press or put it in a letterbox. So we're gonna look at those. We're gonna look at the form of these communications, the language that we use, and also when it has effect. We'll then look at uh 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 we we want to do it properly. Um, 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 gonna look at notifications and certificates and then we'll wrap up with final thoughts and we'll jump into those useful resources and QA. Right. So I'll hand over to Glenn for the first slide.
SPEAKER_00Well then, you said it's less than a page, and it is. It's only eight subclauses in clause 13. So quite a small section, but some really simple, yet pretty fundamentally important uh clauses to understand and get a head round within the contract. So important to prepare systems and governance and to meet the format and timings required. Yeah, governance. So we talked about this at our London conference and how sometimes uh clients can uh uh 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 setting the rules or the choosing the contract and the rules they want, yet their own internal governance prevents them from achieving that. So that maybe is a a topic of another webinar in in the future. And as we already said, it's more than just administration, but there's some very important conditions uh that sort of govern acceptance and uh what it means if uh withholding acceptance or and it also is written in very specific language, and it's important we emulate that language uh 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 that the NET's got identified 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 as well. So there may be elements in the scope that dictates exactly what the 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 for each application. Design submissions could detail exactly what needs to be how it needs to be put forward, same for test inspections, programs 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.
SPEAKER_02Anything to do, Glenn, isn't it? How 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 are 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 are being 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
Written Records Only No Verbal Notices
SPEAKER_02choices, will be around 30 different entries that you're expected to write in the scope to make those clauses work properly. So, jumping into number one, a simple clause. It says each communication in a form that can be read, copied, and recorded. And these are this relates to all communications required by the contract. Okay, so okay, 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 hear quite often here is no verbal instructions. Well, actually, it's broader than that. It's no verbal communications of any kind, which the 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 says do what the contract says. So let's not confuse those two. 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 uh quite often another question we get asked is 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 and and copy. But I think it as we learn the rest of these eight rules, because they are taken together as a collection, we might find that there are other things it might not satisfy, such as is it has it been identified as the address for notified by the parties for receiving communication. 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 a 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 the dialogue. We'll see that in a moment. So lots of conversation is still making the world go around. Um, writing, very small point on this clause, but writing is in the language of the contract. That's an italicized term, it's an identified term, and that's something we'll need to look up in contract data part one, where it will tell us the language of the contract. Okay, go ahead.
SPEAKER_00I think the worst one I heard on that, Ben, was uh one project they were communicating via Snapchat. Now, I don't know if anyone knows anything about Snapchat. The whole irony of it is it self-destructs once you've read it. So uh that's about the words. The messages disappear in 24 hours, they disappear. Is that the one? Is that yeah as soon as you read it, yeah.
SPEAKER_02It's uh not very good for record keeping, is it?
SPEAKER_00No, I'm sure Gather would have a thing to uh to say about that. So 13.1 is really clear and in particular no verbal. Ben Morley mentioned the what about WhatsApp? Might that comply? It is in the formically red copy and recorded, but it won't then comply with clause 13.2. And this is specific into NEC4, these 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 lights of uh I think project or and 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
WhatsApp Snapchat And The Record Trap
SPEAKER_00important. We'll always talk about cloud-based systems, and it's for you to do your own homework and 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 such like. And you want one version of the truth. So it'll 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 everyone, unless you've been copied in on that, you won't see that communication. So it's imperative that where uh 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've specified a system, everyone needs to be using that same portal so we're all clear on the uh 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 such like. 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 element, you want to have a set of proformers that in effect do the equivalent of a cloud-based system. And then you're emailing attachments, and those attachments, you'll have an instruction form, notification, and 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 proformers rather
When A Message Has Contract Effect
SPEAKER_00than just bodies of email. 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. Um, 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.
SPEAKER_02Absolutely. And I think that's probably the answer to this question, isn't it, Glenn? 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 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 it will be a conversation then, but you can react quickly and make sure that uh that those arrangements keep pace with with whatever the reality of those communication systems are. So uh thanks for the question. I think uh that's probably the answer to it, is because it's in scope, you can change the scope, uh which would have an immediate effect. So you could quite quickly put something in place, or if you if you were to remove it temporarily, I think you'd you'd make the point that it was uh as as per contract data, perhaps, but uh or or make you know make some other arrangement. But it it is within the project manager's gift to swap things around. Again, it's another reason it's not in contract data. Which you would you agree with that, Glenn? I think that's the answer to that question.
SPEAKER_00Yeah, totally. Uh it's a great point from CN. It's something I hear a lot. The project teams just don't have it set up at the beginning. And it it's crazy because we've all looked at you know, Ben, these systems shouldn't take long to set up at all.
SPEAKER_02No, I used to do it over the weekend. I could I could get one live by Monday morning. So yeah.
SPEAKER_00So the amount of times I hear projects, they're weeks, oh yeah, we're 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 project.
SPEAKER_02And if you are convinced that one's not for you for whatever reason, then then the place to find a set of those performers would be volume four, how to manage an ECC contract. That of the guidance notes. There was some performers 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 uh volume two, how to prepare a contract. It's in chapter three. Uh so if you're listening back to this, there's some useful reference. Okay, let's turn our attention then to the when the communication has effect.
Roles Delegations And Writing To The Right Person
SPEAKER_02So we know whether or not we're gonna 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's written in italics, contractors 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 that 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 a supervisor. That duty switches to the project manager for accepting defects. So, you know, just double check things that 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 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 Z clauses. We said that already, but there may be some Z clauses that move those express duties around and give them to other people.
SPEAKER_00Uh what can you? And again, the 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 and the authorised person under the contract.
SPEAKER_02Just to cross cross the T's and dot the I's on that, Glenn. We should nonetheless, on day one, 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. You 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 uh a hygiene check, I guess.
unknownYeah.
SPEAKER_00Yeah, yeah, absolutely. Great advice. Users are not required to quote the clause numbers. I mean, it's common practice and it is helpful, and even you could say courteous. But it leaves the other party and no ambiguity as to 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 drop down and you look through for the reason uh 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 you're saying something is for example, if 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 world, where in the contract does it does it say that? You know, one of the other positive things, I think we cover it in a in a while, is the uh 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 we'll pick up on that again shortly. We do have defined and identified terms, so don't invent new ones as a post-contract. So make sure we're using the established defined terms, obviously, as a clauses, can have extra defined terms, and that probably does warrant depending on 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 an EC and make sure we're using the contract data inches and the values in there as well. Um, there is no requirement to keep registers on number events and matters, but again, very sensible and difficult 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 uh what we're talking about. So early warnings. Or naturally just do a natural sequential numbering system so you can refer to early warning 17, but we all know what we're talking about. And 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
Use NEC Verbs And Defined Terms
SPEAKER_00thinking. You're on mute there, Ben. Absolutely, yeah.
SPEAKER_02Yeah. And uh we come on to that sort of slightly pedantic bit about verbs, and this isn't sort of nostalgic, so avoid the erosion of uh of of accuracy or anything like that. This has got real practical importance. So I want to stick to the verbs in the contract and really more broadly emulate uh the language of the contract. I remember despite sort of authoring one of these communication systems, I I still had the contract open whilst I was drafting communications through it so that um I could see the template, the performer that was gonna harness what I was about to say. But I would try and use the language, and that again is courteous, but it's also effective. It reduces that ambiguity, improves clarity. And again, if 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 trying to bring those clause numbers in, but also emulating a language helps us, helps us to do this. And it's 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 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 NEC4, we've got inform now to soften those notices to informations, which is very helpful in some places where we can batch them up. Um, let's stick with them. What we it's so as contracts practitioners, we're saying, you know, the verb is accept. You accept a design, you accept a program, you don't approve a design. Uh, 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, well, I've I've been approving designs. What does that mean? What does it do? Well, what we can, 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 contractors, the responsibility of the contractors provide the works or liability for their design. So we know what it we know what it doesn't do. So it's really important we stick to that. Uh notification is quite important under 13.7 is that you know, 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 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, Glenn?
SPEAKER_00No, other than we keep coming back to cloud-based systems, but they will naturally already have those hardwired in. So you you tick a box to say, yes, I'm 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 program. It won't allow
Cloud Contract Systems What They Fix
SPEAKER_00a project manager to use the word approve because by ticking a box that says, Yeah, I I am accepting this program, the default text is written for you and uh you can't go can't really go wrong. And then when you do have a text box, obviously it's to uh 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 uh contract management systems. So generally, whichever one you you've chosen or has been chosen for you, you'll have some kind of uh of dashboard, uh project dashboard. And normally that could be configured to suit yourself. So it would give you useful information like how many unagreed compensation rate quotes are current in the system compared to how many have been accepted and implemented. When was the last accepted program? So it will give you some uh what value of agreed compensation rates 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 rate register, and then generally uh within these systems uh you click on the new form button and it will list the forms that you can generate uh within that system. And most of these systems have thought about okay, what communications do we need in order to be compliant with the uh with the contract. So the proformers are there for notifying an early warning or notifying a compensation event or issuing a program for uh acceptance. A lot of the forms will have stuff filled in uh 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 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 two 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 be 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.
SPEAKER_02Yeah, they're they're all the better for a good input of records as well, Glenn, but that's another story. And and uh yeah, absolutely. And I uh on that point about how helpful they are in various ways, I know you're getting the videos soon for your London conference, Glenn. And Nick Woodrow myself did a talk on something that we coin called the Bennett Triangle, and it and it looks at um knowledge, culture, and discipline, so knowledge behaviours and and discipline. And we think that that uh these systems actually provide a bit of all of that. They they can help you through the knowledge of what you have to do next uh and how to do it. They kind of give you that cultural bit of a shared truth, the 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 apply 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 uh I call this the problem of politeness. And uh 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 a CMO 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 come the door flung open, and the client said, Is this how it's gonna be? We've only been in for two 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 and said, Oh no, no, that's not the case. That's Ben's fault. We were we 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?
Formal Notices Without Killing Collaboration
SPEAKER_00Yeah, um, 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 by the system, but it doesn't stop dialogue, it doesn't stop meeting face to face in shared offices. Having said that, we also don't want to be too afraid of of using the systems. I had I've had this a number of times on training where uh if we take an early warning, a 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 thought, you might think that's a great idea, so uh 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 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 formalizing those elements, but equally, we don't need to be afraid of using them. You can be very adversary 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 go through? That's a great point.
SPEAKER_02That's a great point, Glenn. And it goes back to what I was saying about knowledge, culture, and discipline. So you can very if 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 going, we go back to governance again, how we're governing this. And that can drive odd behaviours 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 and I I guess we would point people to our first webinar plan, 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 and 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, Glenn, of of software like that? What how 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.
SPEAKER_00Uh that that that that that came up only a couple of weeks ago on a training session, and someone said cynically, oh yeah, the contractor always all these communications come on a 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 realise, 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 two weeks to respond, whatever that may be. So so what if it's on a Friday? Don't think that is a ploy. At the end of the day, they should
Faster Agreement By Collapsing The Timelines
SPEAKER_00notify as soon as they can, but if that's Friday afternoon, I can't 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 the life goes on whilst you're on holiday.
SPEAKER_02Absolutely. 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 bill and end all because if you think about community back to the topic of a broader topic of communications, what you've got in front of you there is perhaps a contractor-notified event on a Friday afternoon. Contractors 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 contractors then got three weeks to submit a quotation, which they did. The project manager used a full two weeks to reply. Unfortunately, it it wasn't quite right, and they gave their reasons and instructed a revised. So then we went into another three-week submission period and then a further two-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 the 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 eight-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 time frame. Let's that's the compliance bit. Let's collapse all that down to what's actually effective. And many clients and contractor 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 who had been working on half a dozen compensation events each, or a few this, a few that. Maybe the program, the programmer and and and the clients, person looking after the program, they would come in and they would then 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 time scale 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 and evolve the the work together such that the submission is successful first time round. Anything to add, go ahead.
SPEAKER_00No other than it's a shame that doesn't happen more often, isn't it? And time just adds muddiness and uh subjectivity to things. So I I 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.
SPEAKER_01They're not going to agree like something easily, but equally, if both parties can get across that, yeah, 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 uh just totally rely on uh putting the information on the cloud-based system and 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.
SPEAKER_02I think it's the informal collaboration that the stakeholders of both parties expect of their team. That for me smacks up a healthy culture.
SPEAKER_01A good team will that if if they're working well as a collaborative team, that's what will be happening. And you're gonna get that around some, yeah.
SPEAKER_02Absolutely, and the real indicators of that cultural success are things like how many times do we accept first time? And 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 program pushbacks, lots of disallowed costs. 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 to try and find the gaps to culture and whether there are practical things people can be doing. And again, volume four does set out a little bit of this in terms of how to run project startup workshops. It's uh yeah, it's 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 uh 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're all 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 we'd we can look at everything straight away, but at least try and give it an initial look, try and spot the things that are missing
General Communications And Misuse Risks
SPEAKER_02so that we we can use that time frame to get a submission acceptable first time around. Okay, good stuff. Uh Glenn, this is a bit of a topic, isn't it?
SPEAKER_00Other, yes, or general communications. We need to be very uh 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 uh it's just saying almost like the minimum requirements that uh that we do need uh systems then have separate modules, registers, workflows for every possible contract communication. So it is desirable to keep that system uh intuitive along the way. Uh and some systems put less frequently used communications into a significant module together, uh things like certificate, termination, meeting, minutes, report. So yeah, we want that somewhere where these can be done separately. The other or general labels speaker to communicators not having their own system module, but not necessarily a contractual communication uh 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 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 are being shared. Well, we don't if we have the the danger with a general communication form, otherwise, is people can use that uh 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.
SPEAKER_02Yeah, 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 it's uh it's it would become a very unintuitive solution if you had a module, a register, and a and a form for absolutely every communication, some which we might only use once, like the completion certificate. It 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, Gleve, one of the biggest errors is to would be to use uh an other communication type, a miscellaneous, if we call it that, to notify Early warning because there's 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 it's it's it's it's something that um I would be very cautious delegating authority to use uh in in a kind of system permissions way,
Period For Reply And Agreed Extensions
SPEAKER_02and you know, maybe only give it to certain members of the team who understand how the rest of the processes do work. Yeah, great point. Good stuff. Okay. This next bit's easy. It's just a note on timings for reply. And so clause 13.3 tells us this. And 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 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 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. And this does have limited uh application, if you like. You can see the period for reply is identified in contract data part one. 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 organizations and we're signing another professional census contract perhaps to provide that duty. We need to be checking that the governance that that the con that the client is requiring of us is compatible with those periods for applying 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 one to map them to the different types of of communication. But yeah, governance check is is probably wise. And then we have extensions, Glenn.
SPEAKER_00Yep. So we can extend the timescale for replying. So clause 13.5, uh the project manager may extend the period for applying 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 don't think, 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 nowhere on the system that said, well, you didn't agree this extension of the contract. So though the system said you had longer, actually you didn't have longer, and maybe you have 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.
SPEAKER_02So But of course, the the agreement could be had in a different format, couldn't it? And uh 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 in within the system that you're pointing at it, so it doesn't later get challenged.
SPEAKER_00Yeah. 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 uh 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 625 do it expressly? But you know, it is there as a reminder, if nothing else, I think that uh that's an important one that uh might be required to be extended. Because some of these CE quotes are big and you can't maybe do the CE quote within three
Acceptance Withholding And Compensation Events
SPEAKER_00weeks when it's uh a very big one.
SPEAKER_02Yeah, and and of course, that 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 with quotations. 14.1 is relevant. Again, we we talked about this. So 13.4, massive obligation on the PM for accepting or explaining why they're they are not accepting. 14.1, very relevant again on the verb acceptance by the PM does not change the responsibility of the contract provider works or liability for the design, so it's the reason we use the verb accept. Uh, 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 three weeks. They are different things. There's a 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 uh win a pub quiz with that or something. I don't know.
SPEAKER_00I've I've never found a pub quiz that does any C. I I I I keep looking, but um yeah, it's not happened yet. So Who Wants to Be Millionaire is the closest we get, I think, at uh at our conferences. 13.8, the final clause within uh section uh 13 is accepting and withholding acceptance, and it empowers the project manager to withhold acceptance of a submission by the contractor, so they can uh withhold acceptance. Now it does make it clear within the withholding for the reasons stated in the conditions of contract is not a compensation effort. So if it is a valid reason for not accepting, for example, a program submitted by the contractor is not practical, uses that word. But if the project manager considers it's not practical, 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, or the 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 of the contract, then it just then becomes a compensation event under 60.1 brackets nine. It just makes the decision quicker. So the project manager decided they're not happy with that submission, but the reasons that 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.
SPEAKER_02Anything to add on that, Ben? No, I think that's uh that's it. I just don't get caught in that trap as a contractor of telling the PM they can't they have to accept, is is 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. Uh notification certificates, just for completeness,
Separate Notifications And Certificates
SPEAKER_02there's these two clauses. Uh 13.6 states who issues certificates to whom, and 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 if it caters for certification. Clause 13.7 is concerned with avoiding the buried notifications. 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 your notifications uh separately and in in proper communications. You know, oh, I didn't see the notification because it was on page four of an instruction or on page six of another notification is a real argument that that might be made at dispute. Okay. And David, a few final thoughts. Do you do uh 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.
SPEAKER_01Yeah, really. I mean, obviously, looking at the timing ourselves at the moment, uh collaborative behaviours are extremely important. And I won't sort of uh go chapter
Training Culture And Next Steps
SPEAKER_01and verse on this, but the obviously we're we're following clause 13, and the 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 a 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 formal 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 seeker member feedback suggests that the NEC4 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 that's one thing to uh that will make quite a difference. Yeah, no good all good points.
SPEAKER_02And and a lot of what we talked about, we felt certainly was echoed in that member feedback that we had of that. We you you do a little bit of a scroll poll, don't you, David, before we go live with the content too?
SPEAKER_01Yeah, I mean you 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 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 eight simple rules.
SPEAKER_02And when we bring that back to uh reference material like this, we kind of covered pretty much all of I I was you know, I'm struggling to think of uh other things we could have put into here. We've got a good good follow-up question from CN, so thank you for that. It's a bit of a teaser, isn't it? I did say you changed the scope, but you correctly point out there that if if there's no system in the scope and there's no uh then you wouldn't be able to do that. I I I guess maybe the addresses of the parties would be the fallback, because I think you complete them anyway, wouldn't you, Glenn, in contract data parts one and two, and then the uh scope would be in there as well. But hopefully it's a situation that's not too too typical there.
SPEAKER_00Yeah, we don't hear of them going down very often and for long. So yeah, I mean, old school, you know, yeah, uh 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, separately from our forms of communication, and then make sure those get backloaded into the system when it's up and running again.
SPEAKER_01And if that is delivered in an open and collaborative way, then that's going to work, isn't it? Absolutely, yeah.
SPEAKER_02And another one, thank you very much for all these good questions. This is a good question, it's a great question. And and again, it comes down to the wording in the 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. Um, so for a quotation submitted for acceptance, sorry, a quotation is just submitted, it 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 a revised or I would notify I was going to make my own assessment. So hopefully that that answers that question. One 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 any C. Um, there's always that momentum. So thinking about, for instance, withholding acceptance to a program, that doesn't just put it back in the other, the other, the contractors call PMs. If you're withholding acceptance to a program 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 uh 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, Glenn? Date?
SPEAKER_00No, just echoing yeah, that that last point you you made. Um, it's you know, if uh don't look for right, I'm gonna find a reason why I cannot accept this submission. We should be looking at it with a view of I'm gonna 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 two or day three. If there's a few things in it you already know you're not gonna accept it for, let them know those reasons, and you're gonna carry on looking for other things because it then gives them the chance to put that right within the two weeks you're reviewing the rest of the submission.
SPEAKER_02If the resources are right, to your to that point, Glenn, 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 of working the detail through? And and if not, how do we correct that? It's probably a reasonable fun thought. I think that takes us to the end. We're at half past five, we're on time, as unusual, and uh well done to all of us. Pat on the back for making it on time. Uh, the next the next episode is uh 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 with David if you've got things that you want to share and and we'll get them in. So if you've got some top tips for NEC, get them into David and uh and or Blenn and I and we'll we'll bring them together in in the next episode and try and look at some practical hints and tips as well for for just generally approaching things. Anything to finish on, guys?
SPEAKER_01No, 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.
SPEAKER_02And uh yeah, uh any ideas for topics for episode 13 onwards, we're all ears. So uh look forward to seeing you all. And uh yeah, welcome back for those of you who hadn't been off during the summer. See you next time.
SPEAKER_01Thanks everyone. Cheers, thank you.
