00:00 Introduction

Glenn Hide: Good afternoon, everyone, and welcome to episode five of our webinar series. Happy New Year and all that. So, yeah, today we're tackling the issue of all things programme. So if you're new to these webinars, this is episode number five. So there's a few others you can catch up on that we've run previously, tail end of twenty twenty five. And this is episode five. They're flying by. And I'm joined today by David Allen and Ben Walker, who will introduce themselves shortly. And I'm Glen Hide and I run GMH Planning and we're a specialist consultancy. Focuses on 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?

David Allen: Thanks, Glenn. Yeah, hi again. I'm David Allen, the Executive Director for CECA Southern. I'm back for this first webinar of twenty twenty six. Blimey, where did the last year go? Well, obviously, Ben and Glenn 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, CECA Southern is just one part of a member-led trade body, a trade association, that represent 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 no doubt either myself, Glenn, or Ben will pick those up as we go through. But now I'll hand you over to Ben.

Ben Walker: Thank you very much, David. Happy New Year, everyone. Good afternoon. Today is episode five. And as Glenn 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 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 the two extremes. We've been a little bit sort of trying to paint those two extremes and hopefully you'll start thinking where is my project on that scale and what can I do to move slightly further to the right. We're going to look at the consequences of both acceptance and non-acceptance. Because accepting the programme has an impact, and we want to explore that a little bit. And also, of course, not accepting it also has an impact.

We're going to have a bit of a look at how to show compensation events on the programme. Glenn and I actually have a 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 that 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 looked at the time we thought we had available and we think we've just about covered 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 ever with every episode we'll look at some common problems and solutions and then have some time over to Q&A.

So, a bit of etymology. This is Greek, I think. Prographein. So "before" and "to write". So later becoming a gramma meaning public declaration. So that's where this one comes from: to write something out publicly.

03:00 The Role of the Accepted Programme

Ben Walker: So what's the role then for 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 absolutely 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 Glenn calls it the beating heart and I think we'll explore that a little bit more in a moment.

And the contractor must keep this programme up to date to reflect actual progress and the 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, 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 programme and then we forget about it. It's a much more contemporaneous document that is really necessary 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.

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, time risk allowances, resources and other information. So it's a collection of documents. It's a bundle, including method statements and all sorts of other things. It's not just a kind of pretty Gantt chart that we print out. It's a much richer set of documents. And again, definitely have a look at how to prepare a contract in the user guides, volume two, for more information on that as well.

The project manager then has two weeks to accept or not accept a submitted programme. And new to NEC4, silence is one of those occasions where it comes to the programme where you end up with a treated acceptance. So that's not everywhere, but this is one of the places where that now is also a feature. Compensation events are assessed against the accepted 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 sort of pricing documents. So all in all, there's a lot to say about this.

Glenn Hide: No, I was 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 thirty one point two to get the full list, bulleted list of all the things that need to be shown in the contract's programme.

08:00 Benefits of a Regular Accepted Programme

Glenn Hide: Well, these are just some of 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. 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. You can't do the application straight from the programme, but nevertheless, cost loading programmes is a very useful benefit. It's not mandated that 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. It 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 from the programme, your remaining cost profile forecast becomes just another part of the programme tool.

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 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 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 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 data date. Everything to the left of the data date will be actualised and should be factual. Everything to the right is then the remaining activities to be done and the logic links 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 process and part of that is using the programme 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 plan completions. So it's going to help with the CE assessment.

And then finally, cost value reconciliation, earned value analysis, not specific NEC requirements, 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 a programme should be.

I used to be a planner and a planning manager myself, so I've always had a real high level of importance and 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 with the benefits that it's going to bring.

Ben Walker: I think that's the key thing, isn't it? It's not saying this is extra admin. This is just project management good practice. There are some things that the contract is mandating, and they're in that list on that slide. But there are other things that are good practice that contractors will be doing anyway. And, you know, everyone's going to be doing a cost value reconciliation. Everyone is going to be efficiently planning their operations. They might not do it on the programme. There might be a bit of tactical planning, 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 those things into this. And 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.

