NEC4: Ep.05 - Programme: Getting it working for you.

Foreign.

Good afternoon everyone and welcome to episode five of our webinar series Happy New Year and all that. So yeah, today we're tackling the issue of all things program. So if you're new to these webinars this is episode number five. So this is there's a few others you can catch up on that we've run previously. Tail end of 2025 and this is episode five. They're flying by and I'm joined today by David Allen and Ben Walker who will introduce themselves shortly. And I'm Glenn Hynes and I run GMH Planning and we're a specialist consultancy that focuses on EC NEC forms of contracts. We're providing training support to the industry. So today's webinar NEC4 program and getting it working for you, that's what we're going to be covering today. David, would you like to introduce yourself?

Thanks. Yep. Hi again, I'm David Allen, the executive director for Seeker Southern. I'm back for this first webinar of 2026. Blimey. Where did the last year go? Well obviously Ben and Glenn will provide an overview around the use of the NEC4 program and how that can actually support all engaged in the project. However, just as a reminder, Seeka Southern is just one part of a member led trade body trade association that represent organizations delivering and maintaining civil engineering infrastructure across the mainland uk. We're made up of six English regions, the two devolved nations of Scotland and Wales and we have an office in Westminster. We engage with governments clients and those bodies that influence industry outcomes and you can find more about that on our and our other activities on our website. But we do also deliver training including that around the NEC contract where we look to increase both awareness and to seek to promote the collaborative use of this tool. So please feel free to put any questions that you might have in the chat and no doubt either myself, Glenn or Ben will pick those up as we go through. But now I'll hand you over to Ben. Thank you.

Thank you very much David. Happy New Year everyone. Good afternoon. Today it's episode five and as Glenn and David have already said, we're going to look at the NEC4 program. Now this isn't a full in depth look at everything to do with the program and how to put it together and that kind of thing because it's a vast topic and no doubt will we'll take chunks of it over the next months and we'll present different bits on it. This episode is really focused about the importance of the program and getting that foundational understanding of what it's there for, and also some hints and practical tips around making it work for you, rather than being just a big admin duty that you have to do every month or more frequently, perhaps. So we're going to look at the accepted program and the importance of it and its life cycle. We'll touch on how to approach the update, submission and acceptance of the program and really look at two extremes. And we've been a little bit sort of, you know, try and paint those two extremes and hopefully you'll start to think, where am I? Where is my project on those on that scale and what can I do to move slightly further to the right? And you'll see that as we present that slide, we're going to look at the consequences of both acceptance and non acceptance, because accepting the programme has an impact and we want to explore that a little bit. And also, of course, not accepting it also has an impact. We're going to have a bit of a look at how to show compensation events on the programme. Glenn and I actually have slightly different view on this. I mean, broadly aligned, but there are some nuances to our thinking and perhaps a little bit of conversation around that should perhaps be helpful, not least to demonstrate some of the underlying dynamics of how to show things on the program and generate a bit of discussion. What I should say, actually, is that all of these webinars are not legal advice, so we encourage the questions. We can't answer anything from a legal point of view, but hopefully in the spirit of it being healthy to raise these conversations and explore these topics, we hope that'll be useful. Now, there's so many other things we could have picked on. We. We looked at the time we thought we had available and we think we've just about COVID how to show time risk allowance on a program, but there's a lot more to say about that. Of course, we could have covered key dates and all sorts of other activities, but we'll have a quick look at time risk allowance, since it's something that keeps coming up in how to present it in a kind of slick way. We'll draw some conclusions and as with every episode, we'll look at some common problems and solutions and then hand some time over to Q and A. So, oh, my favorite little thing to do. A bit of etymology. So this is Greek, I think, progression. So before and to write so later becoming programma, meaning public declaration. So that's where this one comes from, to write something out publicly. So what's the role then of the accepted program in the term service contract, we call it a plan and there is a little subtlety there, I think plan typically being where the operations on the program are a little more absolute, mutually exclusive. You don't have to, you know, if you can't cut the grass, then you empty the bins or whatever it might be. Whereas in a program we're looking for a little bit more dependency and sequential activity. So that's my understanding of what the distinction is. But both of them, whether you're in a program, a contract using a program or a contract using a plan under nec, they both are fairly familiar concepts in terms of NEC elevating them to being a central contract management mechanism. So that's fairly unique to nec. And the contract creates these ongoing obligations around the program. I know Glenn calls it the beating heart and I think we'll explore that a little bit more in a moment. And the contractor must keep this program up to date to reflect actual progress and the remaining operations and the effect that that progress really does have on those remaining operations. The program is submitted at maximum intervals and very much I think you'll see from what we're about to explore here. We would hope that would suggest that the more frequently the better, particularly in light of lots of change, which is unfortunate, but sometimes a reality. It's therefore different to other standard forms of contract in. In that NEC requires both parties to engage with programming as an active project management discipline rather than a kind of passive informational piece. It's not the case that you have a baseline program, then we forget about it. It's a much more contemporaneous document that is really necessary and there's plenty of indicators for that. We're going to unpack a few of them in order to make the rest of the procedures of the contract work. In particular the pursuit of NEC's prospective approach to change and risk specific. So the accepted programme is the contractors program formally accepted by the project manager. It must show the order and timing of the operations in order to provide the works, but also those of the. Of the client as well, float time, risk allowances, resources and other information. So it's a collection of documents, it's a bundle including method statements and all sorts of other things. It's not just a kind of pretty Gantt chart that we print out, it's a much richer set of documents. And again, definitely have a look at how to prepare a contract in The User Guides Volume 2 for more information on that as well. The project manager then has two weeks to accept or not accept a submitted program and new 20C4 silence is one of those occasions where it comes to the programme where you end up with a treated acceptance. So that's not everywhere, but this is one of the places where that now is also a feature. Compensation events are assessed against the accepted program, making its accuracy really critical to accurate assessment of change. And also we see a link with options, particularly option A, but also perhaps good practice C as well, where you'd hope that the operations on the program aligned with that sort of pricing documents. So all in all, there's a lot to say about this. You're going to take us through a few other examples on the next slide where the programme really sits in the centre of NEC's stimulus scope management, which is obviously one of their principles. Glenn, anything to add on this one?

