Plan, Don’t Panic – Part 2

Originally aired on 4/9/2020

41 Minutes

Request A Demo

We hope you enjoyed Part One of our livestream series, Plan, Don’t Panic. Here in Part Two, we advance the conversation even more!

During this episode, Dan and Paul discuss how technology is helping us build better plans and mitigate risk despite the “new normal” of so many in the industry working remotely. 

Part Two includes discussions on how:

  • New methods for identifying inputs and running simulations drive more accurate results
  • Simplified capturing of inputs and improved simulation methods has led to more reliable risk-adjusted plans
  • You can do this all from your home office

TRANSCRIPT


Paul:

Hey, Dan. It’s good to see you again. Looks like we’re back at it one more time.

Dan:

Hello, yeah. Here we are, week two of three for the session.

Paul:

Yeah, and actually week number four from work from home. We’re continuing to see technology helping us to adapt to this new working environment and new world. In that vein, we thought the last week was going to be a small gathering, but ended up with literally hundreds of participants, so it might be worth letting everyone know a little bit about ourselves and history before we jump right into it. Before you start, you’re my friend and we’ve been doing this a long time together. You’ve spent, we know 20 years innovating in the project management space.

Dan:

Even back in my university days, I had this fascination around scheduling and planning and I’ve always had a strong passion for technology, so yeah, I think absolutely. I think, it’s always been my belief that project failure, it really isn’t about poor execution. It’s about the fact that as an industry, we’ve been utterly rubbish at forecasting the future. We’ve been overly optimistic; we’ve been overly aggressive.

Paul:

We are taking questions today and if you guys want to chat with us during the live stream session stage, feel free to use the chat function through the GoToWebinar. In that vein, we did have a question that came up last week after the fact and it was related to owners versus contractors and risk and risk workshop and the questions was really around can we create a model that accommodates both? I mean, I know you have an opinion on that, Dan.

Dan:

Yeah, so my not so humble opinion is no, you can’t have a blended opinion or a blended view of risk on a project. Projects have these two stakeholders, primary stakeholders. You have the owner organization that’s wanting the asset built or developed, you have the contractor who’s responsible for actually building the thing, and of course, during that project life cycle, you’re going to have very differing opinions around what is your risk tolerance and the associated risk exposure.

Paul:

Yeah, it’s interesting. When we talk about, I mean, we’ve worked with owner organizations. The way I’ve always seen it in working with them is they look at the project in the context of a cost project and how quickly can I move it from a cost bearing project to a revenue generating project. As a result, it makes them, again, in our history, much more sensitive to the schedule driven risk because the longer I delay first production on an energy project, for example, the longer I’m delaying the potential revenue on the project. Very, very sensitive to schedule on the owner side.

Dan:

Yeah, I mean, it’s interesting. In many ways, the CAPEX project piece of the project life cycle, of the asset life cycle for the owner, it’s really a very small part. The project may only take two, three years to execute and deliver, it’s the remaining 20 years of OPEX that the owner organization cares about whereas, conversely the contractor, quite rightly so, they come in, they execute the project, they move on to the next project on day one of OPEX operating. Their focus is, okay, well how much profit are we going to make on this project. They don’t take into account the full asset life cycle cost and value prop as well.

Paul:

Right. It’s really that watching closely that contingency and paying attention to the fact that, hey, when will that contingency potentially start to erode the margin for the profitability on my project? We got a lot of questions last week as well around some of the just basic modeling and one of them, to make it simple, and we created a simple example for it, was how does a 10 day risk event that’s identified by a member of the team, how does that actually impact our project from a risk perspective?

Dan:

Yeah, so one of the attendees said, “Well, this all sounds great, but at the end of the day, if I have a risk event and that risk event is 30 days, isn’t that just going to impact my project by 30 days?” First glance is you might think that, but in reality, it’s actually not the case. The best way of answering that I think is to… I’ll try and go through this without… you’re going to think I’m a little crazy, I guess, but think of float as your anti-risk. Right?