17:00 Programme Life Cycle from Tender to Completion

Glenn Hide: So this is our life cycle 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 contracts. And the term of service contract for task orders, similar process, obviously the subcontract version. So a lot of the contracts do have this requirement for the programme.

So first of all, the first one can be included as part of contract data part two. Now that is optional, not compulsory. We've written one of our bulletins on why it is a good idea to always include a programme within your tender submission. From memory that's bulletin number forty-nine if you want to read up on that. But it serves so many good purposes if you as a contractor submit a programme as part of your tender submission. It shows you've understood the job, you've understood NEC requirements, you hit the ground running with your first accepted programme. So there's a lot of good reasons why you should be wanting to submit a programme as part of your tender return.

But it's not compulsory and there's a lot to do at tender stage, we get that. But if you don't include one within your tender submission then data part one will then state how quickly the first 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.

There's no need to ever refer back to the original contract programme. Even with NEC a lot of people refer to the clause thirty-one 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.

24:00 Submission Intervals, Sanctions, and Deemed Acceptance

Glenn Hide: 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 contract has got the 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 one. So the client will be stating how often they want to see revised programmes submitted. And almost always, it's either going to be four weeks or every month. Typically, those are the timescales we're going to see.

There are some sanctions. So if the project manager doesn't reply to a programme 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" is it doesn't make it an obligation because otherwise the contractor is 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 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. 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 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 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 twenty-five percent of the price for 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 three months into the job without an accepted programme that will be twenty-five percent of three months' money rather than twenty-five percent of the money applied for just in month three. And plus as well if you're three 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'll 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.

Ben Walker: Yeah, just a small point. Remember, it's the first programme, if you don't have one in contract data, it must be submitted showing information required. So it doesn't have to be accepted to release that retention, that retained amounts, but it must show the information required and kind of otherwise be compliant.

I was just thinking Glenn, you triggered my mind when you said these programmes are submitted whenever the contractor chooses to. 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 plan completion and the completion date, I think that would probably be an occasion when you would think to yourself, actually, I must submit a programme, I want that recognised.

Glenn Hide: Yeah, I think so. Having said that, I mean, if you've just submitted a programme and a week later, it could happen. It won't happen loads of times that in that week you've suddenly had a miracle and something, but maybe changes in logic.

Ben Walker: Yeah, you could have an idea about a different procurement method or something. So yeah, in that regard, that could automatically bring a sudden massive advancement. Changes in logic, things like that.

One of the big things people argue about is concurrency of delay. And if you've had that, if you can maybe have more frequent programmes, I guess that naturally kind of reduces the number of times you get that sort of circumstance. The other thing that I was thinking about was also, when you have sort of early warnings about potential issues and potential delays, it's not a bad idea to refresh the programme so you can go into those early warning meetings with a management tool that's actually speaking to reality and updating it for progress like that.

There was one thing I was going to draw on as well. The interval isn't set by the drafters of the contract, it's set by the client, the procurers in contract data part one. So the minimal interval will very much depend on the context of the project. So if you're in a power station outage period or a railway possession where you're doing a lot of work in a short space of time, it might be that your programming interval is a day. You might have that very rapid submission and revision. Whereas if it's a larger project and perhaps the scope is fairly sound and the site information is well known, a month might be sufficient. So the reason the authors didn't specify timings throughout the contract, 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 a copy and paste approach to your contract data preparation.

31:00 Two Approaches: Parachute Scheduler vs Collaborative Updates

Ben Walker: So I wanted to paint this scale. On the left, we've got 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 building the programme up from real-time records. And I've been on projects where both have happened. And it won't surprise you that where we were updating the programme twice daily from a whiteboard which had yesterday, today and tomorrow and by section what the different engineers were doing, what they worked and what they completed, it meant we had a much better objective factual picture of where we actually are.