No, obviously just picking up on the point you said, Ben, that there's only so much we can cover today. So that second bullet on the specifics talks about some of the things the program must show and you can just look at clause 31.2 to get the full, full list bulleted list of all the things that need to be shown in the Contraptus programme. Well, these are just some of the benefits and the reasons that NEC is steering us towards wanting a regular accepted program. And as we've alluded to, NEC does set itself out slightly differently. Most other forms of contract don't sort of formalise the requirement for a regular revision and even if it is revised, what the contractual status of it is less clear or in some cases non existent in other forms of contract. So NEC has got this much more regular discipline for acquiring a regularly revised programme and once accepted, making it clear that the accepted program supersedes the previous accepted program so you know what purpose it's actually serving and then the benefits of it. Some of them, not all of them, are listed here as to how the accepted programme helps in just so many ways on your project. For options A and C, the items on the activity schedule need to relate to items on the on the program. And particularly with option A, you can, if you cost load the program in line with the activity schedule, it's possible to actually do the application direct from the program, which is pretty neat and pretty slick and also means it's less likely for the application to be challenged because at the end of the day, if the amount's right and the item's done, there's very little to argue over whether the payment should be made or not. So particularly with option A, the program can actually Be used for the basis of the application for payment and with the other options B, C, D and E, it's going to help. Not you can't do the application straight for the programme, but nevertheless cost loading programs is a very useful benefit. It's not mandated you cost load programs, but it's very useful to do so. It helps your efficient planning for operations. So for procuring materials, for procuring resources, equipment interfacing, it helps your efficient planning of the job, allows you to forecast your defined cost right through to completion. So again if we cost loaded the program, even without thinking about doing applications for the program, your remaining cost profile forecast become just another part of of the program tool. And with the software and we are talking obviously one of the established planning software tools we're not suggesting use Excel for programs, hopefully everyone's aware of that anyway. Another key one is coordination with the client and others. So it is an obligation to show interfaces of the client and others and if they are then shown on the program, the client can see what they need to do in order for the contract program to be met as well.

So.

So that's very helpful. It's not just the contractors activities we're focusing on, it's other sort of third party interfaces as well. It also helps us explore delay or mitigation and looking at acceleration as well. So pulling back the completion date with a formal acceleration we can do that from the program. Early warning matters. We can do some what if scenarios. So if we were to do this, this is the possible impact same for compensation potentially as well. Sometimes there's a compensation event, alternative quotations asked for and there might be two different ways, two different solutions. We can explore these as like what if scenarios within the program progress reporting. So it allows us to show what we've actually done. So every time we're updating an issue in the program, we'll have a new day to date. Everything to the left of the day to date will be actualized and should be factual. Everything to the right is then the remaining activities to be done and the logic link should then ensure that that it's leading to the correct anticipated plan completion at any one point in time. Compensation EVENTS if you caught our last couple of webinars on compensation events, we've gone into a lot of detail on the compensation event process and part of that is using the program for that as well. So you are going to plug in compensation events into the accepted program to then demonstrate the impact on any key dates, any plan completions. So it's Going to help with the CE assessment and then finally cost value reconciliation, earned value analysis. Not specific NEC requirements, but good practice project management tools that may or may not be part of your scope requirements anyway. So this is just some of the things that the program is going to allow us to sort of manage and monitor. And it really comes back to NEC wanting the program to be a real management tool and that's what programme should be. I used to be a planner and a planning manager myself, so I've always had a real high level of importance and high level regard for the programme. I even hear some people saying sometimes, oh, we can't afford to do a program in terms of the cost of a planner to do a program. Well, my argument is you can't afford not to do a program benefits that it's going to bring.

I think that's the key, isn't it? It's not seeing this as extra admin. This is just project management good practice. There are some things that the contract is mandating and they're in that list on that slide. But there are other things that are good practice that contractors will be doing anyway. And you know, everyone's going to be doing a cost value reconciliation. Everyone is going to be efficiently planning their operations. They might not do it on the. You know, there might be a bit of tax planning or a bit of a rolling program as well, which may well be done in Excel. I've seen that. But. But in general what we're saying is don't treat this as an extra, just bring those things into this and yeah, follow what the contract's saying, but use them and make them work for you. So get it working for you rather than having it as an admin overhead.

