Making The Accepted Programme Work For You Under NEC4

A schedule on the wall won’t run your project. A living, accepted NEC4 programme will. We unpack how to turn the programme into a central management tool that reflects reality, accelerates decisions, and shrinks the space where disputes grow. From acceptance rules and deemed acceptance to resource clarity and client interfaces, we walk through the mechanics that make NEC’s prospective approach to change actually work on site.

We dig into the lifecycle from tender to completion, why monthly (or faster) updates matter, and how to structure submissions so acceptance becomes routine rather than a negotiation. You’ll hear a clear breakdown of the consequences of acceptance and non‑acceptance, including when withholding triggers extra duties and how silence can lead to treated acceptance. We also tackle a frequent flashpoint: programmes that show planned completion beyond the completion date. You’ll learn why that can still be acceptable, how to separate acceptable from desirable, and how a realistic plan helps mitigation more than a neat fiction ever could.

On change, we show how to represent compensation events on the programme before implementation without conceding liability, supported by a concise narrative that explains cause and impact. We compare approaches to time risk allowance and make the case for embedding TRA within activity durations while distinguishing it clearly from float to comply with NEC4 and protect assessments. Rounding out the guide, we share pragmatic fixes for common blockers: missing resource statements, out‑of‑date logic, unpaired planned and contract dates, and overcomplicated models that stall acceptance.

If you want fewer surprises, stronger CE assessments, cleaner payments under Options A and C, and faster decisions across the board, this is your playbook for making the NEC4 programme work for you. Subscribe, share with your team, and tell us: what’s the one programme habit you’ll change this week?

View the webinar: https://www.gatherinsights.com/en/webinars
Join the LinkedIn Group: https://www.linkedin.com/groups/2893228/

Transcript

Welcome And Introductions

SPEAKER_02 0:11

Good afternoon, everyone, and welcome to episode five of our webinar series. Happy New Year and all that. So uh yeah, today we're tackling the issue of all things program. So if you're new to these webinars, uh this is episode number five. So there's uh 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 my I'm Glenn Hines, 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?

SPEAKER_00 1:01

Thanks, Glenn. Ben, yeah. Hi again. I'm David Allen, the Executive Director for Seeker Southern. I'm back for this first webinar of 2026. Limey, 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, Seeker Southern is just one part of a member-led trade body, a trade association that represents organisations 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 I 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.

NEC4 Accepted Programme: Role And Requirements

SPEAKER_01 2:20

Thank you very much, David. Uh happy new year, everyone. Good afternoon. Uh today is episode five, and as uh Glenn and David already said, we're going to look at the NEC4 program. Now, this isn't a full in-depth look at uh everything to do with the program and how to put it together on that kind of thing, because it's a vast topic, and no doubt we'll 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, uh, and also some hints and practical tips around making it work for you rather than being uh just the big admin duty that you have to do every month, uh, or more frequently perhaps. So we're gonna look at the uh in 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 the two extremes. And we've been a little bit sort of uh uh you know, try and paint those two extremes, and hopefully you'll you'll start to think, 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 gonna look at the consequences of both acceptance and non-acceptance, because uh accepting the program 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 gonna have a bit of a look a look at how to show compensation events on the program. Glenn and I actually have a slightly different view on this, I mean, broadly aligned, but there are some nuances to our thinking, uh, and and perhaps a little bit of conversation around that should perhaps be helpful, uh, not least to demonstrate some of the underlying uh dynamics of how to show things on a program and generate a bit of discussion. What I should say actually is is uh that uh all of these webinars are not legal advice, so we encourage the questions. We 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, uh, we we hope that'll be useful. Now, there's so many other things we could have picked on. We we we looked at the time we thought we had available, and we think we'd just about cover how to show time risk allowance on a program, 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 uh in how to present it in a kind of uh slick way. We'll draw some conclusions and as every ever with every episode, we'll look at some common problems and solutions and then hand some time over to QA. Uh so oh, my favorite little thing to do a bit of etymology. So uh this is Greek, I think, progressin. Uh so before and to write. So uh later becomes programmer, meaning public declaration. So that's where this one comes from to write something out publicly. So uh, what's the role then of the accepted program? Uh in in the term service contract we call it the plan, and there is a little subtlety there. I think plan typically being where the operations on the program 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 program, we're 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 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 a 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 actual progress really does have on those remaining operations. The program is submitted at maximum intervals, and uh very much I think you'll see from what we're about to explore here, uh, we would hope that we 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 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 and then we forget about it. It's a much more contemporaneous document that is really necessary, and there's plenty of indicators for that, and 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 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 client as well. Float, tight 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. So it's not just a kind of pretty gamp 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 in the um uh user guides volume two for more information on that as well. The project manager then has two weeks to accept or not accept a submitted program. And new to an EC4, silence is one of those occasions where it comes to the program where you end up with a treated acceptance. So uh that's not everywhere, but this is one of the places where that now uh is also a feature. Compensation amounts are uh 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 pro with the sort of pricing documents. So, all in all, there's a lot to say about this. Glenn, anything to add on this one?