So 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 might be getting back as disallowed costs when you're putting those in for payment. And of course, assessing compensation events. 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 or a different workshop of some kind where your teams are doing the tactical planning and some of the strategic thinking. And it's probably not the go-to document for you to start your CVRs and your 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, objective measures of progress underpinned in records that also help your commercial payment side of things. And then very crucially, doing the review and update together. So NEC doesn't prescribe every conversation you're going to have. It just deals with the formal communications and some management bits which are compulsory, like the early warning meetings and the upkeep of a register and what have you. But there's a lot it doesn't say that it anticipates you'll be doing from common sense project management. And it's sort of captured under the collaboration ethos. So reviewing it together seems evidently sensible.

Because not all things will be equal on a given project when we're looking down through that list of requirements that programmes should have. Are we really going to push for how many hand tools are used in eighteen months' time and argue their 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 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 CE assessments.

It also creates that minimal latency for project management. Which is going to maximise the 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 history. 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.

Glenn Hide: Yeah, absolutely. You know, I think I've already alluded to it. Some people say, oh, we can't afford a planner. And my argument is, well, you can't afford not to plan a job properly. And that's what the 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 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 is close the gap between site and the project office. 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 start to have those conversations around disallowed cost. So much of it is about where are the resources, what are they doing, how much progress have we made, how were we hindered, why were we stopped? Is it access, is it weather, is it physical conditions, or is it equipment broke down?

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 the two-dimensional picture, isn't it? We've already said there's method statements, resource allocation, that kind of thing. But we really are providing ourselves the oxygen we need to breathe life into those NEC processes.

There's a bit of top-down strategy with this of course because we still need a general strategic direction and make sure we're going to finish on time and take interventions as necessary. But I think that bit's quite often done relatively well. It's the ground-up injection of reality that's sometimes left.

39:00 Consequences of Acceptance (Clause 14.1)

Ben Walker: OK. Glenn, I think you're going to take us through the consequences of acceptance.

Glenn Hide: Yeah, well, it's important to remember. So it's a verb and it's intentionally that NEC uses the word "accept". So it's acceptance. So the project manager either accepts or does not accept the programme. And really important to remember under clause 14.1, the project manager's acceptance does not change the contractor's responsibility to provide the works. So don't "agree" a programme or don't "approve" a programme. 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 clause 14.1 makes it clear that by accepting the programme, it doesn't change the contractor's responsibility to provide the works. So they're off the hook if they've missed off a chunk of works on 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 that the project manager accepted the programme without those works doesn't change anything in terms of liability.

But equally it's important to then think, don't think it's inconsequential. Don't just accept the programme thinking it doesn't matter. Well, there are consequences because certain compensation events will refer to items on the accepted programme. 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 programme and the project manager has accepted those, as long as they don't contradict anything else in the scope, then they are accepting that. So there is meaning behind acceptance, but it doesn't mean liability taken on by the project manager.

So with that in mind, it's helpful to highlight timings for work of access or others. So when you're submitting a revised 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 programme, major changes in logic, things like that, highlight that. And yes, if there are 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 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.

Ben Walker: 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 clause 14.1 is a really important thing to know to sort of quell some of that anxiety. But equally 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. The idea is you add some value if you can. It's just you're not taking any liability for it.

And one of the things, one of the ways project managers 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 two, preparing an ECC contract. I think it's chapter three, how to write scope. So where 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've changed on your programme, how your assumptions have changed.

44:00 Consequences of Non-Acceptance

Ben Walker: OK. 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've got your twelve hundred line programme arrived for the first time and it's very daunting and you're looking at it and thinking, oh, good grief, what do I do with this? And you're weighing up your options.

Well, there's actually really only three options for non-acceptance. The first option on this slide is to accept it. And I won't reiterate that because Glenn's just covered it. So we basically notify acceptance. It doesn't change the contractor's responsibilities, but might change yours. You might have to go back and think about the client's work and others.

But there are three other options to you that I can think of. 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 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 is to notify non-acceptance. Perhaps there's an activity somewhere in sort of a year's time, which you think 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?

But there's some other things quite often project managers miss. If you withhold acceptance to a programme 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 the reason that I'll be making my own assessment because I think it's clause 64.1 and the last bullet point. 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? There's actually a significant consequence to withholding acceptance for a reason in the contract. You actually take on the duty of implementing those compensation events. And you also obviously have to make your own assessment of the programme for the remaining work.