Yeah, very much so. Very much so. So this is our life cycle of the program throughout the life of the contract. And with these webinars we're focusing on the ecc, but it's the same requirements with the professional service contract and the term service contract for task orders. Similar process, obviously the subcontract version. So a lot of the contracts do have this requirement for the program. So first of all, the first one can be included as part of contract data. Part two, now that is optional, it's not compulsory. We've written one of our seeker bulletins on why it is a good idea to always include a program within your tender submission from memory. That's bulletin number 49 if you want to have a read up on that. But it serves so many good purposes. If you as a contractor submit a programme as part of your tender submission, it shows you've understood the job, you've understood NEC requirements, you hit the ground running with your first accepted programme. So there's a lot of good reasons why you should be wanting to submit a programme as part of your tender return. But it's not compulsory and there's a lot to do at tender stage. We get that. But if you don't include one within your tender submission, then data part one will then state how quickly the first program has to be submitted within. And normally that's going to be within the first few weeks anyway. So if you don't do it at tender, you've got to do it very early on, and that's the time where things are very busy and you've got a lot to do. So if you can do the program as part of your tender submission, it's one less thing to have to worry about when you're live on the project. And then this program is going to be regularly revised as we progress through the project. And previously accepted programmes may be called upon to assess certain compensation events, but ultimately you are referring to, at any one point in time, the accepted programme, and it's a defined term under nec. And it tells us the accepted programme is the program either identified in contract data or the latest programme accepted by the project manager. And it goes on to say the latest program supersedes any previously accepted programmes, so there's no need to ever refer back to the original contract program. Even with NEC, a lot of people refer to the Clause 31 program as though it warrants its own name. I don't mind it, but it doesn't warrant its own name, because as soon as you have a revised programme accepted, that is the accepted programme, you don't really call on older programmes other than your own reviews, and maybe to assess an older compensation event. But ultimately we're only ever going to get back to the accepted programme, and NEC is very clear on that intent, makes it very clear that we only ever go back to the last accepted program. So when are we going to submit these programs? Well, ultimately, a contractor can submit a revised program whenever they want, so they could submit one if you've just submitted one and there's a major change in the program logic or a major compensation event or week later, you might want to update the program to show that sort of change, rather than wait until the next one is due. The project manager can instruct a revised programme whenever they want to see one, albeit the contractor's got the period for apply in which to produce it, so won't necessarily be submitted very quickly. But there is the opportunity for the project manager to insist on a revised programme at any point in time. But the backstop is the interval stated in Contract Data part one. So the client will be stating how often they want to see revised programmes submitted and almost always it's either going to be four weeks or every month. Typically those are the timescales we're going to see. So it means that normally maximum monthly there will be a revised program and the revised program brings us up to date in terms of what's gone on and how we're now planning to do things going forward. There are some sanctions. So if the project manager doesn't reply to a program submitted within two weeks, then the contractor may remind may put in a notification that they've not responded. Now you might query the word may there the reason NEC's put the word may it doesn't make it an obligation because otherwise the contractor's now in breach for not reminding them the client's not done something they should have done. So it does say maybe, but. But if you don't remind them then nothing happens as a contractor, so you've got to put that reminder in. But then if the reminder does go in and we're assuming hopefully you're using one of these established cloud based systems, then if they don't respond within a further week, the project manager then it is treated as being accepted, which is what Ben alluded to earlier. It's only program and compensation events where deemed acceptance really exists in nec. Generally they're not big fans of having deemed acceptances, but in those two instances it's it was felt so important that they did bring them in. So they only came in with NEC3 and NEC4 respectively. So NEC3 saw deemed acceptances with compensation events and NEC4 now sees deemed acceptances with program, but only where the project manager is staying silent. And if they're doing the job then it won't be an issue at all. On the first program if the contractor is not submitted one as part of contract, they depart to and not submitting one showing the information the contract requires live on the project, then 25% of the price work done to date, that is the cumulative application value can be retained until they do submit one that the project manager is able to accept. So it's only on the first program. But having said that, if you're three months into the job without an accepted programme, that will be 25% of three months money rather than 25% of the money applied for just in month three. And plus as well, if you're three months without an accepted program, you've got other bigger problems than just money being withheld. Because if you're starting to get compensation events on the project already, how are you going to assess change when you haven't even agreed the original baseline? So that's why NEC's view is we put this high sanction on the first programme. Because if you don't have your first program accepted, you're in an almighty mess, both parties, when it comes to assessing change. Anything to add, Ben?

Yeah, just a small point. Remember, it's the first program, if you don't have one in contract data, it must be submitted showing information required. So it doesn't have to be accepted to release that retention, that retained amounts, but it must show the information required and kind of otherwise be compliant. I was just thinking, Glenn, you triggered my mind when you said the program submitted whenever the contractor chooses to, as one of the three sort of things they can do. I think scenarios that might be helpful, like when might you do that? I think if you'd manage to pull off some brilliant progress and you created a really healthy terminal float between plan completion and the completion date, I think that'll probably be an occasion, would it not, when you would think to yourself, actually, I must submit a program, I want that recognized. I think that might be quite a useful thing to do.

Yeah, I think so. Having said that, I mean, if you've just submitted a program and a week later it could happen.

It's.

It won't happen loads of times that in that week you've suddenly had a miracle and something, but major changes in logic or. So, yeah, you could have an idea about a different procurement method or something. So yeah, in that regard that could automatically bring a sudden massive advancement. So, yeah, so changes in logic. Yeah, things like that.