Paul:

Yeah.

Dan:

Float is wiggle in the schedule. My example on the screen, at the top I’ve got a very simple CPM schedule, two parallel paths, task A and B, six days, four days, give me a total duration of 10 days. That’s your critical path through the project. The second part, task C, has eight days of work. The net result gives you two days of wiggle, two days of float. In many ways, float is your friend, because it’s the forgiving amount of time that you can afford to give up before that work becomes critical and pushes the finish date.

Dan:

When you add risk and uncertainty into the mix, as we have in the bottom, that critical path, that task A and B, let’s just say for example, there’s some uncertainty on the first task, so we don’t know whether that six day task is six days or maybe it could go as much as eight days. In a similar manner, task B, that four-day task, may be exposed to a very significant risk event, which actually, in the example here, the exposure of the risk event is greater than the duration of the task itself. The net there is, when you summate all those up, you get 17 days. Now, again, you might think, “Well, okay, my project is now 17 days in duration.”

Dan:

One of the fascinating things about project execution and risk and how we mitigate that is let’s take that noncritical path activity, task C. It may be prone to not only things like duration uncertainty, driven by scope creep or design growth, it may also have a risk event that may attack it and eat that initial two days’ worth of float to give a net 20 days. Well, that critical path then jumps from the task A, task B path, to task C, so this concept of float erosion and risk and float constantly fighting each other, and not only that, the result in jump in the critical path I think is one of the, again, one of the fascinating insights that we can get from a schedule risk analysis.

Paul:

I would agree and one of the resounding comments coming out of last week’s session was they’d like to see how this is really done. Can you jump into a live example and we’ll play a little risky on our site and we’ll see how the model this stuff?

Dan:

All right, so what do you want to know?

Paul:

All right, so I think first and foremost, can you just explain the basics of the Monte Carlo simulation. Right? Let’s just get that out of the way.

Dan:

The basics to you, Paul, no problem. What we have on the screen here is a traditional CPM schedule. Again, this could be developed in really any scheduling tool of your choice. Really, the important point to note here is this is your base schedule. It doesn’t account for risk and uncertainty, so really, it’s your best-case scenario. The concept of running a risk simulation in Monte Carlo and all that good stuff is actually very, very simple. The concept says look, for the durations in the schedule, rather than looking at them as a single point, in other words, a deterministic view, let’s look at the degree of wiggle. Remember, the concept of uncertainty and risk events that we mentioned a few minutes ago. From a modeling perspective, Paul, just a simplistic example here. On the right-hand side in our view, against the entire schedule I can say well, actually, I think there is a… maybe there’s a 10% upside in our ability to execute, so we can [crosstalk 00:08:27]

Paul:

[crosstalk 00:08:28] a little bit faster.

Dan:

A little bit faster, up to 10%, but conversely, it could take as long as 25% longer. Okay?

Paul:

Okay,

Dan:

The net result of that, if I just pick an activity here, the net result of that is a distribution. Because of that 10% under, 25% over, the computer is able to calculate a range of durations for each of the activities. Now, in the old days of risk analysis in Monte Carlo simulation, the computer would run thousands of iterations and come back with a range of outcomes based on if you run a thousand runs, it’s going to come back with a thousand scenarios.

Dan:

Now, we’ve actually moved a little bit beyond that concept and maybe we’ll get into that later on, but I guess to just close off on your question on Monte Carlo, as a result of those ranges, again, when we look at the total number of outcomes, let me just run the simulation here… we end up with what we call a risk histogram or a risk distribution. Really, Paul, the best way of reading this chart is to start in the bottom right corner where we have what we call P zero, you see that there? The 20th of June? Sorry, 20th of January.

Paul:

I do. I do.

Dan:

This is our absolute best-case scenario and then, everything in between, and all the way up to P100, showing our worst-case scenario of the second of November. Now, probably the most important thing about a risk analysis is this concept of contingency because contingency is the difference between your risk adjusted view of the world and your original schedule without risk. Typically, you and I, we’ve always pushed for at least a P75 certainty. Right?

Paul:

Mm-hmm (affirmative).

Dan:

The corresponding P75 contingency there is 84 days, so our original schedule date, completion date was the 13th of April 2021. Our risk adjusted schedule that we are 75% certain we can either achieve or beat, is actually the 6th of July the same year.

Paul:

The yellow line there is indicating what?

Dan:

Well, I was hoping you wouldn’t ask that because this used to be a leading indicator, but we’ve since realized that it’s actually not all that useful. What this is showing is this is the probability of a confidence of achieving that original schedule. In this example here, it’s saying we have a 30% chance of hitting the original 13th of April date. In reality, Paul, what happens is in very large CPM schedules, that probability actually diminishes very quickly. It’s less about risk and uncertainty and more about the number of parallel paths in the schedule. Use it but use it with caution. It’s really more of an indicator as to the complexity of logic in your schedule rather than how much risk you have exposed to you during execution.

Paul:

Okay, so I can see this. This gives me what’s my exposure at a given confidence level, all the way from best-case to worst-case, but how do you… I mean, so then what? Great, I’ve got a picture of what my risk exposure is, but what do I do about it?

Dan:

Okay, so again, first glance is you might think, well, in order for me reduce my risk or my exposure, I’m just going to focus on the critical path. Well, as per the little demonstration I showed you a few minutes ago, that isn’t the case, so the best tool to report that is what we call a risk driver chart or a risk tornado chart. What this shows, Paul, is of that 83 days, remember, that was our P75 exposure, 83-84 days there, we can see the drivers, the activities, and I think, again, when you have a large schedule looking at individual line items, it’s a bit academic. What’s more useful though is to be able to roll up through the WBS hierarchy and say, “Okay, looks like early site work and structural installation foundational scope. They’re the big hitters. A month and a half, a month, 20 days, so on and so forth,” but then even more than that, let’s roll up and take a step back further. It is construction, is it close out, is it procurement or pre-construction.

Paul:

Sure.

Dan:

This becomes super powerful work because now, I can see is it the early phase of my project that’s going to hurt me or is it the actual execution, and this case, it is indeed the execution.

Paul:

I get a sense of what my exposure is on the product and on the project, and then, I have the ability to hone in on the areas of the project that are impacting me the greatest.

Dan:

Exactly, yes.

Paul:

How has this changed in the last 20 years? What’s different now than the way we’ve done this because we’ve been doing this for a long time, as we said earlier?

Dan:

Well, the charts have got prettier, but now, on a serious note, we’ve actually made huge strides in both the analysis and the interpretation of the result. Probably the biggest difference, Paul, is originally when we started out doing this, we would run the analysis, just like I showed you in the in histogram. Right? It would give you the range of P zero to P75. The project team would then have to make a decision as to, okay, what confidence level do we want to march against. Well, in recent years, we’ve realized that’s a little bit backwards.

Dan:

What we’ve done, we’ve said, “Look, even before you start your analysis, pick a competence level.” This is sort of like your risk lens, so what this allows you to do, Paul, is you can say, “Okay, I want to view my project through, in the extreme case, P zero. This is the absolute best-case scenario,” or “I’m super risk averse, I want to know what my worst case scenario is,” or more typically, know during the concept select or through the FID or sanction, we’re going to march towards we want to know what our 75% certainty is, as an example. What’s so powerful about this now, Paul, is you set that lens, that P value lens, let’s say 75, and literally now, as we review the schedule, we make changes to the schedule, the Monte Carlo analysis, it’s real time. You don’t have to run that simulation anymore. It’s literally on the screen look, showing me. I can see as I walk through the latter parts of the construction here, we’re getting the increasing deltas both between… let me just pull it back up, again, both between the deterministic and the risk adjusted as well [crosstalk 00:14:59]