Now I would 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 programme for all the importance that adds, and you end up with a deemed or treated acceptance anyway.

So that really does only leave the kind of proactive option in my mind. The project manager and contractor, let's share the records of what we've done and what we intend to do. Let's work together on it and update it regularly so that submission and acceptance can happen in a very short amount of time because we're aligned on it and it's recent.

Glenn Hide: No, I think you covered all the options, really. Just to emphasise that it should be in neither party's interests to not want to have a programme accepted. There's no one's benefit. Let's try and issue a programme that can't be accepted or from a project manager's perspective, let's try and reject the 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 then put that right. But both parties should be striving to make sure that we both get to an accepted programme every period. That should be an achievable reality, not a pipe dream.

49:00 Acceptable vs Desirable: Bad News Is Better Early

Ben Walker: OK and Glenn, 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.

Glenn Hide: Yeah, one of the key things is there's four 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 plan 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, from 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 practical, then it is acceptable if it complies with the scope.

So much better to know the reality now, rather than think that we're going to finish on time. We're going to finish on time. No, we're not. We're going to be really late. And that comes out too late. No one can manage those expectations. And it then becomes a bigger problem. So don't hide bad news. Show the reality at any one point in time. Absolutely fundamental to the success of a project.

Ben Walker: Yeah, and another reason to collaborate on the inputs for that update. Because if the building blocks 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. One of the pressures that project managers and client teams put on contractors to kind of squeeze the programme into a narrative that kind of suits, it's just so self-defeating. The whole point of this is to be effective in mitigating the delay. We need a realistic picture of what we currently got in front of us. And this is supposed to be that realistic picture.

52:00 Showing Compensation Events on the Programme

Ben Walker: OK, 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 programme? So we can agree on that. And certainly you should show everything that you're doing on the programme. 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 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, all the contractor thinks it is, 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 of these works, we must show that on the programme. It doesn't matter the status of the compensation event.

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 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. 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 twenty-seven, corresponding to compensation event number eighteen. And I think this is the bit where Glenn favours this approach of having a bit of clarity about being able to point at it.

Personally, I'm a bit ambivalent about that post implementation. Pre-implementation, I feel like although it doesn't interfere with the compensation mechanism, I think it might make people feel a little bit uneasy to accept a programme that is annotated up as a compensation event before the quotation process has played out. So courses for courses really but I think you just at least be mindful. Personally, I would probably mention a PMI because it might be relevant but I definitely show the works. Whether I would identify which part of those works were related to a specific compensation event, I probably wouldn't pre-implementation.

I think what I'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.

Glenn Hide: Yeah, we're more or less aligned. The only bit is do we tag that bar, that second bar down as a CE? And I'm of the mindset, absolutely. And 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 three and four, that sorts out the time and cost implications of that compensation.

So I think this is just helpful to annotate this as project manager instruction PMI, which has also been agreed as CE number eighteen. It's showing that that's the reason that plan completion is moving. So it's given everyone that visibility. I think that's helpful rather than a hindrance. And then once the CE is implemented, if it is implemented, let's say that bar is two weeks long, completion date can then move by two weeks. It's already in the programme. 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 programme, how the CE process works, then there's no issues. It's just that lack of understanding that creates issues that shouldn't be there.

56:00 Time Risk Allowance Best Practice

Ben Walker: Right. We'll spare everybody the geeky debate. You could just give us the best way to show time risk allowance on the programme.

Glenn Hide: Yeah, 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 time risk allowance.

So traditionally I see it done three ways and we normally explore the three ways and then say, well, there's only one of them that really works fully. Some people like to do a block contingency at the end. I call that lip service. Not particularly helpful. It's easy. But whilst plan completion will be realistic, to achieve those individual durations is unrealistic. So you could argue that's actually a reason to not accept the 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 a four day bar with a one day bar for time risk allowance. That just doubled the number of activities on the programme, 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. But know that 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. Contractors should already have allowed for it. It was just never called time risk allowance.