I mean, one of the big things people argue about is concurrency of delay. And you know, if you've had that, if you, if you can maybe have more frequent programs, I guess that naturally kind of reduces the number of times you get that sort of circumstance. The other thing that I was thinking about was also when you have sort of early warnings about potential issues and potential delays, it's not a bad idea to refresh the program so you can go into those early warning meetings with a management tool that's actually speaking to reality and updating it for progress like that. But yeah, okay, let's move on to the next slide then, which is, you know, two ways which I think Glenn and I have observed over the years that people approach and update submission and acceptance well there was one thing I was going to draw on as well just to point that on the previous slide the interval isn't set by the drafters of the contract, it's set by the client, the procurers in contract data part one. So the minimum interval will very much depend on the context of the project. So if you're in a power station outage period or a railway possession where you're doing a lot of work in a short space of time, it might be that your programming interval is a day, you might have that very rapid submission and revision whereas if you're not having if it's a larger project and perhaps the scope is fairly sound and the site information is well known, a month might be sufficient. So the reason the authors didn't throughout contract specifying timings but there's certain types of timings that are left for a contract data entry much like the period for applies and that's really done intentionally so that the people putting the project together can think about what the best timing would be Another reason not to have copy and paste approach to your contract data preparation. So when it's a paint this scale on the left we've got, you know the let's parachute in a scheduler so P6 expert will come in and draw you a beautiful picture that you'll proudly print out on a color plotter and put on a naught as wallpaper in your office and within a couple of hours it's useless but we might leave it there for the whole month and point at it versus the other extreme which is, you know, building the program up and I've been on projects where both have happened and it won't surprise you that where we were updating the program twice daily from a whiteboard which had yesterday, today and tomorrow on it and by section what the different engineers were doing, what they worked and what they completed it meant we had a much better objective factual injections to where we actually are. So quick contrast those two things. If you if you're parachuting the scheduler in once a month you're probably struggling with getting the program accepted because it's more likely that it doesn't reflect the reality of progress. It might be a bit vague and the logic might be out of touch and it's probably also causing you friction which preparing payment applications could be not very explanatory of your of what you might be getting back is disallowed costs when you're, when you're putting those in for payment. And of course assessing compensation events, if the logic's flawed and straight away we're going to, you know, we're going to start to see those challenges come back. You're probably not using it for programming, you probably have a different document that you're using or a different workshop of some kind where your teams are doing the tactical planning and some of the strategic thinking. And it's probably not the go to document for you to start your CVRs and your earned value and all the rest of it. And so if that's the case, you're probably in the left hand group there and the contention is you probably want to be further to the right. So enabling a regular update from robust record keeping, giving you that real time event, objective measures of progress underpinned in records that also help your commercial payment side of things and then very crucially doing the review and update together. So NEC doesn't prescribe every composition conversation you're going to have. It just deals with the formal communications and some management bits which are compulsory like the early warning meetings and the upkeep of a register and what have you. But there's a lot it doesn't say that it anticipates you'll be doing from common sense project management. And it's sort of captured under the collaboration ethos. So, you know, reviewing it together seems eminently sensible so that we, because not all things will be equal on a given project, when we're looking down through that list of requirements that program should have, you know, are we really going to push for how many hand tools are used in 18 months time and argue that principal items of equipment or other resources, probably not. So, so where's the balance? And that will take compensation. And if we can align around how we're capturing progress and resources used, we can build that into the actuals. And in doing so we start to create those measured miles and those productivity insights that help us in the future with things like compensation assessments. It also creates that minimal latency for PMO which is going to maximize their opportunity for a positive intervention. And I'll take you right back to the first few episodes where the little speech bubble at the very start of those episodes was the quote from the late Dr. Martin Barnes where he was saying project management is about influencing what hasn't happened yet. Everything else is happening. You know, do we want to be project managing, do we want to be influenced in the future? So yeah, maybe just painting that picture there of the of the two extremes and I'm sure that, you know, most of the projects we're in will be somewhere in between. But I would be making the strong case that the right hand side is better because then this document is working for you. It's not an output that you create from a load of other stuff. It is itself a useful central project management document. What do you think Glenn?

Yeah, absolutely. I think I've already alluded to it. Some people say, oh, we can't afford a planner. And my argument is well you can't afford not to plan a job properly and that's what the program is going to be there for long. So, so whether it's a dedicated planner or a very good construction manager who can do it, someone needs to do it. And if you do have a dedicated planner, it takes the pressure off the people who would otherwise have to do it. And because it's not their day job, the planning software, they're not used to it. It takes them twice as long and then that's twice as long not doing other stuff they could be doing that's more their day job. It's a team effort. NEC is a team. There's people doing commercial aspects, partners planning aspects, operational aspects. It's all about the right team.

And the big bit for me on that team point, and you mentioned the site manager doing it, which is a really interesting point because I've for a long time felt that one of the really important practical things to do is close the gap between site and the project office. So because so much of NEC's procedures rely on good information about what's happening, particularly to get into the cost based contracts where, you know, you start to have those conversations around disallowed cost. So much of it is about where are the resources, what are they doing, how much progress have we made, how were we hindered, why were we stopped? Is it access, is it weather, is it physical conditions or is it equipment broke down? You know, if we capture that information at source and feed into the program and of course generally our records in general, then we've got the fuel, the oxygen that makes the contract procedures more, much more workable. And then if we are capturing that as a picture, it's a bit richer than a two dimensional picture, isn't it? We've already said there's method statements, resource allocation, that kind of thing, but we are, we really are sort of providing ourselves the, the oxygen we need then to operate those breathes life into those NEC processes. Anything else, this kind of sort of, you can Eat. It's perhaps not giving ourselves a fair chance at actually looking at it. There's a bit of top down strategy with this of course, because we still need a general strategic direction and make sure we're going to finish on time and take interventions as necessary. But I think that is quite often done relatively well. It's the ground up injection of reality that's sometimes lacking. So that's something. Okay, Glenn, I think you're going to take us through the consequences of acceptance.

