NEC4: Programme - Getting it working for you

Good afternoon everyone and welcome to episode 5 of our webinar series. Happy New Year and all that. So yeah, today we're tackling the issue of all things programme. So if you're new to these webinars, this is episode number 5. There's a few others you can catch up on that we've run previously, tail end of 2025. And this is episode 5. They're flying by. And I'm joined today by David Allen and Ben Walker, who will introduce themselves shortly. And I'm Glen Hyde, 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 programme and getting it working for you. That's what we're going to be covering today. David, would you like to introduce yourself?

Thanks, Ben. Yeah, hi again, I'm David Allen, the Executive Director for SECA Southern. I'm back for this first webinar of 2026. Blimey, where did the last year go? Well, obviously Ben and Glen will provide an overview around the use of the NEC4 programme and how that can actually support all engaged in the project. However, just as a reminder, SECA Southern is just one part of a member-led trade body, trade association, that represents organizations delivering and maintaining civil engineering infrastructure across the mainland UK. We're made up of 6 English regions, the 2 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 I'm no doubt either myself, Glen, 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 is episode 5, and as Glen and David have already said, we're going to look at the NEC4 programme. Now, this isn't a full in-depth look at everything to do with the programme 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 programme 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 Programme and the importance of it, and its life cycle. We'll touch on how to approach the update submission and acceptance of the programme 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 thinking, well, 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. Glen 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 programme 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 just about COVID how to show time risk allowance on a programme, but there's a load 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 every— with every episode, we'll look at some common problems and solutions and then hand some time over to Q&A. So, oh, my favourite little thing to do, a bit of etymology. So this is Greek, I think, progrethen, so before and to write, so later becoming programme, 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 programme? 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 programme are a little more perhaps 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 programme we're looking for a little bit more dependency and sequential activities. So that's my understanding of what the distinction is. But both of them, whether you're in a programme, a contract using a programme 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 programme. I know Glen 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 programme 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 programme 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— or we 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 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 programme and 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. Specifics. So the accepted programme is the contractor's programme 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 chart that we print out. This is— 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 2 weeks to accept or not accept a submitted programme. And new to NEC4, silence is one of those occasions where it comes to 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 programme, 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 programme aligned with that pricing document. So all in all, there's a lot to say about this. Actually 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 Good Management, which is obviously one of their principles. Glen, 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 programme must show And you can just look at Clause 31.2 to get the full list, bulleted list, of all the things that need to be shown in the Contractor Programme. Well, these are just some of the, the benefits and the reasons that NEC is steering us towards wanting a regular accepted programme. And as we've alluded to, NEC does set itself out slightly differently. Most other forms of contracts 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's got this much more regular discipline for requiring a regularly revised programme, and once accepted, making it clear that the accepted programme supersedes the previous accepted programme, 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 programme, and particularly with Option A, you can— if you cost load the programme in line with the activity schedule, it's possible to actually do the application direct from the programme, 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 programme 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 programmes is a very useful benefit. It's not mandated, you cost load programmes, 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 programme, even without thinking about doing applications for the programme, your remaining cost profile forecasts become just another part of the, the programme tool. And with the software, and we are talking obviously one of the established planning software tools, we're not suggesting use Excel for programmes. 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 programme, the client can see what they need to do in order for the contractor's programme to be met as well. So that's very helpful. It's not just the contractor's 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 programme. 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 events potentially as well. Sometimes there's a compensation, 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 programme. Progress reporting, so it allows us to show what we've actually done. So every time we're updating an issue in the programme, we'll have a new date-to-date. Everything to the left of the date-to-date will be actualised and should be factual. Everything to the right is then the remaining activities to be done, and the logic link should then ensure 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, um, on, uh, the compensation process, and part of that is using the programme, um, for that as well. So you are going to plug in compensation events into the accepted programme to then demonstrate the impact on any key dates, any planned completions so it's going to help with the CE assessment. And then finally, cost-value reconciliation, earned value analysis— not specific NEC requirements, 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 programme is going to allow us to sort of manage and monitor, and it really comes back to NEC wanting the programme to be a real management tool. And that's what programmes 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 a high level of regard for the programme. I even hear some people saying sometimes, oh, we can't afford to do a programme in terms of the cost of a planner to do a programme. Well, my argument is you can't afford not to do a programme for the 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 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— there might be a bit of takt planning or a bit of a rolling programme as well, which may well be done in Excel. I've seen that. But in general, what we're saying is don't treat this as an extra. Just bring it, 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 lifecycle of the programme 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, for the programme. So first of all, the first one can be included as part of Contract Data Part 2. 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 programme 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 1 will then state how quickly the first programme 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 programme 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 programme 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 programme either identified in contract data or the latest programme accepted by the project manager. And it goes on to say the latest programme supersedes any previous accepted programmes. So there's no need to ever refer back to the original contract programme. Even with NEC, a lot of people refer to the Clause 31 programme 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, and 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 programme. So when are we going to submit these programmes? Well, ultimately, a contractor can submit a revised programme whenever they want. So they could submit one. If you've just submitted one and there's a major change in the programme logic or a major compensation event a week later, you might want to update the programme 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 a period for reply 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 1. So the client will be stating how often they want to see revised programmes submitted, and almost always it's either going to be 4 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 programme, and the revised programme 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 programme submitted within 2 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, 'cause 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 may, 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 programme 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 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 programme, but only where the project manager is staying silent. And if they're doing their job, then it won't be an issue at all. On the first programme, if the contractor's not submitted one as part of Contract Data Part 2 and not submitted one showing the information the contract requires live on the project, then 25% of the price work done to date, i.e., 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 programme But having said that, if you're 3 months into the job without an accepted programme, that will be 25% of 3 months' money rather than 25% of the money applied for just in month 3. And plus as well, if you're 3 months without an accepted programme, 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 programme 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 programme, if you don't have all-in-contract data, it must be submitted showing the information required. So it doesn't have to be accepted to release that retention, that retained amount, but it must show the information required and kind of otherwise be compliant. I was just thinking, Glen, you triggered my mind when you said the programme is submitted whenever the Contractor chooses to, is one of the 3 sort of things they can do. I was thinking of scenarios that might be helpful, like when might you do that? I think if you'd managed to pull off some brilliant progress and you created a really healthy terminal float between planned completion and the completion date, I think that'll probably be an occasion, would it not, when you would think to yourself, actually, I want to submit a program, I want that recognized. Um, 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 regards, 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 I, 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, the number of times you get that sort of circumstance. The other thing that I, I was thinking about was was also when you have sort of early warnings about potential issues and potential delays, it's not a bad idea to refresh the programme so you can go into those early warning meetings with a management tool that's actually speaking to reality and updating the progress like that. But yeah, yeah, um, okay, uh, let's, let's move on to, uh, the next slide then, which is, uh, you know, two ways which I think Glen and I have observed over the years that people approach an 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 1. 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 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 it's the reason the authors didn't, throughout the contract, specify timings but there's certain types of timings that are left for a contract data entry, much like the period for replies. 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 I wanted to paint this scale. On the left we've got you know, the let's parachute in a scheduler, so a P6 expert will come in and draw you a beautiful picture that you'll proudly print out on a colour plotter and put on A0 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 programme up and 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 what— and by section, what the different engineers were doing, what they'd worked, and what they completed, it meant we had much better objective factual injections to where we actually are. Quick contrast, those two things. If you're parachuting the scheduler in once a month, you're probably struggling with getting the programme accepted because there'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 with preparing payment applications. Could be not very explanatory of what you've you might be getting back is disallowed costs when you're putting those in for payment. And of course assessing compensation amounts, if the logic's flawed then straight away 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 in a different workshop of some kind where your teams are doing the tactical planning and and some of the strategic thinking, and it's probably not a 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, you know, 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 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 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 a programme should have, you know, are we really going to push for how many hand tools are used in 18 months' time and argue they're principal items of equipment or other resources? Probably not. So, so where's the balance? And that will take conversation. 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. Do we want to be project managing? Do we want to be influencing the future? So yeah, maybe just painting that picture there of the two extremes, and I'm sure that 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, Glen?