Why Regular Acceptance Matters

SPEAKER_02 8:46

No, I'll be 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 list, bulleted list of all the things that need to be shown in the CHAPTER program. 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 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 contracts. So NEC's got this much more regular discipline for acquiring a regularly revised program, and once accepted, making it clear that the accepted program supersedes uh the previous accepted program. So you know what purpose it's actually serving. And then if the benefits of it, some of them, not all of them, are listed here as to how the accepted program 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 um 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 program, 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 uh 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 with the program, your remaining cost profile forecasts become just another part of the program tool. And with the software, and we are talking obviously one of the established planning software tools, uh, we're not suggesting you use Excel for programs. Hopefully everyone's uh 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 contractor's program to be met as well. So that's very helpful. It's not just the contractor's activities, we're focusing on its 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 events 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 data date. Everything to the left of the data 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 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, earn value analysis, not specific NEC requirements, good, 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 want in the program to be a real management tool. And that's what program 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 program. 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 uh do a program for the benefits that it's going to bring.

SPEAKER_01 13:51

Yeah, I think that's the key thing, 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 there in that uh uh that list in that on that slide, but there are other things that are good practice that contractors will be doing anyway. And you know, I I can't everyone's gonna be doing a cost value reconciliation, everyone is gonna be efficiently planning their operations. They might not do it on the on our, you know, there might be a bit attacked planning or a bit of a rolling program as well, which may well be done in Excel. Um, I've seen that. But uh in in general, what we're saying is don't treat this as an extra, just bring it, bring those things into this. Um and yeah, follow what the contract's saying, but 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.

Submitting, Updating, And Acceptance Windows

SPEAKER_02 14:43

Very much so. So this is uh our life cycle of the programs 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 uh 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 uh program within your your tender submission. From memory, that's bulletin number 49 if you want to have a read up on that. But it it serves so many good purposes. If you, as a contractor, submit a program 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 program. So there's a lot of good reasons why you should be wanting to submit a program 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 gonna 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 a 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 programs may be called upon to assess certain compensation events, but ultimately you are referring to at any one point in time the accepted program. And it's a defined term under an EC, and it tells us the accepted program is the program either identified in contract data or the latest program accepted by the project manager, and it goes on to say the latest program supersedes any previous accepted programs. 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 program accepted, that is the accepted program, and you don't really call on older programs 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 program. 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 a 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 program whenever they want to see one, albeit the contract's got the period for reply in which to produce it. So it won't necessarily be submitted very quickly, but there is the opportunity for the project manager to insist on a revised program 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 programs 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 contractors now in breach have not reminded 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 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 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 contract has not submitted one as part of contract data part two and not submitting one, showing the information the contract requires live on the project, then 25% of the price work done today, i.e. the cumulative application value. 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 three months into the job without an accepted program, 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 rates 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'll put this high sanction on the first program 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 then?

SPEAKER_01 20:48

Yeah just a small point remember it's it's the first program 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 amounts, but it it must show the information required and kind of otherwise be compliant. I was just thinking Glenn you triggered my mind when you said um these the programs are submitted whenever the contractor chooses to is one of the three 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 if you'd managed to pull off some some brilliant you know progress and you created a really healthy terminal float between planned completion 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 recognised. I think that might be quite a useful thing to do.

SPEAKER_02 21:39

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 all automatically bring a sudden massive advancement. So yeah so changes in logic yeah things like that.

Lifecycle From Tender To Completion