Yeah, well, it's important to remember. So it's a verb and it's intentionally that NEC uses the word accept. So it's acceptance. So the project manager either accepts or does not accept the program. And really important to remember under 14.1 the project manager's acceptance does not change the contractor's responsibility to provide the works. So uses the word accept. So don't agree a program or don't approve a program, that's not the verb. And again, if we're using a cloud based system that should be hardwired in so you can't use the wrong word anyway. But it is acceptance. But it's important. I think sometimes project managers are reluctant to accept things because they're worried about the liability they're taking on. But 14.1 makes it clear that by accepting the program it doesn't change the contract responsibility to provide the work. So they're off the hook. If they've missed off of this chunk of works, we've missed off the program. Well, the scope still requires them to do it. So on the next program they'll have to show that. And the fact the project manager accepted the program without an S back to works doesn't change anything in terms of liability. But equally it's important to then think, don't think it's inconsequential so that, oh well, just accept the programme. It doesn't matter because Glenn said in that webinar it doesn't matter, I can just accept it. Well, there are consequences because. Because certain compensation events will refer to items on the accepted program. So the date for access, the client providing something like maybe free issue materials or a piece of design information or the work of the client or others. So if any of those elements are changed in a program and the project manager has accepted those, as long as they don't contradict anything else in the scope, like they've reduced acceptance periods down for 40 weeks, down to one week, as long as none of those have been done, then if they've accepted something earlier, maybe then they are accepting that. So there is meaning behind acceptance, but it doesn't mean liability taken on by the project manager. So with that in mind, it's helpful to highlight timings for work of access or others. So when you're submitting a revised program, I'm always talking about contractors. Make sure you submit a name narrative with each program you issue for acceptance. Highlight some of the key features, things that have changed since the last accepted programmes have major changes in logic, things like that. Highlight that. And yes, if there is deliverables from the client that the contractor needs in the next four to six weeks, highlight them. They might be suspicious if you're moving things around on a program. So if you're highlighting as a contractor while you're moving things, then it's going to help the understanding and speed up the process and hopefully increase the chance of getting an accepted programme and hopefully quicker as well.

Absolutely. It's got to make it more digestible, hasn't it? So if you're a brand new pm, this first job you've done on NEC and you get this huge program knowledge of 14.1, as you said Glenn, acceptance doesn't change a contractor's responsibilities is a really important thing to know to sort of quell some of that anxiety. But equally as you point out, well, you know, okay, but you can't just frivolously accept it. Don't forget as well, the client might be a little bit increasingly upset with a project manager who's missing obvious things. You know, the idea is you add some value if you can. It's just you're not taking any liability for it. But yeah, I think in particular that highlighting the bits that by accepting you are binding the activities of others or the client is very helpful as well as you say, to give that narrative to digest and should indeed hopefully improve the chances of acceptance. So yeah, some top tips there. And one of the things, one of the ways project managers, you can sort of set that out if you like is again the program other information. There's the scope requires. So I think the final bullet point there or near the bottom of the bullet points of operating requirements. And there's actually an entry in the how to write scope part of that codified suggested structure we quite often talk about in every episode. So volume two, preparing an ECC contract. I think it's chapter three, how to write Scope. So when it comes to program submissions, maybe put your extra requirements in there. Can I also please have a narrative that tells me how the activities of the client, including access and the Activities of others, how they've changed on your program, how your assumptions change. Good stuff. Okay, let's then look at the opposite of that and the consequences of non acceptance. So you're perhaps a brand new project manager. You're sat. You've just, you've got your 1200 line program arrived for the first time and it's very daunting and you're looking at it and thinking, oh, good grief, what do I do with this? And you're weighing up your options. Well, there's actually really only three options for non acceptance. The first option on this slide is to accept it. And I won't reiterate that because Glenn's just covered it. So we basically notify acceptance. It doesn't change the contractor's responsibilities, but might change yours. You might have to go back and think about the client's work and others. But there are three other options to you that I can think of. There might be some more. The second one is to be very upfront and notify non acceptance because you don't have the time to review it. I don't really think that's an option, but you know, it could feasibly happen. You've been very upfront. You said, I'm sorry, I can't accept this because I haven't got time to review it. Now. The trouble is with that is you've given your reason, which is important. If you withhold acceptance to something, you must give a reason, but the reason here is not one that you'll find in the contract. And therefore it will be a compensation event because you withheld an acceptance for a reason not in a contract. So that doesn't really get you anywhere. It just creates a bit more admin and things get a bit more complicated. The other option available to you or another option available to you is to notify non acceptance. Perhaps there's a bit of. There's an activity somewhere in sort of a year's time, which you think, I could do with a bit more resourcing on that. So, you know, make your own mind up whether that's, you know, a real reason, if you like. But if it comes under one of the reasons under the contract, then, you know, perhaps that is a reason you can give. So how far have we got there? Well, firstly, we've given a non acceptance, so we don't have an accepted program. We got a situation where we're saying there's something wrong with it. As a client, I'd be looking at the project team thinking, well, is this something you could have anticipated in a conversation and not wasted time submitting and withholding acceptance. So, you know, that's the first observation, but there's some other things quite often project managers miss. If you withhold acceptance to a program for a reason in the contract, then you automatically have to assess the compensation lengths for which there are good. So you're effectively having to reply to the quotations that are there to say, I'm sorry, I don't accept this quotation for a reason. For the reason that I'll be making my own assessment. Because I think it's clause 64.1 on the last bullet point. At the time, I hadn't accepted the program for a reason stated in the contract. So it's not a case of kicking the can down the road. Right. There's actually a significant consequence to withholding acceptance for a reason in the contract. You actually take on the duty of implementing those compensation loans and you also obviously have to make your own assessment of the program for the remaining work. Now, I suggest that's much better done with the contractor in advance of the submission rather than after with all these other duties. So there really is no kind of easy way out of this. We have to embrace it and kind of get on with it. The fourth option is to just stay quiet and hope for the best. And that's not an option either, really, is it? Because not replying is a compensation event. And as Glenn alluded to earlier with the sanctions, if that failure to reply persists and the contractor reminds you of that, then eventually it'll take you to option one anyway, which is, to all intents and purposes, it's treated as accepted. So you have a compensation event, you don't have a program for all the importance that adds and you end up with a treated acceptance anyway. So that really does only leave the kind of proactive option in my mind, unless you think of any others. Glenn, the project manager contractor let's share the records of what we've done and what we intend to do. Let's work together on it and update it regularly so that submission and acceptance can happen in a very short amount of time. Because we're aligned on it and it's recent. Yeah. Anything to add there?

