Name: Why NEC4 Claims Succeed or Fail: Lessons from Clients, Project Managers and Contractors
Uploaded: 2026-10-15T10:31:07.968Z
Duration: 58 min 45 s
Description: Why NEC4 Claims Succeed or Fail: Lessons from Clients, Project Managers and Contractors

Transcript for "Why NEC4 Claims Succeed or Fail: Lessons from Clients, Project Managers and Contractors": good morning, everyone, and thanks for joining us. My name is Natalie Moyes, and I'm Deltek's regional director for And today, we will be talking about claims, but also what happens before you ever get to that point. We'll be talking about how good the program is, what evidence did you have, what decisions were made, and, ultimately, does the position stand up to scrutiny? I have a great panel with me today. Mick Higgins, manager director of Exacom, has over twenty five years experience across project controls, earn value, schedule risk, particularly defense, nuclear, rail, and utilities. Second up, we have Richard Brown, project controls director at Arcadis with more than thirty years in planning project controls, including some of The UK's biggest infrastructure programs. And Tony O'Hallaghan, when he joins us, is project director and technical lead for planning at Blueprint Project Solutions. Tony spent twenty two years in the RAAF before moving into construction and has since worked across rail, water, energy, and aviation. So clearly between them, we will be treated to stories and perspectives from a client, from project managers, and from a contractor's point of view, which should make it a really interesting discussion. So rather than me taking any longer as we have had a slightly slow start, Mick, I'm gonna hand over to you to get us started. Thanks, Nat. Thanks for the introductions. So a couple of things before we start. Number one, I think it's important to highlight that this isn't a product session even though we're presenting on... With Deltek, and it's not a software demonstration. And although the title says claims, I wanna be slightly awkward about that word because it matters. So NEC four doesn't really have claims. It has early warnings, compensation events, notification inside periods... In set periods, an accepted program, and an assessment of events effect at the dividing date. By the time something's become a claim, the contract is usually run badly first several months. Most of what we end up calling a claim is a compensation event that nobody managed while it was still alive. So the premise we are working from is this. Most claims do not fail because there was no delay. They fail because the program, the evidence, the terminology, or the decision making cannot withstand scrutiny. The delay was real. The entitlement may well have been real, and the claim still falls over. So where are we today? Three observations. First, when it goes wrong, it's not marginal. HKA's Crooks research covers more than 2,200 distressed projects in a 114 countries. On those projects, the dispute sums average about a third of the contract budget, and the extensions of time claimed average about two thirds of the plan duration. Those are not rounding errors. That's the project again. Second, and this one's more encouraging, the underlying causes are easy. The same research shows failures in contract management and administration roughly halving over five years. Scope change is still the most common cause, but it is down. The industry is getting better at this, but slowly. Third, what is rising is cash. Payment and cash flow disputes now affect around one in seven projects and over a quarter of mega projects. In a tighter economy, nobody has the capacity to absorb costs quietly. What used to get written off now gets claimed. Put those together and the prognosis is reasonably clear. Claims are becoming a planned commercial exposure rather than an exceptional event, which is why boards are paying more attention and analysis getting cheaper because structured tools and AI can interrogate in an afternoon a program that took took two years to build. That cuts both ways. If weak evidence can be found quickly, it will be. So the bar does not drop. It rises. The organizations that come out of this well are the ones who... Whose records were honest at the time, not the ones who were best at reconstructing a story eighteen months later. That is what we're here to unpick. Where it goes wrong, what good actually looks like, and the part in the middle that nobody really talks about. What happened between the moment the problem was first visible and the moment somebody decided to claim? One ground rule. These are live commercial situations, so please describe the pattern rather than the parties. No naming projects. No naming clients. It protects everyone, and it makes for a better discussion because we are after what generalizes. Richard, Anthony, if he joins, let me start with you on environment. So, Richard, if we look at the environment around project controls and claims in NEC, is a claim now a budgeted commercial exposure rather than an exceptional event? I think you're somewhat... I think some of it depends on the sector. I think the point with this is really, mate, is that, as as you say, it's it's no longer just a commercial matter, just a contractual matter anymore. I think one of the key issues really is it's what it exposes, within the project itself, you know, the the the governance, the forecasting, the project controls, who was making the decisions, what got escalated, did it get escalated, what's the culture like there? You know, that... That's really, I guess, the the key point you're coming back to. And I'm sure that something that Tony will really lean into when he joins us is the willingness of the leadership of the project to actually accept, the the information if it's not very comfortable for them. So the real, I guess, the real question then is if if the organization knew the project was was slipping, why do they only really get attention when it became a clue? Yeah. I think you're quite right on that. I think it's, you know, it's back to this collating evidence as we go through the project rather than getting to a situation when we have to retrospectively try and dig everything out to create a picture of what we think went wrong at the time. It is... I mean, for me, from from from a project and program controls perspective, what do we need? What do the lead... Leadership of projects need? They need to know the schedule is credible, that they're actually making decisions upon. They need to make sure the forecast is actually an honest forecast, if if that if that makes sense. Then if we do have if we do have any variance that's emerging in the projects that we understand what it is, then getting getting back to your point really is is is if we are... If we do make any interventions, those interventions get owned. Ultimately, with that good data, you're gonna get decisions getting made at the right time, hopefully. But mainly then you can find out if people didn't do anything, the consequences of not doing that was actually visible. I think the problem really then kinda hooks back to... Because if we always... We were kinda building this around, it being an issue of leadership. If the if the formal position of the project that... That's being reported, if that's dis... If that gets disconnected from the operational reality of the projects, then that's when it becomes a real issue when leadership need to lean in. I think that... I mean, I think I guess the idea of this is why why are people paying more attention to claims now? I think that comes back down to the current position that we're in in terms of the economy and things getting tighter budget wise. You know, profitability, impacts, you know, every... In a lot of organizations now, every penny counts. So it's... You know, the focus rather than writing some of these things off really is focusing on what can we recover back from. a situation that, potentially, you know, we we may not feel like we're at fault as an organization. True. Yeah. I mean, I think if you got... I think the thing is with... When you get into these, major claims situations, they're they're rarely an isolated event. It's rarely an isolated commercial event. Quite often it can it can show that whomever that organization was, they might have known about the position slowly deteriorating over time, but they might not have understood it. They might not have understood the why. They They didn't know how to escalate it or they just didn't escalate it or they certainly didn't act upon it. And I think at that point, the leadership of the, you know, the clients or that organization is not only asking if the claim's valid, but they're asking why did the governance system not pick it up earlier and produce an earlier intervention for us? Let me just jump in and welcome Tony. So pleased that you were able to join us. A few technical issues, but, you know, that's real life. So you've not missed very much, Tony. We have actually mentioned you a few times already. So welcome to the discussion, and we'll pass back to Richard so he can carry on. Thank you. Yeah. So let you sum up, Rich. very opportune... Yeah. It's like a very opportune time to, to join Tony. You know, we're really talking around, you know, why claims are an issue, why claims are becoming more prevalent. And and, oh, I guess I guess to wrap up what I was trying to say is that while while the claimant itself is is contractual, the issue quite often in its origin is actually an organizational issue and a governance issue. So so, I I don't know how much you missed at the start of that, but I'll have to say, I mean, an NEC three then morphed into NEC four as an example. And what I see a lot of the time is you've got things like zed clauses and all all the clauses start getting... They they start killing a lot a lot of the underpinning of what the contracts meant to mean. So then it all gets very messy in the middle of a lot of the contracts. So I think that's part of the issue as well. So, again... And I think this is back to, you know, tracking the information as we go along rather than getting to the end and trying to reconstruct, you know, history. So things like, you know, the program, you know, can it actually be used to demonstrate what happened, or does it only demonstrate what was planned? That's the difference between we've got a a planned program here, but we've been tracking actuals and progress against it. So is there any specific things around programs in your experience, Tony, that, you know, we need to take into account, especially if we're... If if we wanna protect ourselves from a claim position? Yeah. Thanks, Mike. I mean, Michael, the, I've I've been across various projects, and some some go too far with control of the programs. Like, they want to know every single change, every relationship change, everything to the nth degree. And I believe that draws away the planners and the teams from actually using the program to drive the project. And then we go to the flip side where project teams sometimes feel it's it's like a tick box role, then it's one of the best tools on a project to help them deliver the project, identify risks, look for opportunities. Again, on other projects, they're either too detailed or they're not detailed enough. And I've I've been asked to go and look at small projects for claims and maybe a 200 activity program. Loads of missing logic, like, 25% constraints on 200 activities, you know, 98 missing logic links. And then when it dug into the program with the construction manager, about a 100 of the activities were the wrong dates or the wrong durations. They had to go back into the site logs. So I think if the... Some of the best projects seen is the project teams know that they own an input to the program. It's not owned by the planner. It's owned by the team, and it's in everyone's interest to keep it up to date and to use it to help them drive the project. Yeah. I think on that... So I think, because I think I think on that sort of, yeah, it kinda leans into that, the whole credibility of a schedule is that it's the understanding that your schedule's not reliable just because it's got thousands of activities or it gets updated every month or it's kicking out the metrics that you wanna see or it has a critical path or it's been accepted. The the real question is, isn't it? Is that... Or does that schedule give you a, a credible model that's based on reality as to how we are intending to deliver the work and showing what's actually changed. I I mean, just another example. And, in one of my interviews, I gotta ask, you know, what do you think about about metrics and, you know, earn value and all of this AI, etcetera. And it's exactly as you just say. It's it's it's gotta be about the quality of the data as well. So if there was a team on you doing a really nice Power BI presentation and all nice charts and graphs, but then I was asked to go and look at something. And when I looked at the resource numbers, the hours, they've gone from, like, 26,000 over about eight programs up to 38 at one point and then back to 29. Now there's a little bit of scope and d scope, but not by 12,000 hours. But everyone had looked at the nice graphs, and no one had recognized that it was climbing and falling quite significantly through the months. So, again, it's back to what you're saying is we've got to look at all the data and all the information, just not pretty graphs, just not nice Power BI inputs. What what is that information telling you? That's what programs really... And planners should be helping you to do, identify risks, opportunities, issues. It's it's not just a reporting tool. It's a delivery tool. So I'm just gonna. jump in. because we are getting some feedback. We're not sure, Mick, if it's your sound. So if we're not speaking, if you could mute yourself, hopefully, that will cut down on the feedback we're getting from Tony. Sorry, guys. Back to you. No worries. Yeah. Just to kinda lean into what you were saying, Tony, I think that the point with that is you can get a very detailed program. It can still be analytically weak as you say, you know, even though it's got a lot of detail. But then on the flip side, it can also be... You could argue that it's technically compliant, but still it doesn't mean a lot operationally. And, you know, the the credit just because you have a critical path, that critical path, it needs to make sense of the people actually delivering the work. They're the people who who truly own the activities. And then I know we're getting to this later, then it kinda drives that whole thing that really annoys me about vague activity descriptions. Because then it just gets very... It's almost like guesswork. So, you know, that's my two penneth that insufficient. Sorry. detail, which is Well, It is. Yeah. they always describe it, isn't it? I mean, there's a guy on on LinkedIn, Zoltan. He's absolutely brilliant, but he always said, like, you have to have a verb and noun and then, you know, locations, etcetera. And you just see something really nebulous, you know, as a description. But one of the best project directors I worked with, and he said program's king. And I know I'm a planner, and I know we're a bit biased, but I believe it is because how can you do cost? How can you look for a lot of your risks? I know there's risks that sit outside the project and they sit more on the potential business side of things. But your cost, your risk, how can you do a cost if you don't know how long the project's gonna take? You know, how can you do your prelims, site time... I know your site cost for your site cabins, etcetera. So he he he was... He loved the program, and he used it for all of his decisions and everything else. And guess what? His projects went well. You know? And, he valued the planner. it's a question I'll post to to you guys. Right? Because you're closer to the tools than me these days. But in your opinion then, what what most commonly would undermine the credibility of a schedule? So is that for. for myself? Mikey. Sorry. Well, From my point of view and experience, I think it's, it's not being structured in line with the way the work should be delivered or. should be planned to be delivered. So even if you get all the quality metrics right on a program, if it's not constructed in a way to deliver the scope of the works information as the program should be delivered, then it... Even with it passing all the other quality checks, not really worth the paper that it's written on. So I might jump in on that because while I'm not a practitioner, I do hear a lot of point of views and assurance. So if you don't know about one thing that's in that schedule, your credibility goes out of the window, and I hear that all the time. Especially things like... I mean, and this is a really easy and obvious one. Things like hard constraints. Oh, yes, mister client. I know I've got three of them. And they're like, well, actually, you've got five. So now all five are up for issue, not just the three that you thought you had. So we hear that quite quite often. I mean, an... Another piece on it is the, like like I said, Natalie, knowledge of it, but I was on another big project. And, unfortunately, the people who were in before myself came from a production background, not from a construction background. And I knew the client followed a a set structure through their governance, so you've got reba for all of your reba stages, you know, through your design life and then construction commissioning. There's so many different variations of that that you get in every in every sort of large organization, be it network rail, highways, you know, all of them. But they, the team, because they were in an inexperienced construction, their cost breakdown structure didn't align with the work breakdown structure of the project. And then everyone was talking about our own value management. So my point to them was, well, how can you tell how much stage two costs are if the CBS is spanning stage two and three as an example? And they didn't see an issue in this. And so I helped them trying to get the whole change control process in place, trying to get, you know, your your project management baselines because every month, the teams are just moving the projects around. And when I asked them where the clause 31 was, I'm gonna know we're Tom at NEC at the moment. They went, oh, and they they showed me some PowerPoint slides. And I said, well, how how can we actually apply that to the programs as they stand and use it to measure it? Then we had other teams, and the production management teams who... The programs were a 115 activities for eight to 35,000,000 pound projects from light right through from... Does... I am solutioning our nightline design right through the commission and handover. And the teams were pulling their hair out because they didn't know what they're doing. They were sitting in production meetings twice a week, and stuff was being recorded on Microsoft Planner. So I sat with the design teams and built them a 400 activity fragment for design. We plugged it in all the programs, and if there was no break tanks, it was dissolved out, etcetera. And they said it's first time in a year that there's any visibility of design and there was an interconnectivity between the 24 projects. But then the production teams were running off to then buy a certain linear project software that was quite a costly piece of software. And they were telling everyone it would show them headroom removals. It would show this. It would show, you know, site strip. And I said, well, it's not gonna show any of that unless it's in the program. And, again, it was down to these teams proposing these types of things that didn't understand plan and didn't understand the software. And the the... All the projects were then delayed and they're in trouble. So make sure that the people are SMEs, that they know the job, they know the software, and they know planning. Another project went into... There was no, stages or phases discussed discussed whatsoever on this. And this, again, was quite a large organization. And I said, oh, well, stage stage two outline design. They went, what do you mean? What's the stage you're talking about? And I went, well, from that gate to that gate, what's that called? What was the time between the gates? They said, well, it's a stage or a phase. And the the senior PM didn't even know didn't even know what a stage or phase was in the project. So, I tell, you what's funny. there's gonna I'm I'm I'm gonna I'm gonna pick into that in a second. Right? But just to kind of... Because, obviously, I asked the question and everyone gave an answer there, which I thought was great. So it's really that whole thing about underlying the the underlying schedule credibility is it's never one single thing. You know, unrealistic constraints like Nat said, you know, we've got accumulation of weak logic that runs through it or lack of logic, a critical path the delivery team's not not bought into. You know, it's it's never it's never usually one single thing, is it? It's an it's a it's an accumulation of thing. And when you've got a lot of those weaknesses that sit inherently in a schedule, when it comes down to the whole claims piece at the end, it can be quite difficult to isolate So single effect when you've got all of those weaknesses already existing in it. I I think there's another... Sorry. So I make... we've we've covered quite a lot of weaknesses. What's good look like? So if we get to a point where a claim needs to survive, you know, scrutiny, what has to be true before that event happens? So what does good look like when we get to I think claim position? I think before we move on from that, Mick, there's just a quick one is... Again, I think I understand something even more fundamental. That plan needs to be recognized as a discipline in its own right. Another issue I've seen and said we'll go to the positives later is there's a lot of people, non planners, that are playing around in Microsoft Project or they're putting... Trying to put programs together, and they're pictures. They're not programs. You know, in Microsoft Project, you can have auto schedule and manual to send you something you go right or wrong. The director once sent me a Microsoft project program when I just joined and said, oh, put that in p six. And I went, you're six weeks late. And they went, why? I said, you haven't put Christmases and bank holidays? And they said, yes. I have. And I said, you've created the calendar, but you haven't assigned it to the project. They went, oh, I'm gonna assign it. It was five to six weeks late. So I I think it's a fundamental piece. I think there's a lot of planners, and I lose... Use the term loosely sometimes, don't help the planning community. But I think there's a lot of people don't recognize planners and their specialisms and that managing the project, the the program, the logic. And outside of that, the planners aren't just p six and Gantt charts and tools. Planning is so much more about ice to get contacted by the expediter in procurement saying, Tony, when are those pumps getting the site? Because then, yeah, I was chasing down people in the program to make sure the pumps had site, as per my program. So, Okay. yeah, that that acknowledgment plan... And because there's no charter ship for planning, there's one for a cost a, there's one for risk, there's none for planning at the moment. So I was trying to work with APM, and I've said there's now a charter ship coming out for project controls, but project controls isn't planning. So I think. that's one of the fundamental problems that planning hasn't got a charter ship and a governing body and something to make sure people have the correct skills, etcetera, to call themselves a planner. Sorry, Mick. So, Samik, just before you go, our team has reminded me to remind the audience, many of whom may be planners, that if you have questions that you want to submit as well, please do so. Our team will see them, and we'll see if we can feed them into the discussion as we go. Nick, back to you. I'm gonna, link into what what you were saying, Mick. I'm trying I'm trying to give you a bit of a neat. segue into what good looks like. So it was... I think it needs to start with it. It's something that Tony touched on. First of all, making sure that we all use the right terminology or at least the same terminology on a project. You know, if we're referring to a baseline or an accepted program or a forecast or, what kind of float we're using, I was working on a... I was work... Be be... Be careful. I was working on a project. But, you know, where where we were using or when I arrived, the terms time risk allowance, terminal float, and buffers were being used interchangeably. That's just dangerous. And that's not... That was nobody's fault as such. It was just a lack of understanding in the terminology. And I think that's I think that's a real point that the terminology isn't semantics. You know, if we're using different definitions, we could be comparing completely the wrong things. So if you wanted... My first point of what does good look like, get the terminology right to start with before we... Before you get going. And I'd jump on that as well because, I've been in clients when we have been using the same words. So twice I've seen this, one with EAC and one with, I think it was even work packages or control accounts. And it wasn't the definite... It was the definition that was the issue. So the words were the same. On that side, they they were consistent about what that meant. On our side, we were consistent about what that meant. But the next question was, well, what do you... Give us a definition, and what do you do with that EAC? And as soon as you ask that question and what's the next step, then the clarity came out because we were we were using words that we were used to, so they weren't swapping them out. But the definition and the ultimate end of what that journey of that kind of piece of information was was different. So so something, of... Just to start up with a new client and something I was asked for when I first joined is, can I have an acronyms list, abbreviations list? And there was one organizing I went into, and they had a 40 page one, which was absolutely amazing, but they actually had, acronyms for... That meant two or three different things. So, you know, start start with those basics. A lot of people throw in acronyms now in in in in pro... In projects. And then I think it's... The good the good part, Mick, is that that it was part of my masters that did around what good construction and what good planning looks like construction is that curiosity. Be willing to ask those questions. And I I think from from a lot of stuff I've seen, we've gotta get back to doing the basics better. There's there's a rush at the moment. Everything's AI, AI, AI, and I think we've gotta get back to good quality logic, good quality underpinning of the activities. You know? Some planners look at look at p six and Gantt charts and bars. I see that as a task. How big is it? What what size is the material? What size is the substation? What size is the pump or the valves to quantify it? Because it helps you, a, understand the challenges people are gonna have on-site when they're moving this bit of kit around. But, also, it helps you to challenge them and go, right. You're really saying it's gonna take two weeks to do that. No. No. It's not. So I'm I'm on this. I've got the WhatsApp group. I've got about 130 planners in there, and it's brilliant, you know, and the people have worked... 80% of people are... People have worked with through my time and plan, and then 20% are people that have come recommended from the 80%. And I believe also, Sharon is is building strength, not I know more than you. So, again, we've got a... The the earlier you can get in in with PMs and train them to respect the program and plan and, you know, the better because then the value of the program and see what it'll help. So that's what good looks like. I would rather have PMs come and ask me I think both all day. Sorry. I would rather have PMs come and ask me 50 questions a day about the program than them asking you twice a week. So it shows that they're invested and interested in the program. It... Calling Richard. No. I I I agree. I think from... I think we can all, you know, we can all look at, you know, what what does good look like with regards to a schedule? Oh, okay. You know, Make sure it's a robust schedule. I'm not gonna go in adding tonight and what a robust schedule looks like. From a controls perspective though, make sure you're being transparent with regards to the limitations, and that you're recording your assumptions. That kinda comes back to what you're saying as well, Tony. You know, record your assumptions. If you've got uncertainty, because you will have uncertainty, make sure it's visible. And the the analysis, when people are doing the analysis, make sure it's reproducible. And I guess... And and this is not a question for yourselves, Megan, Tony, because you do this a lot more than me. But with regards to a claims position then, what makes a claims position more credible? I think if somebody who didn't build it can do analysis on it and be able to follow it, whatever it might be, whether it's the schedule, whether it's a bill... As bills, whether it's timesheet logs, or however the claim's been built for whatever rationale. If somebody who didn't build that can actually analyze it, then I think that's what good looks like. So so it feeds in what makes saying the whole the whole thing I've seen when I've been involved in various claims and and, you know, people go go and review review the program and then start asking for documentation. Right? So the whole thing is contemporaneous information, and only started to hear that sort of term three, four years ago. And it's one of the biggest things that help you win a claim, and it's one of the biggest things that help you... That will cause you to lose a claim. You know, if if subcontractors or clients have more information than you about what's been discussed, they're gonna win the claim. Whereas if you can put your package down and then you go, right, we've had a delay here. The program shows that. Get get the delay paid into the program and have the information relevant to what what was being discussed and what what... So they always say, what was the issue and what was the impact and what was the result? You know, the three sort of things you need to have for a claim and for an impact. And the amount of times that's not recorded is is quite quite bad, actually. So the the ones that win are the ones with more information. And, again, it's it's storing it. I've seen people storing stuff really well, but it's fragmented in the different folders and different people's emails. People leave the business. Someone goes, oh, he sent an email to me. Right? Where where is it? He's left the business. Right? So where is the email? And no one could find it. So I always try and... I mean, brilliant... One of the brilliant tools I I used and started trying to do to build up, and it's not claim specific, but it can be used for claims as something like Mural and Marrow. And, you know, you have your month by month key events, whatever, and you can put a link on there to a folder where these these events and this information is stored. And you could... You know, there's all our tools out there, but folder structures. People people aren't even using folder structures correctly. You know, even someone goes and sets a, b, c, d, and up to, like, k and q, whatever. And c might be commercial, d's planning, but then someone might store something that should have been for commercial information in the planning folder, and then something was about mechanical... To put a mechanical folder, but it was actually a commercial. So it's about getting your your documentation and your information stored correctly as well is a is a big one for that. Yeah. I think it's not it's not... I think we need to be careful... Be clear in what we're saying. It was... But it's not it's not just about that repository of data. It's having that consistency, isn't it? It's like, well, like Nick was saying, consistency between what the schedule is telling us, what progress records were telling us, what the contemporaneous data is telling us. And you've got that connected golden thread, if you like, that runs through the chain of information with. But what I'm saying, Richard, is if the folder structure is right, you would have a folder in there and say delay event one. So. Okay. you you. would be keeping it. Right? And then on the program, you'll have delay event one. But if it's just. chucked into a folder somewhere and it's not marked as delay event one, the amount of time and energy that's wasted going looking at dates and trying to see who's... Who sent what, that's a massive time on a claim review. So, yep, you're right. But then have a claims folder, EOT folder, delay one. Right? Programs says delay one. Let's go and look what happened in the in the contemporary and this information. Is that link in that margin of the information? Which obviously has the same... I'd, you know, I'd I'd say the same thing with regards to when you're trying to view it on a schedule. You know, if you if you've got your CEs and your changes, you know, bold and bright enough for everybody to be able to easily find it. Well, you you should always have, like, a CE section in your program, and then it's linked. Again, I went into a program, and someone had put notices of delay into the program for a milestone when the event started. It wasn't linked to any events. Now it wasn't a big program. It was a 200 activity program. And I said, why haven't you linked it to the events? Well, I'm not a claims planner. And I said, no. You've put a notice of delay that is an impact on the event, so it should be linked to the event. So that's, again, what it looks like, Mick, is you put the event in, you put how long the delay is, you link it to the activities it's delaying, and people don't like breaking out and tasks as well. So if there was a... No task belong in forty four days, two months. But a month then, if you get a delay, I... What I do is chop that to the first month and say first part of the task, then there's two months delay event. You can't get access to a build, and you put in a two month task between it, then you do the next twenty two days. Then you've plugged in the delay event to show what the impact is of that. You get other people put in pause and resume, which I don't like. I've never done. I've never used it in my life. You've gotta clearly show the delay events in the program. Code them. You can code them easily as well, Richard, which a lot of people don't do. So then each month, whenever you go in, you can go and pick a window, and you can go filter for delay events, and you've got all those filtered straight in the program. So know? So your window analysis is easier. so in terms of demonstrating impact, how how do you look at isolating, one event from everything else going on at the same time on a project? Is that from myself or Richard? Sorry. I'm assuming that's more for you too. And, Either. You you do an awful lot more, than. me. again, it it comes right down to, and I've I've learned this more and more. I used to just have bars on Gantt charts, and I did a little bit of coding. But the coding is absolutely amazing. Right? You can you can strip and do everything else with code and everything else. You can do it with WBS and filters, but if the code is right, you would have it done by what type of... You know, you can have it by floors. You can have it by areas. You can have it by types of equipment. The more you put into the program early on, the better quality of of filtering and and trace and stuff, the better. So that's where I try to get things to in the program. Codification, I mean, there's there where they actually have a standardized code in construction. So the the code flows from your drawings right through your cost, right through your program, so you can actually trace that golden thread you talked about, Richard. So. that's why the codification is so important. But you see someone as activity codes in the program, different to cost codes, different to, you know, contracts and commercial, different to... So codification is so important, and then it flows through that piece of equipment or that piece of work right through the program and documentation. Nothing we've we've picked up on throughout the conversation the importance of tool... Tools. And another part of that is the introduction, I think, more heavily of AI. And I think, Tommy, you alluded to it earlier, you know, you... The use of AI. So where do you think AI genuinely helps? I have this question to both of you. And who stays accountable for what comes out of AI? So I think you can break this in into two pieces. Okay? Because this... We need to be clear as to tools that help an AI because that could be very, very different things. Technology is there for us that's make life easier. You know? Not to drop any names in there, but there might be some there might be something that somebody, generates who might be on the call that does very good schedule quality checks, for instance, and let you compare different versions of schedules and look at all the different logic changes and all that kind of stuff that can, help you find inconsistencies between dates and descriptions between, you know, scheduled versions, etcetera. That's all great. That really, really helps. More of that, please. With AI, where I think we're gonna be careful, is as a kind of like you you said there, Mick. It's about that accountability for the professional opinion that we're actually giving. So what what is it good for? If we're trying to review documents rapidly, yes, it's brilliant helping to do that. Identifying contradictions between documents and summarizing information that gets repeated. We've all read through documents ad infinitum and you end up going word blind, so it can help highlight things that are missing from that documentation. I think the I think the thing is it... So for me personally, what can AI help? It helps accelerate the interrogation of data and certainly documents, but it doesn't compensate for firstly having an unreliable schedule, having that missing content radius data, Tony was talking about, having the wrong assumptions contractually and the wrong terminology. And ultimately, it doesn't compensate having having from an having an an analyst that doesn't actually understand the results. So for me personally, yeah, it does make analysis quicker, but it doesn't... First of all, it doesn't make poor information true. But also you still need that professional judgment to explain why anomalies matter or not. So that's... That... That's my point of view. So so to go back to the, do the basics better, which has been made to us say especially even from doing the master's piece. We've gotta do the basics better. The program is better, the quality, and then you're seeing how long something truly takes us all better. And then AI has got better quality, and it can help you do tenders, do it all. But it's, unfortunately, if garbage in garbage out, if you stick a 100 programs into it and only 20% of them are any good, it's gonna give you 80% of garbage and nonsense. Same can be said for any sort of data gathering construction. My brother was handed 500, sort of piling events to go and look for norms and look for how long it could take. Didn't have locations. Didn't consider it was the middle of London or it was the middle of, you know, it was the South West Of England that takes four hours to get to. Didn't look for times a year. Didn't have the types of piles. Didn't have the lengths and the depths of piles. Didn't have the type of ground that we're going into. So we got 50 out of 500 of, you know, of pieces of good information. So we need to get back to doing the basics better, and then we could start running on a bit more. And then, similarly, where it can can be a bit dangerous and dodgy, I'd I'd have... One of my friends, he sent out this little, task for someone to do before an interview, and it was to build a house and where... You know, with the sequencing, when the windows went in, when the roof went on, I think. And it came back, and the narrative didn't look human as such. And whenever this other guy, Jason, he he put it into chat GPT or something to say, write me a report on this. It was literally word for word. Someone had just dropped the task summary into the... In the chat GPT and it produced a report, and that's what the guy that's what the guy sent back on... For the in... Pre interview. So it's... My my concern is... I I don't know if it's the right word. I don't want it to make people become lazy and think they can just drop something in AI and then take what it does and then pass it on. Like Richard said, there's still gotta be that human element. There's still gotta be the the review, the, you know, check the information that's being produced is correct. And I've no doubt it's a brilliant tool, you know, my brother in construction, whatever, and he's he's even created his own a... His own AI and everything there. But, you know, he's using it to the next level. But he knows construction. He knows contracts. He knows law, etcetera. So he knows what is producing is either good or bad, whereas there's a lot of people doing these types of things in the reporting world, and they don't know what the producers, whether it's good or bad. Make that... That's a danger. A lot of IT people producing stuff in New York. Oh, that's reporting that. Grant, what's it telling us? Not really much. So why have we wasted time on it? Yeah. And I think there's... A lot of the discussion has been about what we've got and reviewing what we've done. But then there is always the next piece, and so many clients spent so much time building these reports, and they have no time left to actually have that discussion about what are we gonna do next, which to me is still very much a human being intervention for the reasons that you've just said, Tony. And, actually, for what you said, that professional piece. And when you have a professional, you have somebody who has experience in doing this, and it is their judgment and their, direction that a lot of our clients are paying for when you've got PMs and contractors in there. So, you know, from that perspective, what are your thoughts on, you know, how how claims and future decisions, how do they all come together? I think I think the first thing... And this is something that I know we've spoken about previously, Tony, Mick, on on a on a previous call. First of all, we need to stop businesses, organizations, clients, whatever, tolerating poor schedules. You know, those schedules... And, ultimately, if they want them to be able to support a commercial position at the end, then they need to be harder with that and make sure that it's a strong schedule. And it ultimately, it reflects reality. We we can't be scared of bad news. You know, we... People ultimately... If if they're gonna be bad news, bad news does not age well. And that's gonna be the start. Then you can look into the reports side of things. Reports are there to support decision making. They're not there just to provide a pick... Pretty picture. Just because someone's got a green dashboard doesn't mean a green dashboard can't coexist with a deteriorating forecast. Metrics behind them, isn't it? It's not just about people going into a meeting and quoting a metric. I was literally having this conversation with somebody in The States last night, about being in with... In a in a performance in a performance review and, a contractor, like a project director from a contractor quoting SPIs and plans versus actuals and then just moving on straight past it. And the numbers... I'm not interested in the numbers. I'm interested in what are you doing in light of those numbers. Now that's the key. If you're not... If you're going to quote the numbers, expect some pushback. I wanna know what are your mitigating actions? What's happening with the bowel wave of activities if you're running late? Why why are not... Why are none of your interim milestones moving? I mean, I know. I know because it's probably not linked properly. You've got hard constraints in there. But that's the real that's the real thing for me. It's about having something robust to start with, getting good data coming out of it, and then being able to do something with that data to, you know, to make better decisions with. So just to add on what Richard said, I think it I think it starts... Like, it's like a a project, like a building. It starts with the foundations. Planners gotta be well trained. They've gotta know their... You know? To just... To me, there's planning engineers and planners. Planning engineers started in tools and new construction that, you know, they've got construction degrees, etcetera, and then you get planners. And there is amazing planners out there that aren't aren't on the tools and have never been... You know, got a construction degree. But it's knowing the basics. It's having that curiosity. It's been willing to challenge. It's the project teams willing to be challenged. The amount of places I've been where planners have been looking at their programs, when there is an issue, they're almost fobbed to the side. There's other places to use planners to try... Move milestones around and input costs, so I started trying to train the planners to look at the subcontractor programs and look for challenges and opportunities. An example we see is thirty one days on one... Thirty three days on one project. If you're looking upwards of a £100,000 saved. So when we get that, it's planners better trained, know what to do, know what they're looking for, supporting them. It's the team who's willing to accept the challenges from the planners. Just before, there was a while ago... I've been speaking to the client. The client was brilliant. Really good conversations, and I found out an issue about the cost and about inflation and price rises and I raised it to one of the teams. And the director said, okay. Thanks. But what does cost and what are these price changes have to do with planning and the program? And I went, right, that just shows your lack of awareness because everything's intrinsically linked. The program's linked with cost, is linked with risk, is linked with construction. And if if people... If if the planners with the PM and the cost of the cost slash commercial and technical director during design phase or construction manager, that's your core team, and you should be able to monitor and measure everything that's going on. And then, like Richard said, project controls have gotta have the teeth. They've gotta have the ability to challenge when they're finding stuff starting to come on the iPods. You know? I had a pro... Project that was point nine or point point nine nine or point nine eight for months. And I said, well, you're losing 1% of time every month. Everyone's celebrating point nine and point nine eight after ten months that was being reported against the previous program, the last month's program, not against the baseline. I said, you're losing point... You know, 1% of your project every month, and. people weren't... They were just saying point nine nine is good, but they weren't understanding why your project's slipping. And it's... You know, after a few months, you've slipped 5% of your time. So that's again... And it's the planners. The planners ask the questions and challenging and asking, but it's the teams letting the planners do it. The amount of times I've seen planners raise project and problems time and time and time again, and they get worn down and then they stop asking questions. You know? So it's the teams recognizing the planners, a key person within teams and the program, but that the team owned the program, the planner's just the the person who helps compile it. The team owned the pro... Program, not the planner. So we are eight minutes for the end. So I'm gonna kind of jump in here, and I've got three questions for you guys. But I do want to kind of just frame it all a little bit. But before we go, we do have a button at the top of the screen that says talk to an expert. Expert. So if this conversation is interesting and you want to continue that discussion, press the button. If this has raised any particular questions that you want to discuss, we're more than happy to. That also includes, the chaps have also said that they're quite happy if anybody wants to reach out to them on LinkedIn to consider and continue, the discussion. And there has been a lot in the discussion today, but I think one thing comes through really quickly that a claim doesn't suddenly just become an issue when it lands. There are early warning signs, whether or not they are data related, golden thread related, or simply kind of conversations that people should be having and aren't having, or giving enough time to those discussions or enough professional credibility to those discussions. So as we close out, I want to thank everybody for joining us today. And I do have kind of like the one moment questions, for each of them. So, Richard, I'm gonna start with you. What is the one thing that people misunderstand about good project controls, and how does that potentially kind of weaken the claim for you? Okay. Well, I think people can can often... You can confuse project controls with just the producing and updating of schedules and reports and metrics. But they're just outputs. That's not the purpose of project controls. Good project controls is around understanding what that information, what the data is telling you, and then be able to communicate it honestly, and then being able to act on it while you've still got time to influence the outcome of that data. In a claim perspective, the claim can be weakened. I think when when the the team can produce plenty of reports, but they can't explain the assumptions behind those reports. They can't explain the change in critical path. They can't explain the decisions that were taken or the mitigations that they attempted. So the records they keep might show that the information was there, but not that the organization understood the data or they acted upon the data. So for me, good controls then. It's not about, reporting history more more efficiently. It's about enabling decisions, timely decisions, evidence based decisions. If the information that you've got, the data, doesn't lead to better understanding and subsequent actions, then it's not control. It's just administration. Great. Thanks up so much, Richard. So, Tony, what is the earliest warning sign that teams most, often ignore, and what should they do when they see it? So, okay, again, back to, sort of NEC and p six, etcetera, it's many have just focused solely on the critical path, and many ignore the near critical as well. But, you know, in variance, it's it's starting to get control of that early, and it's it's flagging it to the relevant people. And sometimes, again, I've had it in the past where I'll be flagging issues and design delays or issues, and I've ended up having to ring suppliers for things like P and IDs and control philosophies because someone, for whatever reason, didn't feel confident in doing it. So it's it's taken... Like Richard said, it's taken the action early because so many times, one place that worked, they were sending out an early warning two months after the event. I was like, right. You know the clues and the title. It's an early warning before they've... And the event had passed. So you come back to things like prevention principle. You have to give someone enough time to take action to mitigate that. You know, if if someone's on-site and it was, again, another project, they got a subcontractor to do a cable diversion, not the main contractor. The contractor put a bucket in the ground, had a cable, so they had down tools and said... And they were there, stand on-site for two and a half, three months. They weren't giving the clients notification. They were accruing calls for these people being on-site every week, so they didn't give the client the chance to prevent those costs accumulating. So it's it's all all of those types of pieces with the, prevention principle, good communication. Again, the amount of times I see communication, not not letting people know. But on the flip side, I've seen really good planners who are communicating and don't get listened to. Me personally, I communicated seven projects when we laid on a big project. I was told go away. I've upset a SLT. And then fourteen months later, the seven projects were then reidentified, and then they were consequently lost. So it's again, listen listen to... If you do... If you're lucky enough to have a good planner and good project controls in your... On your project, listen to them. And, similarly, if you're a planner, go and ask. Me, personally, I'd rather be told off for trying to highlight and help the project than sitting back and just reporting on a program. That's not planning. It's helping to drive the project to delivery overall. Great. Thank you very much, Tony. And then, Mick, we will finish with you. Obviously, we want to avoid the claim. Okay? So before we... We we we want perfect utopian world projects on time, on budget, or better. But if there is one thing that every client, contractor, project director could or should do differently tomorrow to avoid that claim, what would you recommend? I think, first of all, what strikes me is how much agreement there is about what good looks like. Disagreement tends to be whether anybody manages it under real delivery pressure. So one thing I'd do differently tomorrow, is not a better claim process. It's this. I'd record decisions you did not take. So every organization records what they did. Almost nobody records what was proposed and what was refused. So So somebody said in week six that a sequence would not work. Somebody asked for a second crew. Somebody put a forecast showing a date nobody wanted. If that sits in an email that got deleted, then the author moved on. Then eighteen months later, it didn't happen. You haven't got the evidence. So three practical versions depending on where you sit. If you're the client, when you reject a program... Write down why. Rejecting a program because it shows a delay is not a reason as as we all were from NEC. And in two years' time, that will be the most expensive sentence you need to write down. If you're a contractor, put on the early warning register as recorded, not as an administrative task. Date it, name who raised it, name who had the authority to act on it, and record the answers, including the times where the answer was no. If you're a project director, ask one question at your next review. What did somebody tell us that we decided not to act on? If nobody can answer that, you don't have a record. You've got a narrative. None of this is glamorous stuff, and none of it is just a tool. The word that makes a position defensible happens long before anybody knows that they actually need it. And the thing that collapses most often under scrutiny is not the program. It's the gap between the moment it was known and the moment it was actually acted on. So changing the data does not change the outcome. It only changes when the organization finds out. And and that's. me now. Back to you. Wise words. Well, thank you all for your time today. We did talk about the talk to the expert button, but we will be at Project Controls Expo. Deltek will be on Stand 31, and Mick will be delivering our speaking session. So if you do, attend the Project Controls Expo, which will be next month in Wembley, and you do want to, talk further or you want to visit Mick's session, which will be on the second day, we will be talking about these and similar type issues and solutions, in our... I think we're in the claims track. So feel free to stop by, say hello. We'd love to continue to the discussions. Thank you very much. Thanks, Thank you, Yvonne. Thank you. Bye. everyone. Bye.