SPEAKER_01 22:05

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 uh reduces the uh the the number of times you get that sort of circumstance the other thing that I I was thinking about was was on on the 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. But yeah okay let's 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 uh an update submission and acceptance well there was one thing I was going to draw draw on as well just to point that that on the previous slide the interval isn't set by the drafters of the contract it's set by the the client the procurers in contract data part one so the minimal interval will very much depend on the context of the project. So if you if you're in a 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 you your program programming interval is is a day you know you might have that very rapid uh submission and revision. Whereas if you're not having if it's a if it's a larger project and perhaps there's the the the scope is fairly sound and the and the site information is well known you you know a month might be sufficient. So it's the reason the authors didn't throw out contract specifying timings, but there's certain types of timings that are left for a contract data entry much like the period for applies uh and 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 we're going to take 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 null as wallpaper in your office within a couple of hours it's useless but we might leave it there for the whole point at it versus the the other extreme which is you know building the the program up and I've been on projects where both have happened and 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 bisection what the different engineers were doing what they'd worked and what they completed it meant we had a 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 there's more likely that it doesn't reflect the reality of progress it might be a bit vague and the and the logic might be out of touch and it's it's probably also causing you friction with preparing payment applications could be not very uh explanatory of 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 then straight away we're gonna we you know we're gonna 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 or a different workshop of some kind where your teams are doing the tactical planning and and some of the strategic thinking and and it's probably not a go-to document for you to start your C VRs and your earn value and all the rest of it. And so if if that's the case that you're probably in in a 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 your commercial payment side of things make 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 the uh upkeep of a register and what have you but uh there's a lot it doesn't say that it anticipates you'll you'll be doing from 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 we because not all things will be equal on a given project when we're looking down through that list of requirements that the program should have you know are we really going to push for how many how tools are used in 18 months' time and argue they're principal items of equipment or other resources? Probably not so where's the balance and that will take conversation. And if we can align around how we're capturing uh 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 conversational assessments. It also creates that minimal latency for PMO which is going to maximize their opportunity for a positive intervention. And I 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 or we 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 I'm sure that you know most of the projects we're in will be somewhere in between but I would be making a strong case that the right hand side is better because then this document is working for you. It's not an output you create from a load of other stuff it is itself a useful central project management document. What do you think Len?

SPEAKER_02 28:19

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 program is going to be there for. So whether it's a dedicated planner or a 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 for 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.

Sanctions, Deemed Acceptance, And Incentives

SPEAKER_01 28:52

NEC is a is a is a team there's people doing commercial aspects planning aspects operational aspects it's all about the right team and and the big bit for me on that team point that you mentioned the site site manager doing it which which which 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 as you 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 the equipment broke down? You know if we capture that information at source and feed it into the program 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 the 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 the oxygen we need then to operate those, to breathe life into those NEC processes. Anything else is kind of sort of uh it it it it's it's 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 and take interventions as necessary but I think that bit's quite often done relatively well. It's the it's the ground up injection of reality that's sometimes lacking. So that's that's some thinking. Okay.

SPEAKER_02 30:41

Glenn I think you're gonna take us through the the consequences of acceptance yeah well it's it's important to remember so it's a verb and it's intentionally then NEC uses the word accept. So it's acceptance. So the project manager either accepts or does not accept the the program and really important to remember under 14.1 the project manager's acceptance does not change the good tractor's responsibility to provide the works. So it 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 use it in 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 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 that the project manager accepts the program without respect 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 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 conversation 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's accepted those, as long as they don't contradict anything that else in the scope like they reduced acceptance periods down from four 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 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 sort of 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 narrative with each program you issue for acceptance. Highlight some of the key features things that have changed since the last accepted programs 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 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 program and hopefully quicker as well.

Two Extremes: Wallpaper Plan Vs Live Tool

