Welcome to this three part series on actually managing the risk under NSC, uh, using nPlan as a tool to aid you do that. Um, before we get going, I'll briefly introduce the three protagonists. Uh, there's myself, Doctor Jon Broome. I'm an independent expert, uh, on NEC. I've got 25 plus years consultancy and training experience. Uh, and as you can see, author of, uh, various books on NEC which have sold rather well, um. I've actually got 30 years experience on NEC. Five years. Were researching it under one of the co-instigators of NEC. Very early on. Professor John Perry also happened to be the first investigator of risk management in construction. So I'm sort of grounded in that as well. Uh, we're joined by Nick Williams, who's uh, the commercial director of nPlan. Uh, he actually has a degree in psychology, yet somehow ended up working as a commercial director in construction. Um, and we're also joined by Richard Bendall-Jones, who, like me, is a fellow of the association, uh, for project management. Originally a project manager in construction, he then became a risk analyst. Strike manager before, uh. And I hope I'm not putting words into Richard's mouth, uh, becoming, like me, rather cynical about probabilities and impacts. Uh, being subject to quite a few cognitive biases. And therefore, there's the garbage in, garbage out syndrome. And as a result of that, he's ended up working for nPlan. Uh, so moving on. Uh, this session is an introduction, uh, to nPlan and an introduction to the first program and how nPlan can potentially cause. Let's see, uh, help project managers, contractors, professionals, uh, get the first program. A good first program accepted. Before we get going. How did this series come about? Well, the team that's us three did a previous short video with the audience interaction. We thought that went rather well. Um, but we wanted to discuss the application of plan to any C contracts in a more detailed manner. Um, so, uh, Nick and I arranged a call, uh, and it was meant to last there. Well, but I said, well, if I'm going to not exactly endorse the project, but have my name associated with it, I want to. I've got a reputation to uphold. And I want to make sure this this isn't built on shifting sands. So I asked Nick quite a lot of questions. And as a result of that, we didn't start doing any planning. We had another session, uh, which Richard attended because of my detailed questions, and we still didn't do any planning. And then I think it was on the third session that we actually started to plan out this session. So and we thought, well, if I'm asking those questions. Perhaps those questions are of use and interest to wider people, the wider audience about does this thing have legs effectively? So what would have we done? We've divided these three webinars into two sections. Effectively there's the application to NEC contracts. And then the more fundamental question and answers on how nPlan works. Remaining two webinars. We do application to NEC and then those more detailed questions. Uh, second in the second of those part of those, this one, we're going to have an introduction to nPlan first. Then I'm going to introduce the programing provisions of the NEC. And then we're going to explore how any plan can potentially help, uh, professionals get a good executive program in place early on. So with that, I'm going to hand over to -Nic. I think it is. -Thanks so much, Jon. So, yeah, um, I'm guessing that some people might have heard the name nPlan. A lot of people will have heard the name Jon Broome. Uh, but for those that had heard the name but didn't know what we do, uh, we felt it would be prudent to give you a little whistlestop on what nPlan is why we exist, what we do and how we help people doing what we do. So we were founded, uh, just over six years ago. Um, we're a UK company, but with increasingly a global presence. Um, we were founded because. The company had looked out and seen a world that, quite frankly, hasn't been and still isn't successfully delivering large projects. They're being marred by costly overruns. Um, budgets are getting exceeded dramatically, and we don't like that. We wanted to to live in a world where, um, the, uh, ambitions to build mission critical infrastructure, the stuff that affects our everyday lives aren't hindered by our understanding and ability to tackle risk. And that wasn't just in nPlan that saw that we've had a lot of investment from different places, including the likes of Google Ventures, uh, of GV, formerly Google Ventures, who have supported us in our growth, which is accumulated a lot of customers from across different spheres. We've had anything from energy through road, rail, prisons, hospitals, uh, utilities, the contractors that serve all of this. If it's in the built environment, there's a good chance that we've worked with them. We're growing at quite a pace. And that pace has meant that the core of what we do. Um, has been growing, too. We've got the world's largest dataset of past construction projects. Uh, and those projects have been accumulated from across this vast customer base and from others. And we use that tremendous array of experience to train an artificial intelligence, uh, to forecast and forecast the risk, specifically in target schedules. So we're using the the world's hindsight to provide project foresight, where we take in the schedule files, the programs from our customers, and we use that trained AI model to help our customers understand how long the project is going to take so that they can set the right expectations with often a myriad different stakeholders, so that they can understand the likelihood to hit milestones, which is really important in the context of NDC. And most importantly, what they can do to both, um, achieve and exceed the expectations that were set at the outset by best managing risk. And it's a two sided coin. Um, to seize the opportunities that I see in front of them to improve the overall project outcome. Now, that concept is enshrined in in two different, uh, projects in the implant suite. We've got nPlan Insights, uh, which is the project centric tool and nPlan portfolio, which uses the same engine room that elevates past the project and up to the portfolio level. And instead of diving into to the weeds on an individual project that's looking to identify the problem, children project, uh, within the portfolio and the systemic risk that exists. That has a number of different applications. Uh, depending on where people are in the project life cycle. It starts off, we pick up the baton, uh, at the point of business case assurance, when people are looking to understand the deliverability of, uh, a project, uh, so that they can get it through the various different governance gates. And then they go out for for market search. And at that stage, we can, using our independent assurance, um, and working both client and contractor side to create a common currency and risk and transparency across the divide. Um, help people to best prepare their bids to ensure that they're bidding themselves into the black and then from the client side to evaluate those with, uh, an impartial apples with apples comparison. And then once final investment decisions have been taken, project really commences. Construction start, shovels hit ground. That's when we go through an iterative basis to help people really understand the monster risks that are going to derail that project, and what they can actually do about it, to to solve for those and to stop the risks becoming issues. And we do that across the board. So commercial buildings, oil and gas, heavy infrastructure. As I said before, the built environment is home territory for us. And we've helped so many different customers achieve their goals in managing risk better. Hopefully that gives everybody a picture, um, so that we can tee up the rest of the the video series. Here we go. Back to you, Jon. Okay. Thank you. So accepting the first program, which is how Richard will then say, well, this is how nPlan can potentially help. So why do you want a program in place early on? Uh, essentially, so that everyone can have their best foot forward. Uh, here are three reasons to have a good accepted program from day one. First of all, everyone has an agreed baseline to work from. So not only does an independent check by end plan by the project manager give the contractor some assurance that they're going to be able to do what they're going to do, but projects are interactive, uh, activities, endeavors in that in to enable the contractor to do what they've got to do. The project manager, the supervisor, the client, the others involved in the project might have to, well, have to do stuff by certain time. So if everybody knows what they've got to do, then the contractor can do what they've got to do better, more efficiently. That's both in terms of avoiding, if you like, uh, problems, issues, risks, etc., which might materialize into early warning or uh, become early warnings, uh, and then uh, materialize. But it can also be the opportunities, the how can we advance the program, etc.. Um, it might surprise people that in contracts, in projects, things happen and in any see speak compensation events happen which are client owned risks. When I did my research, it was quite evident that those contracts where they had had good upfront discussions, fierce conversations to understand the program when compensation events occurred, they were so much easier to evaluate. It was more amicable. It was more, more constructive process. Uh. And it was a faster process. Now, if you're a contractor under a price based contract, that means that you get your money in for the the compensation went faster. And under any contracts, it means that faster settlement of final account. Because if you're agreeing compensation as the project is progressing, then the final account is going to be there at the end. And it also means that updating the program, because early warnings have happened on whoever they fall, whether it's a client risk or a contractor risk. Stuff goes faster. Stuff goes worse. Updating programs became a lot easier again when there was a good program in place at the start of the contract, what you didn't want to do is start looking at it, as some project managers did three months into the contract when problems had occurred, and going, oh, I disagree with that. In which case, quite understandably, the contractors came back and said, but you've agreed to it for the past three months. Okay. So, uh, what does the contract say? So next slide please. So briefly the programing provisions under the NSA. What does the contract say? The first accepted program is either referenced contract data part two. That's the bit the contractor fills in with their bid, their offer, if you like. And if you're in a framework agreement and as a client, you're saying it's your term providing we can agree a prices. I absolutely see no reason why you can't reference the program into the contract from the contract data, and you have a program in place from day one. In fact, I do not see how you can arrive at a meaningful prices or prices you have confidence in without having a agreed the program if you like, because prices come from use of resources and the cost of those resources in a competitive environment. Having given one contractor the nod. You might then work like crazy before you sign the contract to have that program referenced from Contract data. Part two, providing you are happy with it as a client stroke project manager. If that program's not referenced there, it's submitted by the contractor within the period stated in contract data. Part one. Contract data. Part one is the bit the the client feels in and hopefully accepted by the project manager because it complies with the requirements of the contract. The contract gives four reasons for not accepting it. The first reason is it's not practicable, which generally relates to method and sequence. So logic. But it could also relate to an individual operation. Uh, another one is it's got to comply with any constraints stated in the scope. So you can't work Saturdays. Your program shows you working Saturdays or you can't access VAR this route, noise levels, whatever it is. It's also got to be realistic. Show the contractors plans realistically, which relates to durations and what sits behind it. Resources. And it's got to show the information required in the contract. And there's quite an extensive list there. The three things I've picked out are it has to show float. So but most people probably know what float is but uh, I'll outline it. Um, float is essentially gaps between bars. I can imagine programing people going are right, but gaps between bars on a Gantt chart. That's during the contract. So, um, that is free float. So a gap between two bars is free float. And if there's a particular path of of, uh, along before that path becomes critical, the sum of those individual free floats is the total float. There's another type of float. And that's at the end of the contract or at the at the end of a series of, uh, operations activities, uh, where there is a completion date. And it's the difference between planned completion and as shown in the accepted program and the contractual completion date. And that's the terminal float. So the float at the end of the project is the terminal float. Particular or specific to what we're going to be talking about today is time risk allowances. So the program has to show time risk allowances for each operation. What are time risk allowances. Well, Martin Bonds who was the Co instigator of NRC many years ago, he was asked this at an NEC users conference. And he said A time risk allowance is the difference between best productivity and expected productivity for each bar. Now you can show it any how you like, but you need to show it. Uh, and so what another way of looking at it is the natural variability within a bar. So a good result you can achieve no time risk allowance to be used, an average of the result, if you like. You use the time risk allowance up a a a poor result. But you know to some extent poor it can be very poor or it could be a little bit poor. If I run the time risk allowance related to the amount of time, the length of a bar related to how much float between the bars is, is resources. And again, the program the NSA requires that resources for each operation are shown. Relating back to the previous slide. Good things come from a well understood and accepted program and they can be different. Um. Note the words accepted program it it's it implies it's not going to be a perfect program. It's an acceptable program. Um, and it's got to be well understood. So the project manager could just tick it and say, oh, I've accepted it, but that's not good enough. It's got to be well understood to be a good project management tool. And equally poor stuff comes from not having a good accepted program or no accepted program in place as in updating it becomes hard. Agreement of compensations, etc. and there are several sanctions in the contract to encourage the contractor to have get it acceptable accepted and to submit it. Um, I won't go into those. Uh, I could drop lots of good practice tips, but perhaps the biggest one is don't as a contractor, just throw it over the contractual fence and say, accept that. Sit down with your opposite. Uh, party talk them through it, deal with queries there, and then agree adjustments there, and then add in the justification to the formal submission from that conversation so that when it is submitted for acceptance, hopefully it's a couple of days for them to go over it, rather than two weeks of ping pong information backwards and forwards. So with that, that's just a very quick run through of the program and provisions of the NSA. Um, back to Richard. Richard, based on what I've talked about, how can nPlan help the contractor prepare the project manager, evaluate, perhaps do it together, cooperate to more efficiently so faster and more effectively so you get better more at it. It's a value adding process. Get a good accepted program in place early on in the contract. Thanks Jon and hi everyone, -I'm Richard. -Um, so I'm going to take you through a few features that we have in nPlan insights product to relate to some of the points that Jon has made there about a well understood, uh, program and also one that takes into account risk using the concepts such as float and time risk allowance that Jon mentioned before. So I'm going to show you a few features here. Now, quite often in this environment, um, there will be schedule integrity requirements in the contract. So in the insights product, a user, once they've uploaded their schedule, their program, um, they can interact with the schedule integrity of their schedule. So for example, if, um, a schedule is not permitted to contain negative flight negative lags, a user can interact with that. Or similarly they can look at things like start to finish links. I don't want to get into the technical element of planning too much, but ultimately different attributes of the schedule that a planner or a project manager can discuss and decide whether they want to rectify that. And that is with the purpose of having a schedule that meets the requirements of the clients. And if a user, uh, wants to do this, they can download it as an Excel file and have their conversations that way. So this is about understanding the structure of the schedule and making sure that it meets those logical requirements. But as part of understanding, um, the schedule as a whole, a project manager might want to understand, does the logic go in the right place or does the schedule contain the correct scope? So I'm going to show you a feature we have called driving paths. So if you look at this, this is essentially a network diagram of your schedule. And the lines that are blue or darker blue or thicker. They show where the risk flows through the schedule using the data from the data set that Nick mentioned before, but also, um, the machine learning and the AI that understands how schedules work. So what a user can do is they can look at their critical path. So that is the part of the schedule that has no float in to understand according to their plan. Where are the critical activities, um, so they can hover over different activities. They can highlight them in order to understand, um, where that critical path is. And they're also able to aid their understanding of their schedule by looking at where these critical activities flow through, um, the different scope parts of their schedule. So for example, here, um, you can see that the critical path is going through, um, their civil scope works quite a lot, um, and on a couple of verges. So this is a highways project, but also through cabling as well. So a project manager can look at that and say, hang on, does that make sense to me. Do I see that as realistic. Um, do I see that as practicable as a schedule? Is that what I want to communicate to my client or or something like that? Um, the dark blue lines, as I mentioned, highlight riskier areas of the schedule. So areas that are more likely to be delayed and impact any completion milestones in the next video. We'll go into that a bit deeper in terms of what that means, what we can do about it. So once we've understood the schedule and the principles behind it in terms of, you know, is it the right level of quality that we want to submit or agree? Um, you know. What do we want to do about? How can we allow for risk in that submission? So as a result of uploading the schedule and running it through the AI and the database of activities we have, we're able to create a forecast. Um, that forecast considers, um, what might happen if things go really right or things that go really wrong. So as Jon mentioned before, quite often as a requirement under NPC, um, there's a requirement to create an element of bloat so that free time, um, to allow things to go right or wrong on projects because things happen, as Jon mentioned. Um, so here on this dark blue line, you can see, um, at what point? So when we talk about P80, we're talking about the 80% confidence date, um, for the schedule. So if we wanted enough time 80% of the time, then we would highlight that 80 point. So the planned end date, as Jon mentioned, you know, that kind of, um, ideal productivity point would be, um, May 2025. And to have 80% confidence it would be March 2026. So in that situation, you would want to communicate a time risk allowance of ten months. But if you wanted 50% confidence then that would be lower. So that would be six months in total. So you can do this for the final milestone. You can do this for interim milestones. If you wanted to create free float, as Jon mentioned before. But all of this is here to aid project managers and project teams to do all this objectively and without the need for workshops. And therefore project teams can use that time, um, to to manage risk on their projects or to improve quality and things like that, and ultimately to help them to get even better at their job. So there's a quick, quick rundown on some of our, uh, some of our -features. Jon. -So, Richard, if I was a project manager and I've got to evaluate this for this program for realism. Um, and I could basically do a p. A patty, a P50 or whatever. I could go, blimey. Your program to meet plan completion is based on a P20, as in, there's only a 20% chance of it achieving it. Mm. Um, if, as Martin Bond said, it's based on, uh, time risk allowance is the difference between best and expected, it should be at least 50%. Um, so there there's direct reasons for not accepting it. But even if it was P50, you might want to tell the contractor, actually, you might want to look at your scheduling because you've signed up to a contract, you know, which says you've got to deliver by that completion date. And actually when I evaluate it. It's. It's looking unlikely. Yeah. He's right. Reprograming. Well, as a contractor, I want to know that early. Ideally before I even submitted it to a contract. Uh, project manager for acceptance. Ideally before I even bid -or submitted my bid. -Yeah. That's right. You can look at it from either side of the fence. So as a contractor, you can use this to say, actually, what is my level of confidence of the schedule as is? And therefore what might I want to add to the schedule in the form of a time risk allowance. And from a client perspective, you can look at it as an assurance exercise to say, I've received this, this program, how much confidence do I think I should have in it? And that can enable that collaborative discussion to say, how are we setting this project up for success, especially in in a collaborative neck environment where everyone wins together, everyone loses together. So it's about setting up those chances for success. Okay, thanks. I do have some extra questions. But I'm aware that we intend to ask them in subsequent sessions, so I won't ask them now. Um, but anyway, so, um, I think with that, uh, let's just conclude, um, so, uh, I wrote these before based on our conversations. Um, I let's see if anything's changed as a result of this webinar. Um, so for me, um, nPlan cannot replace a planner because it needs a detailed program to analyze. So a programmer has got to do the work in terms of. Creating the, uh, the work breakdown structure to put in a program, creating the links, putting in the durations, etc. and so on. It also does not replace a project manager taking time to understand the program. Um. In particular so that they know what they're their clients, the supervisors, others commitments are, in order to avoid compensations happening and enable the contractor to start work and proceed -with it efficiently. -Richard. -Nick, do you agree with that? -I mean, um, personally, I do, um, when people talk about AI, people are often concerned about people being put out of jobs and things like that. But for me, I see technologies and planners helping people on project teams to do their jobs even better. So, um, working on a project team is very hectic. There's always lots of things to do and nPlan helps people to do that faster and more objectively. So that's how I see it. Jon okay. Nick, any any thoughts? -Yeah I agree. -At the front end we've got to have the the planner creating the schedule because that's the very basis of what we do. Um, we've got to have a project manager to, um, to get the best possible appreciation of the impact that everything is going to have, whether it's the plan, the risk, um, everything that sits around that, the impact that's going to have on the project. And then at the back end, it's an AI. It's not going to be able to take action on things. It needs human intellect and human hands to do that. So if the plan needs re sequencing on the back of it, the plan has to come back into the action. Project manager needs to make calls and engage with the um, with the different parties involved. And the risk manager needs to to talk to the team about how best to mitigate and seize the opportunities. So now it needs people at every step of this process. It's the same. So that's sort of stolen my thunder on the last two bullet points. I think for me it provides comfort for both the contractor and the project manager. The durations are realistic and the logic is correct. Schedule integrity, I think, is the words that that Richard used. Um, uh, and in doing that, it helps professionals rapidly focus in on the areas of opportunity and risk where human beings can add the and spend their time adding value rather than doing the analysis. Because what I can do, what computers can do, is analyze stuff a lot faster with a much bigger database. What they can't do is they can't be creative, they can't get out and do the actions, etc.. Um, so. Does it help? -Yes. -To summarize, I think, um, does it replace. Absolutely not. Um, I hope that in this interactive session has been, um, informative. And I hope you'll join us for our next session, which, as it says at the bottom of that slide, will be on early warnings and how, um, nPlan can potentially help us identify early, early warnings and, uh, look at the consequences and manage the project better during the contract. So with that, thank you very much. See you -next time. -Thanks, Jon. Thanks, Richard. Thanks, everyone.