Paul:

Yeah, and I know one of the newer advancements made, and part of what we wanted to make sure we touched on today, was the application of AI, artificial intelligence, to this process. As you described me earlier as the guy that… I’m the humanizing guy, talk to me a little bit about what role AI plays and is it replacing human?

Dan:

Sure. What I showed you just now was the traditional risk facilitator mode where I would come in and I would assign the ranging. We did 90, 100, 125 and that’s certainly still a valid approach. Again, what we realized though is well, wouldn’t it be useful if the computer could actually assist in this process as well? The way we are implementing that today, we have this concept of a knowledge library, and again, I know in previous sessions, Paul, we’ve talked about capturing prior as built schedules and using that to import subnets, so on and so forth, but what we now have on the risk front is the concept of an enterprise risk register. Again, what I think is so useful about this, this can be automatically generated from all of the projects that are working in the scheduling environment here or you can manually import those historical risk registers or a knowledge administrator, and I know you’re very keen on this, can actually manually maintain this.

Dan:

To give you an example, we could say competing work in the fab yard, so this is a procurement related risk. We can add that risk and then we can subsequently go ahead and score it just like we have in the other risk here as well.

Paul:

You can become… Sorry, so it becomes part of our global risk register at that point and it does look like you’re also tracking… this is kind of cool. You’re also tracking how often this specific risk event shows up in a given project. Right?

Dan:

Okay. Yes.

Paul:

[crosstalk 00:17:07] that can be work in the fab yard have an impact on our projects and should we do something in the future to better plan around those types of risk?

Dan:

Yes. This is kind of, again, kind of turning a risk register on its head rather than just tracking risk. To your point, it’s just saying, okay, across the projects within our organization, how often, for example, is site access constraints becoming an issue? The software will actually track the projects that are prone to that.

Paul:

That’s interesting. Now you’ve created a risk event. Can you show me how this concept of AI helps me, like you built it into a knowledge library? Now what do I do with that? Does the AI engine help me?

Dan:

We created a risk event with regards to procurement, so if we go to steel fabrication and delivery, again, just to level set, Paul, here’s our uncertainty range that the risk facilitator in the workshop set by using that percentage range, but the nice thing here is then a participant can additionally decorate the risk model with a discreet risk event. What I think is, again, super useful here, you see this risk here, competing work in fab yard?

Paul:

Mm-hmm (affirmative).

Dan:

That risk has come from the knowledge library and the computer knows that it was a procurement related risk, we’re working on steel fabrication and delivery as part of our procurement and fab scope, so because of that, I can select it and then I can even choose to adjust the probability. I can say on my particular project, yes, the probability’s very high, schedule impact is 30 days, and the cost is no more than a hundred-thousand bucks. The computer will then actually assign that risk event, as you can see now on the bottom right, to my skill path and delivery activity here.

Paul:

That’s kind of a massive leap forward in helping make sure that we introduce risk events to the right area of the project, which is something that takes a whole lot of time in traditional risk analysis is trying to figure out where a given risk event is going to have an impact. Now, we can do it in real time.

Dan:

Yeah. I mean, for those of you that have gone through risk workshops and worked with us on risk modeling, you’ll know that this concept that we call risk mapping is just horrific and highly error prone. The process goes away now because the mapping is inherent because the risk was identified in context of the activity. Not only that, I can now apply that risk event to my model, and you notice that, Paul, a little toggle here.

Paul:

It jumped.

Dan:

Yep.

Paul:

Mm-hmm (affirmative).

Dan:

Gone are the days of having to run a Monte Carlo analysis in the simulation and export the file. It’s doing it in real time. Again, this is so useful in terms of getting the team together and starting to do what-if analysis. Again, if I go back to my entire project and pull up the range of distribution of outcomes, we can see now we’ve got our updated scope or, sorry, our updated exposure and if I go specifically back to say our fab and delivery, I can look at the drivers at a given WBS level and see those as well.