SPEAKER_01 33:26

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 program knowledge of 14.1 uh 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 famously accept it don't forget as well the client might be uh uh 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 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 and and should indeed hopefully improve the chances of acceptance. So yeah some top tips there and uh one of the things one of the ways project managers you can sort of set that out if you like is again the program your other information there's the scope requires so I think the final bullet point there or near the bottom of the bullet points of program requirements and there's actually an entry in in the how to write scope part of that codified suggested structure we quite often talk about in every episode. So volume two preparing a an ECC contract things chapter three how to write scope so where 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 uh how they've changed on your program what your 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 a 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 that 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'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 for 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 and and you know 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 the 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 a a you know a real reason if you like but if it's 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'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 program for a 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 for 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 at the time I hadn't accepted the program for a reason stated in the contract. So it's not a case of kicking a 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 of implementing those compensation laws. 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 deemed a treated acceptance anyway. So that really does only leave the kind of proactive option in my mind unless you can think of any others Glenn that the project manager contractor you know 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 and anything to add there Glenn?

SPEAKER_02 39:16

No I think you covered all the options really and just 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 program that can't be accepted or from a project manager's perspective let's try and reject a program because 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 programme every period That should be uh an achievable reality, not a pipe tree.

SPEAKER_01 40:06

Yeah, absolutely. Um okay, and Glennus, I think you're gonna take us through this slide. It it generated quite a bit of interest. I did a post on this a while ago. Acceptable versus desirable.

SPEAKER_02 40:19

Yeah, well, one of the key things is to 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 plan 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 delayed 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 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 program is showing me. That's not a reason to not be accepting the program. 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 oh, we're gonna finish on time, we're gonna finish on time, no, we're not, we're gonna 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 one point in time. Absolutely fundamental to the success of a project.

Site Records, Collaboration, And Reality

SPEAKER_01 41:45

Yeah, and another reason to collaborate on the inputs for that update. Because if the if the if the building blocks for 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's 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 that kind of suits is just so self-defeating. You know, that the whole point of this is to be effective in mitigating the delay. We need a realistic picture of what we've currently got in front of us, and this is supposed to be that realistic picture. Yeah. 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 would 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 have shown 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. Uh, 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. Um the fact is, if there's been a clause 14.3 instruction or a 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 event. 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 event really only means its commercial finality with respect to a price change or a or a completion date or key date or sectional completion remove. Everything else has already got to be on that program. 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 the first thing I think we'd say is that you certainly wouldn't exclude things just because they're a compensation event 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 labelled up one of the activities as PMI project management instruction number 27 corresponding to compensation at number 18. And I think this is the bit where, you know, I think Glenn favors this, or would put words in your mouth, but you explain your view on it as in terms of having a bit of clarity about being able to 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 the PMI because it might be relevant, but I definitely show the works. Whether I would identify which part of those works would 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 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 move about the right way around. But I can't get too excited about it, but I do feel like it's possibly one of the one of the maybe unsaid issues that project managers feel concerned about accepting a program uh that's too heavily annotated. What's your view, Glaire?

SPEAKER_02 46:08

Yeah, I think we're more or less aligned. And 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 program or 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 the cost implications of that uh of that conversation. So I think this is just helpful to annotate this as project manager PMI 27, which has also been agreed as C number 18, it's showing that that's the reason the plan completion is moving. So it's given everyone that visibility. I think that's helpful rather than rather than a hingance. 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. Um it's just that lack of understanding that creates issues that shouldn't be there. And I'm gonna get on that in more detail another time.

SPEAKER_01 47:23

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

SPEAKER_02 47:37

Yeah, 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 dates. But just a little bit on just the 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 uh fully. And I think, yeah, it's just a topic in its in its own debate that we could have a lot longer than we've got time to do today. But uh, some people like to do a block and contingency at the end. I call that lip service, not particularly helpful, it's easy, but whilst a 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 a four-day bar with a one-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 program is achievable, and know that that program contracts got a little bit of risk built in. It's not extra risk that other contracts don't allow you to have. 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?

SPEAKER_01 49:25

Because if you don't show it, uh 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.

SPEAKER_02 49:41

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 it.

Acceptance Consequences And PM Liability

SPEAKER_01 49:49

Absolutely. Okay, well, we could spend an hour just talking about that, but uh we are going to jump to conclusions. So, in conclusion, uh the accepted program is a central management tool, not just of baseline information showing original intention. Uh, it requires sort of contemporaneous updates, regular uh 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 Blenn's early slides showed with those activities orbiting the accepted program. 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 contract data and maintained in accordance with uh 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. Uh, it's protected when assessing compensation events, and the contract incentivizes both parties to engage. We have those motivators that NEC talks about, sanctions, but treated acceptance is retained price for work done state, 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, but then the rest of it will work a little smoother. Common problems. We'll race through these, I think, Glenn, because we'll go how many questions? Will got two questions at the moment. Okay, go for it, Glenn.

