00:00 - Introduction
Glenn Hide: 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 gonna be discussing communication. So Section 13 of the contract, we're gonna 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 Hide, and Ben Walker here from Gather. And David, would you like to do a bit of an introduction?
David Allen: Hi there. Yeah, thanks, Glenn. I'm David Allen, the Executive Director for CECA Southern, which is just one part of CECA, 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 mainland UK's infrastructure. Our CECA members deliver an estimated 30 billion pounds of work per annum to the UK economy and directly employ more than 250 thousand people, with many more jobs represented across our members' extensive supply chains. CECA 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. This series of 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 NEC4 user awareness and the informed use of it to deliver more assured outcomes for all.
02:53 - Why Clause 13 is more than admin
David Allen: Some of the CECA member feedback received in preparing for this webinar suggests that 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 communications procedures were not followed correctly. We will look at today's topic in more detail as Ben and Glenn present to us, and there will be an opportunity to ask questions during the discussion at the end. So I'll now hand over to Ben from Gather.
Ben Walker: 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 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.
Ben Walker: 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'll 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 gonna be looking at today, as always, is an unamended standard NEC contract.
Ben Walker: So communicating correctly, our 11th topic, having had a bit of a break, we're gonna look through 8 little sub-clauses. They take up less than a page in the book. And 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 an interesting bit of trivia. It's the reason why it has effect when it's received rather than when we press send, or put it in the letter box.
Ben Walker: 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 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. We wanna 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.
Ben Walker: 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 Q&A. Right. So I'll hand over to Glenn for the first slide.
06:03 - Eight sub-clauses and what the Scope must say
Glenn Hide: Well, Ben, 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 our head round 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 prevent...
Glenn Hide: Governance can actually prevent the actual timescales from the contract working, which is pretty fundamentally wrong really, isn't it? Because a client setting the rules or 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 govern acceptance and what it means if withholding acceptance. And also, it's written in very specific language, and it's important we emulate that language throughout our responses in our own communications as well.
Glenn Hide: 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. 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. So there may be elements in the scope that dictates exactly what formats things have to take. So for example, the forecast of Defined Cost may have a spreadsheet or a presentation to say how they want that presented each application. Design submissions could detail exactly 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.
08:31 - Clause 13.1: read, copied and recorded
Ben Walker: Yeah, it's a good point, Glenn, 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 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 choices there will be around 30 different entries that you are expected to write in the scope to make those clauses work properly.
Ben Walker: So jumping into number one, a simple clause. It says, "Each communication in a form that can be read, copied, and recorded." And this relates to all communications required by the contract. Okay, so 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.
Ben Walker: And look, I think, again, with these systems, the need for verbal communications is diminished.
Ben Walker: 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.
Ben Walker: So quite often another question we get asked is, does WhatsApp comply, 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.
Ben Walker: But I think 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 communication? So it's strictly possible as long as things are in place, but it's unlikely to be optimal. And, you know, even if we don't have communication systems, because we didn't used to have them, carbon triplicate pads, 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.
Glenn Hide: I think the worst one I heard on that, Ben, was 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 it's about the worst you can...
Ben Walker: The messages disappear in 24 hours. They disappear. Is that the one?
Glenn Hide: Yeah. As soon as you read it, yeah.
12:29 - Clause 13.2: the communication system in the Scope
Ben Walker: Not very good for record keeping, is it?
Glenn Hide: 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 the what about WhatsApp, might that comply? It is in a form you can read, copy, and record it, but it won't then comply with clause 13.2. And this is specific to NEC4, 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 systems 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 in 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'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. 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 gonna bring. So once you specify the system, everyone needs to be using that same portal so we're all clear on the communications.
Glenn Hide: If a communication system 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, you wanna 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're advising, that we're doing pro formas rather than just bodies of email. And contract management systems, CMS, they often do more than the act of purely just communicating.
Glenn Hide: 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.
Ben Walker: Absolutely. 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, if it's not quite for you, you wanna 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. 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, you'd make the point that it was as per contract data perhaps, or 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, Glenn?
Glenn Hide: Yeah, totally. 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's crazy, because we've all got... You know, Ben, these systems shouldn't take long to set up at all.
Ben Walker: No, you should do it over the weekend. I could get one live by Monday morning, so yeah.
Glenn Hide: So the amount of times I hear projects, they're weeks in, "Oh, yeah, we're weeks in," or, "Oh, yeah, I haven't got a licence 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.
Ben Walker: And if you are convinced that one's not for you for whatever reason, then the place to find a set of those pro formas would be Volume 4, How to Manage an ECC Contract, of the guidance notes. There are some pro formas at the back, I think, in the appendix. And if you want a guide on how to write scope, which is my 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.
17:32 - Who you write to, and delegated authority
Ben Walker: Okay, let's turn our attention then to when the communication has effect, so we know whether or not we're gonna use a communication system set out in the scope.
Ben Walker: Couple of other really important things. We've gotta make sure that 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, Contractor's 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.
Ben Walker: Ensure the communications are being sent to the correct individual. And don't assume just because it's to do with defects, it's gotta be to and from a Supervisor. That duty switches to the Project Manager for accepting defects. So 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 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.
Ben Walker: 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. What's next, Glenn?
Glenn Hide: 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, 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 the authorised person under contract.
Ben Walker: Just to cross the Ts and dot the Is 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 was one of the communication types under general communications that we created under clause 14.2 that you could then notify. So you should be notifying your delegations at the start of the contract for them to really bring them into effect. So make sure that 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.
Glenn Hide: Yeah, absolutely. Great advice.
Glenn Hide: 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 pull in the clause number. So it does help because it reinforces why you're saying something. 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 process. 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?"
Glenn Hide: 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.
Glenn Hide: 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 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 and the values in there as well.
Glenn Hide: There is no requirement to keep registers or number events and matters, 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 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.
23:06 - Sticking to the NEC verbs: accept, notify, instruct
Ben Walker: Absolutely, yeah. And we come on to that sort of slightly pedantic bit about verbs. And this isn't nostalgic, so avoid the erosion of accuracy or anything like that. This has got real practical importance. So we're gonna stick to the verbs in the contract and really more broadly emulate the language of the contract. I remember, despite 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 gonna 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 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 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 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.
Ben Walker: 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 - let's stick with them. So as contract practitioners, we're saying 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. "What? Well, I've been approving designs. What does that mean? What does it do?" But what 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 responsibility of the Contractor to Provide the Works or liability for their design." So we know what it doesn't do. So it's really important we stick to that.
Ben Walker: Notification's quite important. 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 events. It's notifying them. If we depart from that language, do we run the risk of forgetting to keep them separate? 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, Glenn?
Glenn Hide: 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, "Yeah, 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.
Glenn Hide: 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've chosen or has been chosen for you, you'll have some kind of a project dashboard. And normally, that can be configured to suit yourself, so it would give you useful information like how many unagreed compensation event quotes are current in the system, compared to how many have been accepted and implemented. When was the last accepted programme? So it will give you what value of agreed compensation events 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 event register.
Glenn Hide: 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 programme 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 gonna 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 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 wanna take the maximum time I'm allowed, but it can help me prioritise the communications I need to get across to the other party or respond to the other party. It's not a panacea. It won't resolve all your problems, 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.
Ben Walker: Yeah. They're all the better for a good input of records as well, Glenn, but that's another story. And 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 Whitrow and myself did a talk on something we coined called the Bennett Triangle, and it looks at knowledge, culture and discipline, so knowledge, behaviours 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 give you that cultural bit of a shared truth, a single truth, and 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 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.
Ben Walker: 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." So I call this the problem of politeness. And another thing that having a set of pro formas or a system does, it takes the heat out of correspondence. I remember configuring a system 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 gonna 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 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 pro formas, the standard stationery that helps, allows us, almost gives us permission to be contractually clear, unambiguous, but without having that tone of the old school adversarialism that sometimes used to creep in. So there we go, another little benefit there, not to push the point too much. Glenn?
Glenn Hide: Yeah. So sometimes these softwares can be misused, so we need to assist with understanding to formalise communications and records. It's not gonna replace human interaction, so it's not just that 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 erode trust. Having said that, we also don't wanna be too afraid of using the systems. 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, on first thought, you might think that's a great idea, don't need to 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 think 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 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, Ben?
Ben Walker: That's a great point, Glenn. And it goes back to what I was saying about knowledge, culture and discipline. So 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 behaviours might not quite come through in the way that was intended. And also, the discipline of 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 track how quick we are in replying. Whereas actually, 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 that when you're notifying an early warning, open the conversation, don't close it down, and make room for those dialogues. And NEC4 has formalised that in the early warning meetings. So yeah, it's one of the ways in which we don't want this to hinder the experience. We want it to augment it.
Ben Walker: Any other examples, Glenn, of software like that?
Glenn Hide: What, how it can be misused?
Ben Walker: Yeah, I was thinking about the sort of Friday afternoon nice surprise over the wall, as it were.
Glenn Hide: 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, they've been on site all week, and yes, Friday afternoon is maybe the last - 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 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, there should be someone with delegated powers because life goes on whilst you're on holiday.
36:11 - Timescales are maximums, not targets
Ben Walker: Absolutely, yeah. It's important to remember. And actually on that point 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 the broader topic of communications, what you've got in front of you there is perhaps a contractor notified event on a Friday afternoon. A 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 compensation 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 revise. 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. The auditors would be very happy,
Ben Walker: but I wouldn't be happy. If I was the stakeholder on this project and this was what was happening, is it contractually compliant? Yes. Am I thrilled by it? Absolutely not.
Ben Walker: 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. 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.
Ben Walker: That's the compliance bit. Let's collapse all that down to what's actually effective. And many clients and contractor teams, when 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 contractor's 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 programmer and the client's person looking after the programme, they would come in and 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
Ben Walker: 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, Glenn?
Glenn Hide: 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.
David Allen: 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 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'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 formal communications, you might miss some of the nuances around the situation you're trying to resolve.
Ben Walker: 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.
David Allen: A good team, if they're working well as a collaborative team, that's what will be happening, and you're gonna get a better outcome.
Ben Walker: 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 Manager assessments, lots of instructions, revised quotations, lots of programme 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 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 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 out exactly how you must do things. It says what we want you to achieve and the minimums. And I guess the other thing is try and build in a first look.
Ben Walker: 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 I know that sounds naive perhaps, that 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 so that we can use that timeframe to get the submission acceptable first time round. Okay, good stuff. Glenn, this is a bit of a topic, isn't it?
42:31 - General communications and the mop-up trap
Glenn Hide: 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 programme, clause 31.2 gives a big list of what should be shown on a programme, 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 single module together, things like certificates, termination, meeting minutes, reports. So yeah, we want somewhere where these can be done separately.
Glenn Hide: The other or general label speaks to communications 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 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. 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.
Ben Walker: 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. It would become a very unintuitive solution if you had a module, a register 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, as you said, Glenn, one of the biggest errors would be to use an other communication type, a miscellaneous, if you call it that, to notify an early warning, because there's almost certainly a separate workflow for that expressly for early warnings. And of course, that just misses all the reporting. It doesn't hit the dashboards. So it's something that I would be very cautious delegating authority to use in a kind of system permissions way. And maybe only give it to certain members of the team who understand how the rest of the processes do work.
Glenn Hide: Yeah, great point.
45:50 - Clause 13.3 period for reply and 13.5 extensions
Ben Walker: 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 reply.
Ben Walker: 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.
Ben Walker: 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 separate organisations and we're signing another professional services contract perhaps to provide that duty, we need to be checking that
Ben Walker: the governance that the client is requiring of us is compatible with those periods for reply 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 One to map them to the different types of communication. But yeah, a governance check is probably wise.
Ben Walker: And then we have extensions, Glenn.
Glenn Hide: Yep. So we can extend the timescale for replying. So clause 13.5, 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 nowhere on the system that said, "Well, you didn't agree this extension with the Contractor," so though 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.
Ben Walker: Well, of course, the agreement could be had in a different format, couldn't it? And the agreement might be batched up in some meeting minutes somewhere and exist elsewhere. And I think it's very sensible and prudent if you are gonna be exercising an extension, particularly for yourself as a PM, that you point out 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.
Glenn Hide: And as it says at the bottom there, 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, I know there was a discussion on LinkedIn about, well, if 13.5 already says you can do that, why does 62.5 do it expressly? But it is there as a reminder, if nothing else. I think 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.
Ben Walker: 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 62.5 expressly deals with quotations. Good stuff.
49:54 - Clauses 13.4 and 13.8: acceptance and withholding
Ben Walker: 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. So it's 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.
Ben Walker: Now, don't get caught in a trap if you've been doing NEC for a while, 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.
Glenn Hide: 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.
Glenn Hide: 13.8, 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, withholding for the 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 practicable - uses that word - 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.
Glenn Hide: 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 becomes a compensation event under 60.1(9). It just makes the decision quicker. So the Project Manager's 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."
Glenn Hide: Anything to add on that, Ben?
Ben Walker: No, I think 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 they do end up withholding acceptance.
Ben Walker: Okay, quick one. Notifications and certificates, just for completeness. There are 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 system is doing that. Clause 13.7 is concerned with avoiding the buried notifications. 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.
Ben Walker: Okay. And David, a few final thoughts. If you're musing on things or unsure about something we covered, do drop a question in for us, and we'll hand over to David for a few final thoughts.
54:30 - Final thoughts and audience Q&A
David Allen: Yeah, really. I mean, obviously, looking at the timing ourselves at the moment, collaborative behaviours are extremely important. And I won't go chapter and verse on this, but obviously we're following clause 13, and
David Allen: 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.
David Allen: The other thing that we need to take on board is that, as we've 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 understanding that means that if you're gonna 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, putting some effort and time into getting training done, getting refreshers done on a routine basis will make a difference.
David Allen: And it was something I picked up in my opening statement, that CECA member feedback suggests that NEC4 Clause 13 is often just viewed as an administrative part of the contract. But it really does underpin the contract. And if we don't forget that, then that's one thing that will make quite a difference.
Ben Walker: Yeah. No, all good points. And a lot of what we talked about was echoed in that member feedback that we had. You do a little bit of a straw poll, don't you, David, before we go live with the content?
David Allen: We do. 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 be having collaborative conversations as well because that puts everything in the right context.
Ben Walker: 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 of it. I'm struggling to think of other things we could have put into here.
Ben Walker: We've got a 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 change the scope, but you correctly point out there that if there's no system in the scope, 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, Glenn, in Contract Data Parts One and Two? And then the scope would be in there as well. But hopefully, it's a situation that's not too typical there.
Glenn Hide: Yeah. We don't hear of them going down very often and for long. So yeah, old school, a communication email, a letter. Basically 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 could 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 too often. But again, apply the same rules. In writing, separate forms of communication, and then make sure those get back loaded into the system when it's up and running again.
David Allen: And if that's delivered in an open and collaborative way, then that's gonna work, isn't it?
Ben Walker: Absolutely, yeah. And another one, thank you very much for all these good questions.
Ben Walker: This is 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 applies. So for a quotation, the quotation is just submitted, so this clause doesn't override 62.3. So it isn't compliant to withhold acceptance and argue something else,
Ben Walker: 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 to revise, or I would notify I was gonna make my own assessment. So hopefully that answers that question.
Ben Walker: 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 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 we're always looking for that momentum in NEC, aren't we, to keep things moving. Okay. Anything to add, Glenn, David?
Glenn Hide: No, just echoing that last point you made. 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 2 or day 3. 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 2 weeks you're reviewing the rest of the submission.
Ben Walker: If the resources are appropriate, to that point, Glenn,
Ben Walker: then anything other than acceptance first time,
Ben Walker: 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?" is probably a reasonable final thought.
Ben Walker: I think that takes us to the end. We're at half past 5. We're on time. That's unusual. And, well done to all of us. Pat on the back for making it on time. The next episode is gonna be Managing Effectively. So we've by no means run out of topics, but there's been lots 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 wanna share, and we'll get them in. So if you've got some top tips for NEC, get them into David, or Glenn and I, and we'll bring them together in the next episode and try and look at some practical hints and tips as well for just generally approaching things. Anything to finish on, guys?
David Allen: No, I think that was very good. Thanks. And I think 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.
Ben Walker: Yeah. And 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.
Glenn Hide: Thanks, everyone.
David Allen: Yes, thank you.
.webp)