Yeah, absolutely. You know, I think I've already alluded to it. Some people say, oh, we can't afford, 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 programme is going to be there for. 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, is a, is a team. There's people doing commercial aspects, 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, which I think it was 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 hindered? Why were we stopped? Is it access? Is it weather? Is it physical conditions? Or is it the equipment broke down? You know, if we capture that information at source and feed it into the programme, and of course generally our records in general, then we've got the fuel, the oxygen that makes the contract procedures 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 want I've already said there's method statements, resource allocation, that kind of thing. But we are, we really are sort of providing ourselves the oxygen we need then to operate those, that breathes life into those NEC processes. Anything else is kind of sort of, it's perhaps not giving ourselves a fair chance at actually looking at it. There's a bit of top-down strategy with this, 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 bit 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 NEC uses the word accept, so it's acceptance. So the project manager either accepts or does not accept the, the programme. 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 it uses the word accept. So don't agree a programme or don't approve a programme— 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 programme, it doesn't change the contractor's responsibility to provide the work. So they're not off the hook if they've missed off— of this chunk of works we've missed off the programme. Well, the scope still requires them to do it, so on the next programme they'll have to show that. And the fact the project manager accepted the programme without an aspect of work 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 program, it doesn't matter because Glenn said in that webinar it doesn't matter, I can just accept it. Well, there are consequences 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 or a piece of design information, or the work of the client or others. So if any of those elements are changed in a programme 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 from 4 weeks down to 1 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, 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 programme, I'm always talking about contractors, make sure you submit a narrative with each programme 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 like that. And yes, if there is deliverables from the client that the contractor needs in the next 4 to 6 weeks, highlight them. They might be suspicious if you're moving things around on a programme. So if you're highlighting as a contractor why 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, first job you've done on NEC, and you get this huge programme, knowledge of 14.1, as you said, Glen, 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 the 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 to, as you say, to give that narrative to digest, um, and, 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 programme, other information the scope requires. So I think the final bullet point there, or near the bottom of the bullet points of programme 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 2, Preparing an ECC Contract, I think it's Chapter 3, How to Write Scope. So when it comes to programme 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 have changed on your programme, how your assumptions have changed? 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 got just— you've got your 1,200-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 3 options for non-acceptance. The first option on this slide is to accept it, and I won't reiterate that because Glen'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 3 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've 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 the 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, ah, I could do with a bit more resourcing on that. So make your own mind up whether that's a real reason, if you like. But if it comes under one of the reasons under the contract, then 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 programme. We've 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 programme for reason in the contract, then you automatically have to assess the compensation events for which there are quotations. 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, uh, for the reason that I'll be making my own assessment, uh, because I think it's Clause 64.1 and the last bullet point, um, uh, at the time at the time I hadn't accepted the programme for a reason stated in the contract. So it's not a case of kicking the can down the road, right? It's actually a significant consequence to withholding acceptance for a reason in the contract. You actually take on the duty of implementing those compensation plans, and you also obviously have to make your own assessment of the programme for the remaining work. Now, I suggest that's much better done with 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 Glen 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 1 anyway, which is, to all intents and purposes, it's treated as accepted. So you have a compensation event, you don't have a programme for all the importance that adds, and you end up with a deemed acceptance anyway. So that really does only leave the kind of proactive option in my mind, unless you can think of any others, Glen, that the project manager, contractor, you know, let's share the records of what we've 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, Blair?

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 program accepted. There's no one's benefit. Oh yeah, let's try an issue programme that can't be accepted. Or from a project manager's perspective, let's try and reject a programme because that's going to benefit us. It doesn't. 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 to 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 programme 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 4 reasons for not accepting a programme, 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 programme. 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 programme 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 date can move and then it can hopefully, for the contractor's 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 programme is showing me. That's not a reason to not be accepting the programme. So if it's realistic, it's practicable, 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 building blocks of your programme, your progress updates, your measurement of actuals, if those are already agreed with a small 'a' between you, then the programme 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 programme into a narrative that, that kind of suits— it's just so self-defeating. You know, the whole point of this is to, 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 the 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 is compensatable, 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 programme. It doesn't matter the status of the compensation. There was a tiny bit of confusion around this under an EC2, 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 event really only means its commercial finality with respect to a price change or a completion date or key date or sectional completion move. Everything else has already got to be on that programme. So representing the contractor's 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 in compensation 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 programme? And you can see in this little programme example there, we've labelled up one of the activities as PMI Project Management Instruction number 27, corresponding to Compensation Map number 18. And I think this is the bit where, you know, I think Glen 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 point at it. Personally, I'm a bit ambivalent about that post-implementation pre-implementation, I feel like although it, 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 processes has played out. Um, so horses for courses, really. Um, but I think you just at least be mindful. Personally, I would probably— I might mention the PMI because it might be relevant, but I, 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'd do is I would include in my narrative, I would note that the current programme 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 a programme that's too heavily annotated. What's your view, Glen?