No, I think you covered all the options, really, just to emphasize that it should be in neither party's interests to not want to have a programme accepted. There's no one's benefit. Oh, yeah, let's try an issue program that can't be accepted or from a project manager's perspective, let's Try and reject a program because they that's going to benefit us. It doesn't. All it, all it leads to is further dispute, which is conjecture, which is time and cost and it's just uncertainty. Neither party is going to understand their liability. If it's not good enough to accept, then fine, do not accept it and explain your reasons why you're not accepting it to allow the contractor then put that right. But both parties should be striving, as you said at the bottom there to make sure that we both get to an accepted program every period. That should be an achievable reality, not a pipe dream.

Yeah, absolutely. Okay. And Glen, I think you're going to take us through this slide. It generated quite a bit of interest. I did a post on this a while ago. Acceptable versus desirable.

Yeah. One of the key things is there's four reasons for not accepting a program and one of them isn't I don't like your end date. That's not one of the reasons. So planned completion being beyond the completion date is not a valid reason for not accepting the program. It could be that the contractor is running late because of something that is unavoidable and they are running late and they will be liable for delay damages. So by accepting the program doesn't mean you're accepting liability as a client, it just means well yeah, I'm accepting, that's the reality and they will be liable for damages. Or it could be that the reason for being late is due to a compensation event that might yet move the completion date. And once the CE is implemented then completion state can move and then it can hopefully for the contracts point of view at least do a catch up with planned completion. So it's not a case of I don't like what the program is showing me. That's not a reason to not be accepting the programme. So if it's realistic, it's practical, then it is acceptable if it complies with the scope. So much better to know the reality now rather than think that we're going to finish on time. We're going to finish on time. No we're not. We're going to be really late and that comes out too late. No one can manage those expectations and it then becomes a bigger problem. So don't hide bad news. Show the reality at any one point in time. Absolutely fundamental to the success of a project.

Yeah. And another reason to collaborate on the inputs for that update because if the, if the, if the building blocks your program, your progress updates, your, your measurement of actuals if, if those are already agreed with a smaller A between you, then the program update is going to be more realistic. And you know, one of the pressures that project managers and client teams put on contractors to kind of squeeze the program into a narrative that kind of suits, it's just so self defeating. You know, the whole point of this is to be effective in mitigating the delay, we need a realistic picture of what we currently got in front of us. And this is supposed to be that realistic picture. Good stuff. Okay, brief one on this because we want to save some time for questions, but Glenn and I have slightly different sort of take on this. So it'll be interesting in itself. But the bit we would agree on, I think Glenn, is that when you're showing what should you show on the program? So we can agree on that. And certainly you should show everything that you're doing on the program. So you should show what it says, all the operations in order to provide the works, the kind of important works of client and others that sort of play a part in that. And of course with each update you should show actual progress and its genuine impact on remaining operations. So we know we've got to show that. So if we've had a change to the scope, which even if it's not a compensation event yet, maybe it's a constraint, we don't feel it's compensated or the contractor thinks it is and blah blah, blah. The fact is, if there's been a clause 14.3 instruction or some other instruction or some other event, if it's affecting the works we have to provide or the timing around those works, we must show that on the program, it doesn't matter the status of the compensation. There was a tiny bit of confusion around this under NEC2, which I won't open up now, but there was a. It was. The only time I felt it was unclear was a little bit in NEC2, which kind of confused the meaning of implementation. But it's important to remember here that implementation of a compensation length really only means it's commercial finality with respect to a price change or a completion date or key date, sectional completion move. Everything else is already got to be on that program. So representing the contractors plans realistically and showing the actual progress achieved of all works, all things on the scope, in that most recent scope is important. So first thing I think we'd say is that you certainly wouldn't exclude things just because they're a compensation amount and not yet accepted with an accepted quotation or implemented. So that's the first thing, maybe some people have that misunderstanding. It's not the case. You must show everything. The kind of other bit then that we look at is how do you show it on the program? And you can see in this little program example there, we've labeled up one of the activities as PMI project management instruction number 27 corresponding to compensation met number 18. And I think this is the bit where, you know, I think Glenn favours this. I won't put words in your mouth, but you explain your view on it in terms of having a bit of clarity about being on a point at it. Personally, I'm. I'm a bit ambivalent about that post implementation. Pre implementation. I feel like although it, it doesn't interfere with the compensation mechanism, I think it might make people feel a little bit uneasy to accept a program that is annotated up as a compensation event before the quotation process has played out. So horses for courses, really. But I think you just at least be mindful. Personally, I would probably, I might mention a PMI because it might be relevant, but I definitely show the works. Whether I would identify which part of those works were related to a specific compensation event, I probably wouldn't. Pre implementation, I think what I do is I would include in my narrative, I would note that the current program submitted for acceptance is showing we're so many days late. But I fully anticipate as our compensation events are implemented we'll see that move back the right way around. But I can't get too excited about it. But I do feel like it's possibly one of the maybe unsaid issues that project managers feel concerned about accepting or program that's too heavily annotated. What's your view, Glenn?

Yeah, I think we're more or less aligned. The only bit is do we tag that bar, that second bar down as CE18? And I'm of the mindset, absolutely. This is about education. As long as the project manager understands that by accepting the program, we're not accepting liability for the ce. That's not the job of the accepted program. The CE process that we've covered in episodes three and four, that sorts out the time and cost implications of that compensation event. So I think this is just helpful to annotate this as project manager. PMI27, which has also been agreed as CE18, it's showing that that's the reason that plan completion is moving. So it's given everyone that visibility. I think that's helpful rather than a hindrance. And then once the CE is implemented, if it is implemented. Let's say that bar is two weeks long. Completion date can then move by two weeks. It's already in the program, it's already shown the impact against plan completion and then completion date can then move once the CE is implemented. So as long as everyone understands what they're accepting by accepting the program, how the CE process works, then there's no issues. It's just that lack of understanding that creates issues that shouldn't be there in more detail another time.