SPEAKER_02 51:52

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 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 program. Um, it talks about for each operation a statement of how the contractor plans to do the work identifying printer equipment and resources. So ascertain what's printer 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 uh 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, accepting the program with a CE already in the program does nothing to change the liability and the project manager's 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 as CE or not, then doesn't matter anyway. But it I think it's more helpful than harmful to do that. Ben, do you want to pick off the others?

SPEAKER_01 53:42

Yeah, very briefly. Then program is out of date, multiple CE since the last one. So this is a very, very typical problem. And we were we were discussing this, and we'll probably cover it in a in a bulletin at some point as well. That 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 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 would probably be a subject of a of a future conference, Glenn, is is if we can prepare it better, we 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 is weak and we're finding things out as we go and it's a bit hand-to-mouth, then we get this you know, 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 program 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 amounts on the one program, which is three months old, just to clarify what I meant earlier. Uh, missing planned dates that pair with contract dates. So really important if you've got key dates on your program. Contractors don't forget to show the 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 and too little detail. You know, it 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 withholding acceptance to programs because they don't show the information required in 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 like project output 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 that would trouble me, and I'd be feeding that back to the project team. Okay, uh we need to try and stick to the program, 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, uh Gilmer, for your question. So he writes under NEC34. Uh, 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 in NEC4. It's where are we? I think it's 32.2. A 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 works are complete, then yeah, we've we tracked everything we need to. Anything to add on that one day?

SPEAKER_02 56:56

No, I mean, uh, yeah, once once completion has has been achieved after that, there's not going to be too much. There might be defa, there might be some defects to prop up. Uh, there might be some obviously some some you still do some analysis of records for cost reimbursable contracts. So 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 program and share them? Because it should be in everyone's interest to close these things out as quick as we can.

SPEAKER_01 57:38

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

Non‑Acceptance Paths And Hidden Duties

SPEAKER_02 58:05

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's not taking on liability by not realizing, oh, I didn't see you reduce that timescale on line item 1004 of those 1200 items to program. If the contract says they've got three weeks for 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.

SPEAKER_01 58:43

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

SPEAKER_02 59:07

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're right, Ben. That that they'd have to be more careful with things like that.

SPEAKER_01 59:23

So I'd be mindful of consultation number two, three, and five. Um but also at a Glenn's point, if it's in the con it's sort of hard in the contract, then that then then those timings will apply. Okay. But as we've got one more, so we've overran on time, but we're gonna have a quick look at one more. So do you Jamie? Thanks for your question. Do we do you have experience of the project manager and the contractor disagreeing over how durations for CEs?

SPEAKER_02 59:51

Oh, never that never happens. Uh every day always agreed within minutes. So yeah, I mean that's the whole part of the C process, just just another part. Of the the compensation process. And I think we covered it in the quotation bullet seminar that we did, a webinar even. And you know, all contractors can do is justify the durations of 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 should, 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 uh is correct or not.

SPEAKER_01 1:00:36

So 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 with uh with a risk allowance forecast, then maybe we could turn it into a bit of a project manager's assumption, perhaps. I don't know whether 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 and kind of talk these things out, I guess, rather than just do it through the formal communication, because that that context and narrative you get face to face again, uh talking together uh uh helps. But certainly it's an area of of uh of of um tension sometimes. Okay, uh we just need to I've lost my slides. Um just need to advertise the next webinar, which is in the link. And can we thank you, Jane? Can we remove Jamie's question just so that we can see the full slide? Uh so episode six, we hope you'll join us. It's how to approach option Z and amendments, because that not all contract amendments are done through option Z. Some uh 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 be might manifest in NEC, but but option Z is we typically know it. So we're gonna be doing that at 4 30 same time on Monday, uh the 2nd of February. Uh 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. Uh we've over run by four minutes, we're getting better each time, Glenn.

SPEAKER_02 1:02:05

We are, we're improving. Thanks, everyone.

SPEAKER_01 1:02:08

Thanks, everyone. Bye bye.