Yeah, I think we're more or less aligned. The only bit is, do we tag that bar, that second bar down as CEAT? And I'm of the mindset, Absolutely. This is about education. As long as the project manager understands that by accepting the programme, we're not accepting liability for the CE, that's not the job of the accepted programme. The CE process that we've covered in episodes 3 and 4, that sorts out the time and cost implications of that compensation. So I think this is just helpful to annotate this as project manager PMI 27, which has also been agreed as CE number 18, it's showing that that's the reason that planned completion is, is moving. So it's given everyone that visibility. I think that's helpful rather than, rather than a hindrance. And then once the CE is implemented, if it is implemented, let's say that bar is 2 weeks long, completion date can then move by 2 weeks. It's already in the programme, it's already shown the impact against planned 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. Um, it's just that lack of understanding that creates issues that shouldn't be there. But I think that 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. Uh, you're going to just give us the, the best way to show time risk allowance on a Yeah, just, just very briefly, we've got different types of float.

You've got total float, we've got time risk allowances, we've got terminal float. So we cover those in other bulletins and we can cover those on other days, but just a little bit on just a time risk allowance. So traditionally I see it done 3 ways, and we normally explore the 3 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 own debate that we could have a lot longer than we've got time to do today. But some people like to block a contingency at the end. I call that lip service, not particularly helpful. It's easy, but whilst planned completion will be realistic, to achieve those individual durations is unrealistic. So you could argue that's actually a reason to not accept the programme. 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 4-day bar with a 1-day bar for time risk allowance. That just doubled the number of activities on the program, makes it 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 programme is achievable and know that that programme, the contractor'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 TRL 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 floats, so we have to show it.