So very specifically, just having an individual column showing your theory of 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 item. And it's listed in clause 31.2 as a specific item to be shown separately from float. So we have to show it.

58:00 Conclusions and Key Takeaways

Ben Walker: So in conclusion, the accepted programme is a central management tool, not just the baseline information showing original intention. It requires a contemporaneous update, 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 Glenn'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 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.

Time risk allowance best identified in activity durations rather than as a lump sum at the end. It's protected when assessing compensation events. And the contract incentivises both parties to engage. We have those motivators that NEC talks about, and sanctions for treated acceptances, retained price for work done to date, which is a massive neon sign that says, look, this is serious, invest in it, think about how you're going to operate it.

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 four to eight hours. Then the rest of it will work a little smoother.

59:00 Common Problems and Solutions

Glenn Hide: Common problems. 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 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.

Annotating programmes with compensation events. So we've talked about this. Yes, you do show non-implemented compensations 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, accepting 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.

Programme is out of date, multiple CEs since the last one. So this is a very very typical problem. NEC is not designed for huge volumes of change. I think most people would agree with that. If we have huge volumes of change, we can cope with large volumes of change if we keep the management mechanisms up to date. But 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 you get this abnormal amount of change and 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.

Missing planned dates that pair with contract dates. So 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 the planned completion. That pairing of contractual deadline and reality creates that terminal float which is preserved under clause 63.5. So really important point, always show the pairing.

Too much or too little detail. You know, we shouldn't be guessing how much information is the right information. If we're having those conversations, we should never really be in a situation where we're holding acceptance to programmes because they don't show the information required in the contract. Those conversations can and should be had.

63:00 Audience Q&A

Ben Walker: Thank you, Gilman, for your question. He writes: under NEC3/4, could you please confirm whether the contractor's obligation to submit programmes for acceptance continues until completion of the works?

Glenn Hide: So yeah, it's in NEC4. I think it's clause 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 we've tracked everything we need to.

Ben Walker: 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 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, once you've achieved completion, a lot of the contractual sanctions and liabilities for insurances and things like that disappear. 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.

Ben Walker: We have another question. What is your experience of instances where an accepted programme includes reduced client periods compared to the contracts and what the contractual consequences of both parties in terms of risk allocation, compensation and reliance?

Glenn Hide: So if the client said they want three weeks to accept design for example and the programme shows one week, and the programme's 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. If the contract says they've got three weeks to review design, then they've still got three weeks. And if the accepted programme says one 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 timeframe, we've got those compensation events, number two and five, I think, which talk about things that the client or others don't do within the time shown on the accepted programme. So I think you need to consider both those things there.

And obviously, if it's response times, then it shouldn't be less than the period for reply. So that would come into play. But yeah, if it's free issue material and there was no restriction in the scope as to how long notice, then they'd have to be more careful with things like that. So be mindful of compensation events number two, three and five. But also, if it's sort of hard in the contract, then those timings will apply.

Ben Walker: Jamie asks: Do you have experience with the project manager and the contractor disagreeing over how durations for CEs?

Glenn Hide: Oh, never. That never happens. They always agreed within minutes. Yeah, I mean, that's the whole part of the CE process, just another part of the compensation process. And all contractors can do is justify the durations of right for the compensation, that they have put a sensible amount of risk and not excessive risk. And at the end of the day, the project manager makes their decision if they think that's right or not. But they've got to make sure that if they think it should be 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. 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. 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, rather than just do it through the formal communication, because that context and narrative you get face-to-face, again, talking together helps.

65:00 Closing and Next Episode

Ben Walker: So episode six, we hope you'll join us. It's how to approach option Z and amendments, because not all contract amendments are done through option Z. Some NEC customers have sort of copyright licence, if you like, to the contract itself. So we'll look at both aspects of how amendments might manifest in NEC. But option Z is how we typically know it. So we're going to be doing that at four thirty, same time, on Monday the second 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 overran by four minutes. We're getting better each time.

Glenn Hide: We are. We're improving. Thanks everyone. Bye.