Paul:

Right. Right. Two things. One is, we talked about this concept of a risk lens earlier and I guess the other piece of it is, two, is we’ve got, yeah, we’ve got lots of risk events starting to show up within our project here. Can you change the risk lens, the value, the way in which I want to view the schedule, and can you see both risk events and that uncertainty as a result of that?

Dan:

Okay, so I think what you’re asking is if we apply or account for the risk events, can we look at the impact of those risk events through those differing lenses? Right?

Paul:

Mm-hmm (affirmative).

Dan:

Let’s try that. In the best-case scenario, and by the way, Paul, the red little subsections here, that’s the impact driven by the risk event versus the schedule uncertainties, so if we look at the best-case scenario, those risk events just don’t happen. If we look at the worst-case scenario, they absolutely, categorically do happen and then, again, more realistically, we go to say P75 and we look at the net result, and again, we pull up our drivers. Now, this is super powerful because what this shows is, again, not only can I roll this up through, as we did before through the various WBS elements, it’s interesting now, Paul, that previously, construction was the biggest driver-

Paul:

Now we’re getting hit by permitting. Huh?

Dan:

Well, we’re getting hit by permitting, look, and not only that, permitting is specifically getting hit by this permitting authority due to civil unrest. Interestingly, too, we have some opportunity in the execution scope here in foundation, so this is a… it’s a bi-directional, it’s called good risk in the form of opportunity and bad risk in the form of uncertainty and threats. This type of report right here is proving so invaluable to projects because it’s showing aggressiveness of schedule in the green, it’s showing the risk events in the red and the orange, and then the opportunity on the left, there in the blue.

Paul:

This is, this is great and interesting. One of the things that we continue to get questions on is around the randomness associated with traditional Monte Carlo simulations. Can you talk a little bit about that?

Dan:

Reluctantly. We used to say it was a fireable offense to use the word random in a risk workshop. Remember? The reason being traditional Monte Carlo simulation, the way it works is let’s just go back to the simple distribution on the right here. We’ve got 26, 29, 36, 37 on the range in there. We’ve got a boundary there. The way Monte Carlo works is think of filling up this triangle, Paul, with ping pong balls or lotto balls that are each uniquely numbered, and let’s just say that you fill it up with a hundred lotto balls, one to a hundred. The way Monte Carlo works is it randomly picks a number, one to a hundred, let’s say it picks 67, 67 falls on a certain segment in the triangle and it drops down and reads the duration.

Paul:

Yep.

Dan:

The thinking being you’re going to get a more frequent occurrence around the center of gravity of the triangle. That’s all great mathematically. I do think projects really did struggle with, okay, so we’re putting all of this time and effort and diligence into this model and yet, the whole damn thing’s based on a random number. We used to… I guess we used to try and avoid that discussion and then, what, probably a year ago, we said, “Okay, I think they have a point.”

Dan:

What we’ve done since then, we’ve actually come up with what we call a modified Monte Carlo simulation where thankfully, we’re not using random numbers anymore. The way this works is if I’m looking at the project through the lens of say my P65-

Paul:

Sure.

Dan:

… when the computer on this activity samples, it will actually pick the 65th percentile duration here, so it is algorithmically correctly picking an absolute value rather than this concept of randomness. I feel very, very thankful that we pushed against the status quo and stuck our neck out and said, “Let’s modify Monte Carlo,” which we absolutely have done.

Paul:

Okay, that’s interesting. We’ve gotten to the point where when we approach the whole Monte Carlo simulation thing in a more algorithmic manner, removing a lot of the randomness that we traditionally would get questioned on. What do you do now with this model? Can you take this scenario and make it a baseline?

Dan:

You can. There’s kind of an interim step. Typically, you would review the tornado chart that we were looking at earlier and you would look at mitigating those as best you can, but once you’re at the point of being comfortable with your mitigating scenario, then yeah, really what you want to do is risk adjust your schedule. Right? That’s what that this is all about. Yes, so again. We have the concept of pushing those inputs, whether it’s the risk events and the uncertainties, and actually embedding them back in the CPM schedule. That’s something that, for me, that’s just a natural last step, it’s closing the loop. Again, I think traditional risk analysis, it never really did that. It just stopped short. It was like, well, you’re going to be 84 days late. That’s not helpful at all. I want to mitigate my risk and then look at my risk adjusted schedule and re-baseline and march to that schedule. Yes, you can embed, or we call it flattening back into the schedule, taking into account the risk and uncertainty.

Paul:

Okay. Great. We’re starting to combine all of those together. Right?

Dan:

We are and, again, I think going back to my somewhat cheeky, but also complementary comment at the beginning, I come at this from a technology and algorithmic and simulation approach, you’ve been harping on for years, “Well, let’s not forget their human.” I think we’ve come up with a really good balance because we’ve got incredible computing power and we haven’t really touched on the AI stuff too much. We’ve got the computer making suggestions, but we’ve also made great strides on what you call the HI front. Right?

Paul:

Yeah. Making it easy to start to capture inputs from our team members that aren’t risk experts, that aren’t CPM planners and schedulers, that don’t necessarily care about or understand the difference between uncertainty and a risk event. They just consider things that may impact their project. Right? Did I get a good bid from my subcontractor, did I base my durations on means and method, do I have confidence in that plan? Then, by the way, is there the potential for something external to my project to impact? They think about it within that way. I think we’ve made it very easy for team members to provide that type of feedback now.

Dan:

I guess you want me to show you that, too. Right?

Paul:

I do. I wanted to walk… so, we talked through the simulations, but [crosstalk 00:27:55]

Dan:

I have a perfect PowerPoint for this.

Paul:

I want to see how we captured the inputs to the model. We did the simulations, but how do we, taking a step backwards, how do we get the inputs to the model from the team?

Dan:

I just realized our little icon in the middle here with the three people, we should probably update that to reflect a more appropriate social distancing and then you won’t feel like they’re all-

Paul:

Just [inaudible 00:28:18] they’re not six feet apart.

Dan:

They’re breaking the six-foot rule there, aren’t they? Yeah. All right, I guess what you are forcing me to do is show this concept of human intelligence.

Paul:

Yep. Okay, so how does someone in this instance, right, if I were a team member, a stakeholder on a project, I don’t build the plan. I traditionally would get a link in an email. I’d click that link and I would come directly to a simplified view of the schedule that presents only the scope of work that I’m responsible for. Right?

Dan:

Yeah. This concept actually came about from thinking about, believe it or not, employment survey. The idea here is that, again, to your point, rather than baffling a team member or a field execution practitioner with the wonders of CPM scheduling, and asking them to review your Gantt Chart, what we’ve done here is said, “Look, this is the scope to which you are associated and responsible for. All we want you to do is review the durations and categorize your comfortableness with regards to are you comfortable in terms of yes, this is achievable or no, I need 10% more time, 25% more time to be extreme, Paul,” or you could say, “Hey, this is just so out of whack I need as much as 50% more time.” You can go in the other direction as well.

Paul:

Okay, so I could say, “Hey, I might need as much as 25% more time for all of that structured scope that you just scored.” Okay.

Dan:

I mean, you could look at some of these and go, “Well, gosh, the steel deliveries on that second floor, part of that will be delivered with floor one. We really don’t need that much time, so we can pull it in the other direction.”

Paul:

By exception, I could say, “Hey, I’m much more comfortable with this area of the project. Yeah.”

Dan:

Yes.

Paul:

Okay.

Dan:

Yep. Again, just tying this back to risk, team members can even come along and say, “Risk of late delivery due to logistics, resulting in 30-day delay.” Right? Again, very easy for a team member to come and not only identify but quantify that risk with regards to cost and schedule. Okay. Again, that risk then automatically ends up in the project risk register. Okay, so we’ll see that in here with that risk there.