Absolutely. Okay, we could spend an hour just talking about that, but we are going to jump to conclusions. So in conclusion, the accepted programme is a central 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 programme faster, but also to unlock many of the other procedures, as Glen's early slides showed, 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 the therefore a programme 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 incentivizes 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? It 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'll race through these I think, Glen, because we'll work— have we got any questions, Will? Got 2 questions at the moment, okay. Go for it, Matt.

Yeah, I'll pick a few of them off. So lip service paid to the programme 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 utilise the programme as, as it's intended. It should be a management tool for the contractor first and foremost, and also a tool then to measure the 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 programme, it talks about for each operation a statement of how the contractor plans to 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 programmes It's not mandated, but you can. Otherwise, you've got to have words accompanying the programme to demonstrate the resource levels. Again, that's a topic we can go into, into more detail. Annotating programmes with compensation events. So we've talked in the, in the earlier webinars about, yes, you do show non-implemented compensation events on the programme. 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 programme with a CE already in the programme, does nothing to change the liability, and the project manager is still within their rights to make their own assessment of the compensation event. So as long as they understand that, then whether you label it a 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 kick off the others?

Yeah, very briefly then. Programme 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 think most people would agree with that. If we have huge volumes of change— sorry, that's not quite true. We can cope with large volumes of change if we keep the management mechanisms up to date. But, you know, I think the real thing will probably be a subject 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 programme which is 3 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 programme, 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 float, which is preserved under Clause 63.5. So a 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 withholding acceptance to programmes because they don't show the information required in the 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'd be feeding that back to the project team. Okay, we need to try and stick to the program plan 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 NEC 3.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 NEC 4. It's, uh, where I think it's 32.2, final bullet point. So the Contractor submits revised programmes 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 works are complete, then yeah, we've tracked everything we need to. Anything to add on that one, Ben?

No, I mean, yeah, once completion has been achieved, after that there's not going to be too much. There might be some defects to crop up, there might be obviously some— you're still doing some analysis of records for cost reimbursable contracts, so there's not going to be a whole lot to programme 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 disappears. So I think there's going to be limited programme 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, government. Um, we have another one. Uh, what is your experience of instances where an accepted programme 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 programme. Is that what we're saying?

I think, no, I think what they're saying is, so if the client said they want 3 weeks to accept design, for example, and the programme should chosen 1 week and the programme has been accepted, what does that now mean? And the answer is, again, coming back to Clause 14.1, the project manager has not taken on liability by not realising, oh, I didn't see you reduce that timescale on line item 1004 of those 1,200 items to programme. If the contract says they've got 3 weeks to review design, then they've still got 3 weeks. And if the accepted programme says 1 week, even though that's been accepted, that does not change liability to the client.

But 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, where we've got those compensation rights, haven't we? Is it number 2, number 5, 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— but that would come into play. But yeah, if it's free issue material and there was no restriction in the scope as to when, how long notice, then yeah, you're right, Ben, they'd have to be more careful with things like that.

So I'd be mindful of, um, compensation notes number 2, 3, and 5, um, but also a particular endpoint, if it's in the contract, sort of hard in the contract, then those timings will apply. Okay, we've got one more. So we've overrun on time, but we're gonna have a quick look at one more. So Jamie, thanks for your question. Do you have experience with the project manager and the contractor disagreeing over how durations for CEs are measured?

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 of the compensation event process. And I think we covered it in the quotation seminar that we did, a webinar even. And all contractors can do is justify the durations are right for the compensation event, 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.

We've got a couple of other little things we can temper that with, haven't we? We've got project manager's assumptions, so if we're really at loggerheads with a risk allowance forecast, then maybe we could turn it into a bit of a project manager's assumption perhaps. I think 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, talking together, helps. But certainly it's an area of tension sometimes. Okay, we just need to— I've lost my slides. I 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 6, 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 license, if you like, to the contract itself. So we'll look at both aspects of how amendments might manifest in NEC, but Option Z as we typically know it. So we're going to be doing that at 4:30, same time on Monday, the 2nd of 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've overrun by 4 minutes, we're getting better each time, Glenn.

Yeah, we're improving. Thanks everyone.

Thanks everyone. Bye-bye.