But yeah, well, we can have a big debate on that, which we won't do now. That's sort of the geeky debates we get into after a conference. Right, we'll spare everybody that. You're gonna just give us the, the best way to show time risk allowance on a program.

Yeah, just, just very briefly, we've got different types of float. You've got total flow, we've got time risk allowances, we've got terminal flow. So we cover those in other bulletins and we can cover those on other days. But. But just a little bit on just a time risk allowance. So traditionally I see it done three ways and we normally explore the three ways and then say, well, there's only one of them that really works fully. And I think, yeah, this is a topic in its, in its own debates that we could have a lot longer than we've got time to do today. But some people like to do a block of contingency at the end. I call that lip service not particularly helpful. It's easy. But whilst plan completion will be realistic, to achieve those individual durations is unrealistic. So you could argue that's actually a reason to not accept the program. So I'm not a fan. Even the guidance notes I think talked about time risk allowance should be against individual activities or small groups of activities. Not a big blob at the end. I also see sometimes people splitting out time risk allowance as a separate activity. So four day bar with a one day bar for time risk allowance that just doubled the number of activities on the program makes you more cumbersome. So sometimes simple is best. And all I would do on that second box down there with the green is just have your duration and then with the elements of time risk allowance within that duration just displayed that ticks the box. All time risk allowance is really there to do is to give the client a bit more comfort that that program is achievable and know that that program, the contract's got a little bit of risk built in. It's not extra risk that Other contracts don't allow you to have. Contractor should already have allowed for it. It was just never called time risk allowance. So very specifically, just having an individual column showing your tre value against individual items is the quickest, the cleanest, the slickest way of showing that. But yeah, I think it's really important.

To show it, isn't it? Because if you don't show it, then if it gets subsumed into float, you wouldn't include it in your float because that can be taken for compensation events, whereas time risk allowance cannot be. So it's important to keep that as a separate. Separate to float if you like.

And it's one of the. It's listed in 31.2. It's a specific item to be shown separately from float. So we have to show.

Absolutely. Okay, we could spend an hour just talking about that, but we are going to jump to conclusions. So in conclusion, the executive program is essential or management tool, not just a baseline information showing original intention. It requires contemporaneous updates, regular collaborative updates. We're advocating there based on structured commercial records that you're capturing on a regular basis to make submission and acceptance of that program faster but also to unlock many of the other procedures as blen's early slides shown with those activities orbiting the accepted programme hopefully get fewer disputes. Acceptable and desirable are different things. Don't fall into the trap of thinking that completion date is specified in the scope and therefore a program showing you that you're going to be late is not compliant with the scope. That's not true. Completion date is identified in the contract data and maintained in accordance with the conditions of contract. So going past completion date with planned completion is not contrary to the scope. So yeah, time risk allowance best identified in activity durations rather than as a lump sum at the end. It's protected when assessing compensation events and the contract incentivises both parties to engage. We have those motivators that NEC talks about. Sanctions for treated acceptances, retained price for work done to date, 25% which is a massive neon sign, isn't it, that says look, this is serious, invest in it. Think about how you're going to operate it. Compensation events, project management assessments and so on. So yeah, embrace it. Consider it early, work on it together, update it regularly. Get it to a point in my mind where you can submit and accept in the same 48 hours. Then the rest of it will work a little smoother. Common problems. We. We'll. We'll race through these, I think Glenn, because how many. Got any questions? Will Got two questions at the moment. Okay, go for it, Glenn.

Yeah, I'll pick a few of them off. So lip service paid to the program by both parties. So I think hopefully we're giving you enough reasons in this webinar to see why both parties should be wanting to fully utilize the program as, as it's intended. It should be a management tool for the contractor first and foremost and also a tool then to measure change against. Because if you haven't got that, how are you going to be assessing change? It's going to be subjective. That's going to increase the level of disputes you're going to have on your project, which neither party should be wanting. Missing information in particular resources. One of the things, you know, showing resource levels on a program, it talks about for each operation a statement of how the contractor plans do the work. Identifying principal equipment and resources. So ascertain what's principal equipment, what resources, agree what levels they should be. You can resource load programs. It's not mandated, but you can. Otherwise you've got to have words accompanying the program to demonstrate the resource levels. Again, that's a topic we can go into, into more detail. Annotating programs with compensation events. So we've talked in the, in the earlier webinars about. Yes, you do show non implemented compensation events on the program. It's absolutely fundamental because they could be impacting plan completion. My strong feeling is that it's very helpful to annotate those as a compensation event so both parties know and understand how and why plan completion is moving. It helps the CE be understood. But as we've said, except in the program with a CE already in the program does nothing to change the liability and the project manager is still within their rights to make their own assessment of the compensation. So as long as they understand that, then whether you label it as CE or not, then that doesn't matter anyway. But I think it's more helpful than harmful to do that. Ben, do you want to pick off the others?