Paul:

Okay.

Dan:

Then, if we go back to the interactive schedule review, we’ll hone straight in on that construction scope and that team member was working on-

Paul:

In structures, yep.

Dan:

It was structure. There’s the steel deliveries’ activity. There’s the risk that they identified and if we click on the human piece there, this is… in fact, you remember I said actually we can do it in less time? You see that?

Paul:

Yeah. Yep.

Dan:

Whereas the other team members are still pushing back and, again, if we walk those structural activities, we can choose to adopt the team member contributions. Again, I think one of the cool things we did here was say, “Look, we’ve got multiple team member contributions. We’ve got Dan, Alan, Ben, so on and so forth.” Well, those multiple points, surely the computer should be able to create a distribution from this point. That’s exactly what it’s doing, Paul, to the point where if we exclude Dan’s opinion, or any of the other contributions, you’ll see the risk distribution updating automatically.

Paul:

Now, the basis of my risk model, right, the inputs to the risk model are truly the opinions and feedback from the team. That’s very powerful. That’s capturing a team member feedback.

Dan:

Yep.

Dan:

Sorry, Paul. I get quite excited about this. I showed you an example of an individual activity. Well, bear in mind, those team members, they were reviewing whole WBS chunks. Right?

Paul:

Sure.

Dan:

You can apply that human intelligence to entire sections of your schedule, which again, is so huge because now, you’re getting buy in into the entire execution scope. As you can see now, my risk model is entirely driven by that human input and, again, we go back, we run the analysis real quick. We’ll be able to see the net result there. Look at that, now much more… Wow, I was going to say pessimistic. It’s not more pessimistic. It now, taking into account the concern that the team members have on that completion date, this is more realistic.

Paul:

Right, right. It’s, to your point, it’s not an overly optimistic plan. It’s something that’s much more likely to actually happen on our project. That’s getting the human component, getting the human input into the risk model in a much easier and faster way than we’ve been able to do in the past. How does that start to play back into the AI bit that you touched on earlier?

Dan:

Okay, so yeah, kind of the third piece in the puzzle. Right? Let’s take our steel deliveries activity again. We went from me, the risk facilitator, saying, “Hey, we might be able to achieve this in 10% less time, but as much as 25% more time.” We then got smarter, if you remember, and said, “Well, no. We’re going to take into account the contribution of the contributors.” Right?

Paul:

Mm-hmm (affirmative).

Dan:

That’s all very well, but interestingly, the contributors, the net of their input is actually saying we can do this in 17% less than the plan suggests.

Paul:

Okay.

Dan:

Okay. That’s great. It still up to you as the facilitator to go, “Okay, let’s go with that,” until now, I can look across to the left here. You see this little AI nugget here?

Paul:

I do.

Dan:

You see what it says? 16%.

Paul:

I do. Yeah.

Dan:

What that is telling us is historically, we’ve never been able to achieve steel deliveries in the time that we’ve had in the plan and, in fact, it’s taken up to 16% longer. I can select that AI suggestion and actually embed it within my plan. In fact, not only that, I can even look at which projects cause that 16% overage look. I actually get validation from my historical projects as to what was actually achievable. Again, this is all now driving my risk model.

Paul:

This is very cool stuff. We’re letting the computer do what the computer is good at, which is go and mine a whole bunch of information that’s sitting in the knowledge library, come back with useful recommendations based upon that, and then can… It’s like having a… you’ve said this before. It’s like having a third team member. Right? My AI engine, my AI bot is my third team member trying to contribute to the plan.

Dan:

Yep. Again, this has been further honing in on the accuracy of the risk model, so-

Paul:

Very [crosstalk 00:35:39]

Dan:

I think it’s so powerful. Again, underneath the covers here, we’re still doing, okay, we’re doing the modified Monte Carlo and all that good stuff, but what I think the biggest strides forward we have made in recent months is this concept of making it easy for the risk facilitator to drive the uncertainty ranges through things like the sliders. We’re accounting for team member expertise, and it’s all validated by the AI engine mining that historical information.

Paul:

Can you use all of this to build scenarios?

Dan:

Scenarios, again, yes. In the old days, you would have to effectively do a file, save as, and it was very laborious. For scenario modeling, and this came from… honestly, Paul, from doing risk workshops where the project manager would look at the model and go, okay, that’s great, but in reality steel deliveries, then, risk of late delivery, I’m just going to make sure it doesn’t happen. Okay. Mr. Project Manager, there’s your scenario. Using these toggles to toggle on and off the impact of those risk events is, again, this is real time, Paul. Doing a risk analysis, literally responding in milliseconds to the inputs to the model.

Paul:

That’s fantastic. I can do that for risk events as well as team member input in the plan, risk ranges that I may have entered or even the AI guidance that may be contributing to the risk profile.

Dan:

Exactly. Yep. You have full control over those levers and which elements make it into the model or not. Again, I get excited about technology and clicks and AI and stuff, but at the end of the day, a project doesn’t actually care about that. They care about getting a realistic forecast, so the clever technology that we implemented is, it’s driving a project’s ability to get to that more achievable forecast. For me, honestly, I know I like technology, but the fact that we’re now able to help projects get to that achievability, honestly makes me shiver. It’s very, very cool stuff.

Paul:

I mean, and one thing we haven’t even touched on, right, so we continue to do these workshops while teams are working from home. What do you think is going to happen post-COVID? Do you think things are happening now that will stick and stay as we move into a post-COVID world and people get to go back to work?

Dan:

Stick and stay, okay. I think pre-COVID, very few projects were adopting risk analysis, whether it was our next generation approach or legacy risk analysis. That’s going to change. I think the world and specifically, projects and project management, projects are going to be viewed through the lens of risk and I think that’s great. That’s why, again, this concept of setting that confidence level, whether it’s your 75% certainty or above, I think it’s going to be the norm. I think the concept of risk registers, honestly, I think a lot of projects today, to just pay lip service to them where, oh, gosh, we’ve got to get an Excel spreadsheet of risk events and then we can check the box on our risk register. The fact that now people are quantifying the probability and the impact of schedule and cost, and the fact we’ve completely nixed that ridiculous concept of risk mapping that we used to have, means those risk events get appropriately embedded and accounted for in the risk model, I think is, again, is a big step forward.

Paul:

I was going to say, I think it’s clear that quantifying risk, especially for contractors, and especially as part of the bid analysis process is, it’s going to be the new norm. We’re in a more risk adverse world now. [crosstalk 00:39:52] long time.

Dan:

I agree, I would maybe challenge and say maybe we’re just in a more risk aware world and the technology, such as what we just demonstrated, can help awareness in the world of CAPEX projects and maybe the techniques and the tools that we’re developing for project management also have applicability in a bigger space outside of just project management, too. Who knows?

Paul:

I think you’re right. I think you could be right. All right, well thanks, Dan. As usual, it was a very fun conversation with you. Next week, we’re going to do this again and we’ll focus on the marriage of risk adjusted planning with the front-end planning process and how that impacts when we plan for field execution, kind of making it a full life cycle planning process. We’ll do it same time, same day, and we are very excited to see everyone there. If there are questions that we didn’t answer during this session, feel free to send them to us at RiskMyProject@InEight.com.

Dan:

Paul, just to add to that, I think next week we’re also going to demonstrate how we’re breaking the mold between the traditional plan the work, then work the plan. We’re not doing that anymore. We are better planning throughout the whole project life cycle. We’re turning that sequence on its head, too.

Paul:

Well, I can’t wait to see that. We’ll chat next week.

Dan:

We’ll see you on the flip side.

Paul:

Thanks, Dan.

Show full transcription

REQUEST A DEMO

Thanks for contacting us. A member of our team will follow up with you shortly.