Yeah, very briefly then. Program is out of date. Multiple ces since the last one. So this is a very, very typical problem and we were discussing this and we'll probably cover it in a bulletin at some point as well. You know, NEC is not designed for huge volumes of change. I don't, I think most people would agree with that if, if we, if we have huge volumes of change. Sorry, that's not quite true. If we can cope with large volumes of change if we keep the management mechanisms up to date. But it, but you know, I think the Real thing and probably be a subject of a. Of a future conference. Glenn is. If we can prepare it better, we won't have quite so much to deal with. But that's definitely a different topic. If we're in a situation where the scope is less than ideal or the site information is weak and we're finding things out as we go and it's a bit hand to mouth, then we get this abnormal amount of change, it becomes very difficult. If we're in that situation and it's too late to change that, then one of our best approaches is to keep the programme updated as regularly as possible. So keeping it updated and maybe dealing with a few CEs at a time between revisions is far better. The contract's perhaps not designed to deal with 100 compensation events on the one program which is three months old. Just to clarify what I meant earlier. Missing planned dates that pair with contract dates are really important if you've got key dates on your program. Contractors don't forget to show when you plan to meet the conditions for those key dates in the same way that you show the completion date and planned completion. That pairing of contractual deadline and reality, planned reality, if you're not there yet, creates that terminal flow which is preserved under clause 63.5. So really important point, always show the pairing too much or too little detail. You know, we shouldn't be guessing how much information is the right information if we're having those conversations. We should never really be in a situation where we're holding acceptance to programs because they don't show the information requiring a contract. Those conversations can and should be had. And again, if I was a client or a stakeholder and a contractor, and I was looking in project Admin and finding that there wasn't a regular program submission and acceptance based on withholding acceptance for things that we could have discussed that would trouble me and I'll be feeding that back to the project team. Okay, we need to try and stick to the programme, Glenn, and finish roughly on time. So I think we've got a couple of questions. Whilst you were talking through the one, I did have a quick look at this. Thank you, Gilmer, for your question. So he writes under NEC3.4. Could you please confirm whether the contractor's obligation to submit programs for acceptance continues until completion of the works? So yeah, it's in NEC4. It's. Where are we? I think it's 32.2, final bullet point. So the contractor submits revised programs for acceptance from the starting date until completion of the whole of the Works. The theory being, I guess when all the operations are complete and the whole of the work works are complete, then yeah, we've, we've tracked everything we need to. Anything to add on that one day?

No, I mean, yeah, once, once completion has, has been achieved after that there's not going to be too much. There might be def. There might be some defects to crop up. There might be obviously some, some. You're still doing some analysis of records for cost reimbursable contracts. So the, there's not going to be a whole lot to program in that period. And obviously the sanctions sort of, once you've achieved completion, a lot of the contractual sanctions and liabilities for insurances and things like that disappear. So I think there's going to be limited program requirements after that. But if there are major defects, hopefully not, then yeah, those should be programmed. And why wouldn't you want to get those on a programme and share them? Because it should be in everyone's interest to close these things out as quick as we can.

Yeah, thanks for your question, Gunmet. We have another one. What is your experience of instances where an accepted program includes reduced client periods compared to the contract and what the contractual consequences of both parties in terms of risk allocation, compensation and some reliance? So we're thinking there, possibly thinking there about, you know, maybe the contractor has more, less time to submit the program. Is that what we're saying? I think.

No, I think what they're saying is, so if the client said they want three weeks to accept design, for example, and the program shows one week and the program's been accepted, what does that now mean? And the answer is again coming Back to clause 14.1, the project manager is not taking on liability by not realizing, oh, I didn't see you'd reduce that timescale on line item 1004 of those 1200 items.

Program.

If the contract says they've got three weeks to review design, then they've still got three weeks. And if the accepted program says one week, even though that's been accepted, that does not change liability to the client.

But where the, where the scope doesn't give or the contract doesn't give a specific time frame and that's a bit at large, I guess we've got those compensation let's, haven't we? Is it number two, number five, I think, which talk about things that the client or others don't do within this time shown on the accepted program. So I think you need to consider both those things there.

Yeah, I mean, obviously. Well, if it's response times, then it shouldn't be less than the period for reply. So that would, that would come into play. But yeah, if it's free issue material and there was no restriction in the scope as to when the how long notice, then yeah, you right, Ben. They have to be more careful with things like that.

So I'd be mindful of conversation number two, three and five. But also a tickle ends point. If it's in the sort of hard in the contract, then those timings will apply. Okay, we've got one more. So we've overran on time, but we're gonna have a quick look at one more. So Jamie, thanks for your question. Do we. Do you have experience with the project manager and the contractor disagreeing over how durations for ces?

Oh, never. That never happens. They always agreed within minutes. Yeah, I mean that's the whole part of the CE process, just another part of the compensation process and I think we covered it in the quotation bullet seminar that we did a webinar even. And all contractors can do is justify the durations are right for the compensation then that they have put a sensible amount of risk and not excessive risk. And at the end of the day the project manager will then make their decision if they think that's right or not. But they've got to make sure that if they think it's less, then that may or may not go to formal dispute process, in which case an adjudicator might decide if that provision is correct or not.

And we've got a couple of other little things we can temper that with, haven't we? We've got project managers assumptions. So if we're really at loggerheads with, with a. With a risk allowance forecast and maybe we could turn it into a bit of a project manager's assumption, perhaps that would work. And don't forget as well, before we get to dispute, you've also got those senior representatives and get people involved and kind of talk these things out, I guess rather than just do it through the formal communication because that context and narrative you get face to face again talk together helps, but certainly it's an area of tension sometimes. Okay, we just need to. I've lost my slides. Just need to advertise the next webinar which is in the link. And could we. Thank you, Jamie. Could we remove Jamie's question just so that we can see the full slide? So episode six. We hope you'll join us. It's how to approach option Z and amendments because not all contract amendments are done through option Z. Some NEC customers have sort of copyright licence if you like, to the contract itself. So we'll look at both aspects of how amendments might be might manifest in nec. But option Z is, we typically know it. So we're going to be doing that at 4:30 same time on Monday 2nd February and we very much hope that you can join us. So I think that just leaves us to wish you once again Happy New Year. We might overrun by four minutes. We're getting better each time, Glenn.

We are, we're improving. Thanks everyone.

Thanks everyone. Bye bye.