Removing Risk With
Intelligent Life Cycle Planning

Nate St. John:

Okay, well, welcome to part five of InEight’s Connected Data series. I’ll be your host, Nate St. John. A couple of reminders before we get started here, let us know that you’re here by using the chat box. You can use this feature to chat with other participants, speakers, or leave any comments. Feel free to ask us your questions at any time that we’ll be sure to address them at the end of the webinar. The chat and question features are located within the same box. On the right hand side of your screen, you can toggle between both by clicking the icons at the top. And finally, don’t forget to rate the webinar and give us some feedback. You can rate the webinar and the time using mark scale rating above the broadcast screen. 

So I’m your host, Nate St. John. I’m Head of Planning for scheduling and risk at InEight. I’ll be facilitating the conversation between two great minds in the industry, Brad Barth, Chief Product Officer at InEight, and Dr. Dan Patterson, Founder and CEO PMFocus. Welcome gentlemen.

Brad Barth:

Thanks for having us Nate.

Nate St. John:

Yeah, of course. So, it’s very exciting to have both Brad and Dan together to discuss this topic of removing risk from your bottom line with intelligent life cycle planning. Each of these gentlemen brings a critical pillar of project controls to the table. Brad with cost estimating and control, and Dan with planning, scheduling and risk. So, although they are both experts in project controls, their specific backgrounds have led them down a path of true expertise. So, for those of you not familiar with our speakers, I’d like to give you each an opportunity to introduce themselves. Brad, would you like to kick us off?

Brad Barth:

Yeah, sure thing, Nate. And thanks for moderating this too, by the way. Hopefully, it will be informative for all the viewers and hopefully everybody out there is experiencing some better weather than the last week, and getting past some of those challenges of the past week. So hopefully, this will be a little change of pace for everybody. But yeah, my name is Brad Barth, Chief Product Officer for InEight. I’ve spent the last 30 years-ish building project control solutions for construction. So going back to what we used to call a hard dollar, which was one of the first computerized estimating systems out there. 

We eventually expanded that into a full project cost management system, and that really became the basis for the integrated project controls platform that we offer at InEight today. So my focus has always been on the whole project controls for most of my career. But as you mentioned, I’ve had a particular keen interest on the cost side of that equation. So happy to be here today and to go through these topics with you.

Nate St. John:

Well, thanks, Brad. We appreciate it. Over to Dr. Dan Patterson. Hey, Dan. You’d like to introduce yourself?

Dr. Dan Patterson:

Hello. Good morning, Nate. And again, to reiterate Brad’s sentiments, thank you so much for the invite. Super excited about getting into some really compelling discussions this morning on the topic of risk. So, rather than introduce myself through title, probably better for me to just touch on my experience. Similarly to Brad, I’ve spent just over a quarter of a century specializing in bettering the science of what we call scheduling within project management. And specifically building cutting edge technology solutions that really have bettered the science of what we call CPM scheduling. I think we’re all aware of this approach to scheduling a project using this technique called CPM and why like always, passionately believed in the philosophy of CPM, I’ve also believed that it’s planning, not execution that is really the root cause of project failure. 

And so, what I’ve dedicated my professional career to do is, improving the realism of planning, whether it’s been through building risk solutions. My first venture was an organization called Pertmaster, which became one of the premier Oracle suite that morphed into more of an analytics or an analytical look at improving CPM, a platform called Acumen, which is part of Deltek. 

And then of course, more recently leveraging artificial intelligence and really bringing together computing power and human intelligence together, getting to improve scheduling. That product was originally known as BASIS, and very excited today that that has now become part of the InEight platform and is more commonly known as InEight’s Schedule. Again, very excited to be here today.

Nate St. John:

Well, yes. Again, thank both of you. So let’s get started. Really flexible, like I said, I encourage everyone on the webinar to type in some questions. We’ll have time at the end of the hour. We’ll have a little Q&A and we’ll dive into it. So let’s start this discussion with the idea of this multi-dimensional planning for each phase of a project. So to set the stage for this conversation, I guess a question for Brad, how does InEight define multi-dimensional planning? Could you just highlight what some of the key elements are?

Brad Barth:

Yeah, good way to kick it off. So multi-dimensional aspects for InEight I’d say falls into three categories or three angles, if you will. So the first is just the connection across that kind of traditional project controls triad of scope, cost, and schedule. So certainly our view is that looking at any of those individually is valuable, but not as valuable as looking at the three of them in a connected way. Obviously, each of the scope, cost, and schedule affects the other. So looking at that holistically as a key part of setting the system aside as a part of project controls to look at the impacts of each of those three. So in our solution, we’re constantly looking at how do we make sure that we’re connecting the dots there across those three points of that triangle.

The second part, is really the connection of the different roles that get involved in all those different aspects. So you’ve got whether it’s estimators, planners, schedulers, field engineers, all the way to foremen and folks out in the field. Connecting across those roles and connecting as the project goes through the different stages of its life cycle is another key part of that multi-dimensional positioning. 

Because you typically go through this. You hear it everywhere you go, as the project moves along and you go from stage to stage, roll to roll, stakeholder to stakeholder, there’s always this kind of two steps forward, one step back or worse, as you move through that process. A lot of starting over of reentering data that somebody else has already entered, and not leveraging the work that’s happened before you. So that’s a big part of it. 

And then the third part I would say is the connection of… Dan alluded to this. The expectation side of the project certainty equation and the outcome side. So, there’s historically a lot of good planning tools, and scheduling tools, CPM tools, even estimating and cost forecasting tools that focus on the expectation side of what we think it should take from a cost or schedule perspective. But historically, they’ve not done a great job of tracking what actually happened. Tracking those as-builts outcomes. 

So that’s another part of this multidimensional solution that we’ve created, where you have the ability to not only do the plans and create those expectations, but you’re tracking the as-builts and the actuals in a way that nobody wants to do that twice. So InEight does that in a way that integrates with accounting, and integrates with payroll, and integrates with other systems. So you’re only tracking that as built information once, but you’re doing it in a way that you can capture those lessons more. So that multidimensional aspect ultimately comes down to, how do we help you learn from every project so that you can benefit from that on future projects, right? We’re building up that knowledge library that’s going to help us. The topic today is obviously risks. So, marrying up those expectations and the outcomes helps us track those risks that are potentially coming into play on future projects.

Nate St. John:

Yeah. Thanks for the insight, Brad. I think, that really nails the description and the message that we’re going for it. I think it’s a valid sentence to say that, all of these components, all of the data sets within the multidimensional framework really fall on success when they’re incorporated among the platform. And so it’s this back to the connected data theme, projects generate a ton of data. It’s connecting those pieces at every stage, capturing it and having it sit on a platform. So, if we were to go on a construction journey, let’s say, going back to each life cycle of a project, we would naturally start at this conceptual pre-planning phase. So, Dan, I guess pointing to you here, what processes can be leveraged early on in a project to support proper risk management?

Dr. Dan Patterson:

Sure. So Nate, I think you used the term pre-planning, that is very early stage of a project. I think it’s worth noting that again, historically, CPM scheduling tools, they focused on the work. It’s not uncommon to have Primavera schedule with 50,000 activities and that’s a whole other topic in itself. But I think as an industry, we’ve missed a trick. And I think this is where InEight is really at the forefront now, because before we get into the weeds of determining the work, I think we need to do a better job of determining the scope. How can you possibly put together a proper plan when you haven’t yet finalized the scope? And so in my mind, this concept of pre-planning or sometimes top-down planning is really interesting because the focus is less about the detailed sequence of work, and activities, and the effort, energy, and money, and resources, needed to be expended to do something. It’s more around properly defining the deliverables and the scope of work. 

Because ultimately as an organization, I’m somewhat interested in the construction techniques, and how the contractor does stuff, but really more interested in getting my asset, right? And again, that goes back to scope. So I think, better marrying scope and work, is a long overdue step forward in scheduling. And I know, for example, in InEight schedule, you really don’t have a choice. You actually have to stop in the pre-planning phase, which is perfect. Because you focus on scope definition, and then you break down those scope into more manageable chunks. Then at that point you can go over and say, “Okay, what is the work needed in order to achieve and deliver those scope elements?” 

So this concept of starting with top-down, really deliverable based planning, and then coming back and taking a second swipe of planning, then doing your bottom up. That’s when your CPM comes into play. 

And I think, again, in the world of risk and risk management, the benefit there is a CPM schedule inherently gives you the best case scenario. It doesn’t take into account potentially bad things that are going to happen. CPM schedules don’t really take into account uncertainty of scope. So by upfront, in the very early phase of a project, identify not just discrete external risk events, but also quantifying certainty. 

Coming back to this topic of scope, scope is analogist to things like quantities. Well, if those quantities haven’t been fully defined, it’s okay to raise our hand and say, “Well, there’s a degree of uncertainty around those quantities. Let’s account for that variability during our early planning phase.” So this concept of starting very early on in a project, embracing and acknowledging, what I think we used to call risk, but really, I think that is more potential quantity scope growth, uncertainty driven estimating. 

Embrace that upfront, and then as the project progresses use the outcome from a risk analysis to either mitigate or eliminate, in some cases, reduce that variability, that risk exposure, so that you’re constantly firming up the work plan. Does that make sense?

Nate St. John:

Yeah, yeah, absolutely. Top-down planning makes sense. I think I also picked up on some, almost flipping the traditional methodology from a heavy, critical, path focus left to right and identifying your deliverables and potentially, working right to left to generate execution or constraint-free, potentially hotspots or risk areas.

Dr. Dan Patterson:

Yeah, this concept of constraint, free execution is a relatively new concept. But again, I think, it’s very sound. The thinking as well as a traditional project. Now, in the big scheme of things, you do your engineering, your fabrication, or your procurement, your fabrication, and then you take everything to site and you install, or execute. 

And so, projects are prone to just natural knock on delay effect. So turning it on its head, as you alluded to and say, “Well, let’s plan backwards. If we can agree on a goal, whether it’s a completion date and, or and agreed upon cost of the project, let’s work backwards, such that all of those proceeding tasks, again, whether it’s design engineering, fab’, procurement, let’s make sure that they are all matching towards being able to execute as per plan.” 

Because in really simple terms, if we were able to execute as per the plan, every project would be 100% successful. And of course, in reality, that’s a rarity versus the norm. So yeah, this concept of constraint pre-planning starting with top-down scope, deliverable based planning, feeding back in your more detailed work execution plan. And then I think, additionally, historically, CPM schedules and Gantt Charts, it really become pretty pictures. You walk into a construction trailer and yeah, there’s a picture of Gantt Chart on the wall, but people aren’t really matching to that Gantt Chart. They want to. It’s because that plan hasn’t been updated to reflect reality. So my point there is, it’s okay to re-plan during the complete life cycle. I know we’re going to get into more detail on execution later on in this discussion.

Nate St. John:

Yeah, no, that’s good insight. Brad, it sounds like scope maybe the unifier here for picking up on some trends of what Dan ran through. Is there a potential to connect our data with scope as the central unifier, and do these principles also compare to the cost side of the house?

Brad Barth:

Yeah. I love what Dan was saying there in terms of focusing on the scope. As an industry, we’ve created the expectations that we’re often over budget, behind schedule. And there tends to be the gut reaction that we’re just not executing very well. But I’m with Dan in terms of at least, if not more, of an issue in the planning itself and creating more realism in those plans in the first place, including the proper expectations. And that totally starts with scope, right? So as you’re all the way back to the point where you’re piling scope into that project, you’re piling a risk onto that project, right? So as you throw scope in there, risks should be coming along with it. Now, whether that risk every one of those becomes something that we need to mitigate, or they’re going to bring different levels of risk. 

But a project controls platform where we’re capturing data points for that scope over many times, right? As if we brought that scope into different projects, even if every project is different. If you break it down to the atomic level, there’s a lot of data points from previous projects that can help us as we’re creating plans on the next project. So being able to apply a machine learning capability, to looking at, as we put scope in the project, forget about design risk, fab’ risk, execution risk, all that stuff, even just the scope itself is going to bring inherent risks. 

But we don’t always realize that until we get further into the process. That’s another perfect example of how a connected platform can surface those risks where we’re not always relying on human observation and human assessment, the system can do some of that surfacing of risk in the background.

Dr. Dan Patterson:

Brad, it’s really interesting because historically, project expertise has really been analogist to human expertise. So really, really good at making decisions, gaining insight, drawing analogies from prior projects in a really complicated environment. And again, historically computers have been arguably quite rubbish at that. They’re really good at binary matching and mining through huge volumes of data, but in terms of drawing inference in complicated environments, that’s not what mathematics has historically been about. 

And so this emerging science of artificial intelligence, I think, is so exciting. Because for the first time, computers now are starting to emulate this fuzzy logic, analogist reasoning that this inference driven way of mining not only large quantities of data, but unstructured types of data as well. When I look at some of the database technologies today, I feel like a bit of a dinosaur now, because I grew up in the world of formal SQL tables, and data schemas and databases. Now, we’re actually moving towards modeling unstructured data where you can literally throw any type of format into a database. And the database is smart enough to reason against that unstructured data.

Brad Barth:

But the key is the data points, right? And that’s where I think as an industry, we don’t do a super job. We do a lot of nice capturing of data and all the assumptions that go into the models, and the CPM, or the cost model, like an estimate or a forecast, but we don’t do a great job. We might track what did it actually cost or what did it actually take duration-wise, but we don’t track all the assumptions and validate those assumptions, and use those as data points to as fuel for the computer to go look at, and create, and find those patterns, and find those relationships, that we as humans don’t have time to do. So it’s completely a matter of using the horsepower of a computer to do all that grunt work, and surface those opportunities to mitigate risk. As humans, we can ultimately make those decisions. We’ve both been at this a long time, but where we’re at now compared to 20, 30 years ago, it used to be that the computer, its role was to automate what I’m going to do as a human. Where now, it can vastly expand on that and essentially be an additional set of eyes and ears that are constantly probing for opportunities to reduce risk and to more scrutiny.

Dr. Dan Patterson:

It’s interesting, Brad. I think of cutting-edge AI technology is turning computing on its head, create AI. As you said, computers, they respond to human. Human provides data, the computers create a story and doing analytics, but that’s really the extent of it. Now with AI, the computer can make informed suggestions, we feed that back to the end user. And not only that, I think this is so exciting, the concept that the computer is almost humble enough, such that if it understands that it’s got something wrong, it can actually adjust its behavior, its thinking, it can adjust the data, it can flag that data as being erroneous. That all falls under the umbrella of what’s known as machine learning. But this concept of over time, the computer can get smarter without human input, I think is just an amazing example of technology being an accelerator.

Nate St. John:

I think, well, in everything that was discussed, like you said, I agree. It’s the most exciting time, at least in my opinion, and probably in controls. I think that ties back to the statement of intelligent life cycle planning. And that’s what we mean in how we’re defining intelligence during the life cycle process. So if we were to get a little bit more on track now and move from this pre-planning and conceptual stage, let’s move on to the design phase. So we’re done pre-planning, the job has been awarded, we enter design. Let’s talk a little bit about the experience or interaction of risk management from the perspective of a stakeholder on the project. And I guess Brad, a question for you, what can be done to ensure all stakeholders and particularly if you think of the silos of design and construction teams, how can those folks remain connected during the planning phase and design phase while still maintaining an elite level of risk management?

Brad Barth:

Yeah, that’s a good question. And that’s another where technology, I think can help and the evolution of these platform solutions that can allow these different stakeholders to collaborate much easier than it ever used to be. Some of that is a function of the contract itself. Obviously, design, build contracts have a deeper level of collaboration through design and construction. Going back to what Dan was saying, I think there’s a huge opportunity here to do more value engineering than ever before, in terms of, there’s risk associated with the design work itself, right? So just like construction, and there’s execution risk, and design there’s design risk, just in terms of how long is it going to take us to do it. But there’s also risks associated with the output of the design process, right? So I think a lot of times engineers are to some degree operating in a cost and schedule vacuum, right?

They’re looking at how do we enable the scope? How do we enable the functionality of the asset that we’re building? Without a whole lot of input on… Because a lot of times you’ve got these kind of AB decisions, where if I knew the cost and schedule associated with A versus B, I might make different decisions, right? At certain points of that process, we bring in the experts, right? Whether that’s the contractor or consultants to look at the design, and come up with what’s the risk, and can we optimize the cost and schedule? But our goal is certainly to allow all of those stakeholders and allow design, engineering and construction to participate in that process collaboratively. I think they use the term, democratizing the risk assessment. 

So as that design is progressing, whether you do it continuously or 30, 60, 90, or whatever it happens to be, we’ve got good data from past projects and history to help us make those decisions. So we know, yeah, this approach delivers on the functionality we need from a design perspective. But maybe, it’s got a higher cost schedule risk than an alternative approach that would also get us there. It’s another good example of every time we do a project and throwing data points at that machine learning model even back in engineering and design, we can be surfacing those risks as we go along on a continuous basis.

Nate St. John:

Yeah. That’s great. I’d like to get your thoughts too, Dan. If you had any other commentary around what Brad just said.

Dr. Dan Patterson:

No, I mean, really just to endorse Brad’s comments. I look at risk as sort of the anti-plan, if that makes sense. And so I think it’s very important when putting a detailed plan together, whether it’s during the design or in the execution phase, or relating in execution, it’s as important to define the work and the activities as it is to, we’ve really got to give more emphasis to capturing and quantifying the anti-plan. Because as the project progresses, that anti-plan all, those risks, again, in an ideal world, will get mitigated and diminish. But we can only mitigate them if we, first of all, identify them. 

And so, this concept of more collaborative-based planning, capturing multiple opinions, even if those opinions are different, I think is great. I think the days of the loudest wins, we’re going to march whatever the project manager says. Thankfully, I think those days are behind us. I think having more of a consensus-based approach to forecast and plan is very, very important. And again, the computer capturing all of those differing opinions, such that the next go around when it was starting with a blank sheet of paper, obviously is a huge benefit.

Nate St. John:

Yeah. I agree. And you and I, Dan, we’ve co-facilitated workshops together. And I do like the trend of allowing expert members of the team to go off almost in their own, to provide their unfiltered assessment, to avoid things like group think and the phenomenon of whoever yells the loudest, is the person that gets their way. So it’s promoting the rose colored glass removal. And it’s almost natural to go off and provide feedback in a siloed environment, but at the end of the day, having the technology to surface all those opinions and visualize any kind of variants of consensus, we’ve seen in the past have really driven meaningful conversations and acceptance of an ultimate solution.

Dr. Dan Patterson:

It’s interesting Nate, in many risks workshops, if I’m looking for input into a specific area, let’s take energy or oil and gas project, and you may have onshore scope and offshore scope. If I’m looking for input on onshore, for example, do you know which group I actually go and ask first? The offshore. Because the onshore group, they’re living and breathing that part of the project. And often, they got assumptions built in. Sometimes they’re trying to protect their schedule. And so while expert opinion is of course, very valuable. Getting opinion from the rest of the team, I think is equally important, because often, it’s that knowledge, that audience, that will actually raise questions and force the expert audience to answer that you wouldn’t otherwise get, if you just asked the experts. 

And consensus or collaborative based planning obviously drives that. And again, from a software perspective, having a cloud-based platform and I know InEight’s schedule has this concept of mock-up layers, where concurrently all of the contributors can provide potentially differing opinions and then have the computer flatten those opinions. Of course, it’s hugely beneficial. That’s something we never really were able to achieve using a manual analog approach to risk workshops.

Brad Barth:

Well, that’s another area, Dan too whereas we’ve said, I know you’re fully in agreement, comes down to human decisions on any of this stuff. But those human decisions are always based on knowledge and that knowledge is usually based on personal experience. And so the role of a data-driven solution, like we’ve talked about in this project controls platform, the more data you feed into it, the more historical data you capture. You can effectively expand that experience, that knowledge that, I’ve gone through five projects with my organization, has gone through 500 projects, right? So we can make that experience of everybody collective and bring it to bear on some of those, what may sound like opinions, or as Nate said, the loudest opinion in the room sometimes wins. Well, ideally, it should be the best data that’s backing up that opinion. 

And oftentimes, we don’t have enough data to really take that approach, right? Because we haven’t captured that history across a large number of projects. That’s what a machine learning needs a lot of data. The more data you have, the better it’s going to do. So that cloud platform that you alluded to, where all these different participants can be capturing that data and bring it to bear on every project just makes everybody smarter every time they go through it. So I think there’s way better opportunity now than there ever has been to make risk assessment more of a data driven approach.

Nate St. John:

I agree. Yep. Yeah, that’s all really fascinating stuff. So I guess let’s move along this theoretical lifestyle now. Let’s talk construction execution, okay? Before we consider the most hyper focused area of the project, we can argue that on a different date. But today, up to this point in this conversation, we’ve talked about what you should do, what’s available, what’s out there, and what’s the future. Dan, I want to ask, where do projects typically fail in managing risks during this phase, and what can be done about it? Or is this even the phase where things could go south? What could be improved upon in the world of risk management?

Dr. Dan Patterson:

What’s the phrase, Nate? You plan the work then work the plan. There lies the problem because during execution, you still have to re-plan. And I think by the time we get to execution, as I alluded to earlier with the construction trailer has the Gantt Chart on the wall. People, they don’t take it seriously. And it’s because it’s more often than not out of date. So this is really the fault of lack of processes, as well as, I don’t think as an industry, from a technology perspective, we haven’t historically enabled the updating of a plan during the execution phase. We haven’t made it very easy. And so, we think about failing during execution. I’m not sure that that’s really true because at that point, the project is what it is. It’s the fact that the plan doesn’t reflect reality. Therefore, we perceive failure. 

Well, that’s wrong. If the plan was updated to reflect reality, then we’d actually be in much better shape. And I think the same is true for the risk model that sits on top of the CPM schedule. Most capital expenditure projects spend a lot of time, effort, and money in the early stages. During these third party risk workshops, they quantify the risk events. They have the risk register. We come up with our fancy P75 forecast. The risk adjusted data. We have a 75% certainty of succeeding. And then it gets PDF-ed and that’s it. Well, that’s ridiculous because again, the project is a living thing all the way through to project completion. So in my mind, making it easier to re-plan such that the plan better reflects reality is key, especially during execution. 

And when you think about the amount of uncertainty, and risk, and unknown, wouldn’t you expect most of that risk and uncertainty to be at the beginning of the project, not the end of the project? As you get closer to completion, there’s less stuff that can go wrong or go off the rails. So it’s ironic that actually during the execution today, that’s where things tend to go wrong. And I’m not sure they really do go wrong. I think it’s just the plan is so far out of whack with reality. So that’s my take on where we need to improve in execution. Let’s embrace this concept of re-planning. Re-planning is a good thing, not a bad thing.

Brad Barth:

There’s a little bit of human nature that comes into play too, especially from the owner’s perspective. Sometimes they’re isolated as the project goes along and they don’t find out about it until the end. Your point about, the further you get into it, the time you get 80% into it, only 20% of the risk should be left. But it’s often, that’s when we find out that last 20% or the last 10% on the schedule is when we find out about a lot of those risks that have been modeled up and not necessarily shared. So I think that’s another area where we can, again, the idea of democratizing that whole process, where it’s more collaborative and as those risks are being surfaced everybody’s aware of them, or at least, the right people are aware of the risks that come along and it’s not on a monthly basis or some prescribed frequency.

Nate St. John:

Go ahead, go ahead, Dan. We might be losing him a bit.

Dr. Dan Patterson:

I just sort of throw into the mix there. So again, traditional legacy risk analysis, if you will, really focused on, “Okay, how much longer is the project going to take, and how much extra money is it going to take? Or how much are you going to overrun by being told my project is going to be late?” Isn’t constructive. It doesn’t help me whatsoever. What does help me is, “Hey Dan, your project’s going to be late. Here’s the reason why. And for each of those reasons why, we have a potential solution for reducing those.” And again, I think, risk analysis, risk software is thankfully now, getting to the point where the focus is more on the root cause versus just reporting, I’m going to be late. 

Again, that doesn’t help anybody, but being able to track the drivers of delay and the drivers of cost overrun, is absolutely the way we should be approaching de-risking a project. So focus on the root cause, take into account the outcome of that root cause. But the outcome, I honestly think is secondary. It’s the root cause that we have a fighting chance of doing something about which of course, then in turn, impacts the outcome.

Brad Barth:

I love that because it’s not the outcome itself, it’s the why behind it. And that’s the opportunity to make the models smarter and teach the system to get better the next time, right? You might have something if that was going to take $1 million, it’s going to take 60 days. Okay, well, the outcome was we were behind by 20%. Let’s say, “Well, that’s interesting.” But the more interesting thing is the why were we 20% off? Where were our assumptions off? What data can we feed into that model to validate the assumptions on and off, right or wrong? So the next time we see a common scenario, or a similar scenario, we’re going to get better at it.

And so, every time we do something, we’ve got an opportunity to teach the system to get smarter. I think that’s something whereas an industry, we don’t do that very well, right? We’re tracking the outcomes and managing to an end result of that project, but we don’t do a great job of capturing the lessons learned. We move on to the next project really quick. And we end up capturing data that can be reused.

Dr. Dan Patterson:

Brad, I think it’s the risk register saying to the CPM schedule, “Hey, it’s me, not you.” And I say that in jest, but I think there’s a lot of truth to that.

Brad Barth:

For sure.

Nate St. John:

Yeah. And I think you can even take it a step further. You identify, what’s your exposure. Why are you exposed? But then owners, contractors together can sit down and have meaningful cost-benefit analysis discussions around, how do we handle now these primary drivers? And that leads you down a better decision-making for your business to attempt to get back on track, if things were to go south at this stage of the project.

Dr. Dan Patterson:

Oh, Nate, so really exciting topic here. So I know you guys have made amazing progress on the concept of cost benefit of mitigation. Yes, we can say 90 days, but it’s going to cost you so many dollars. How cool would it be to think that in the future, the owner could come to the contractor and say, “Hey, I’m willing to spend so many dollars. What is the best case outcome? What is the reflection in the schedule that you can give me as a result of me investing so many dollars in mitigation?” Then you start going down the paths of a target-driven risk reduction, risk mitigation. That would be very cool.

Nate St. John:

And I think that we can get there, Brad, right? I mean, we pride ourselves at InEight for taking stuff that’s very complex under the covers and sophisticated, but trying to enable everyday users with ease of use. But maintaining that sophistication, so that something like Dan just mentioned, that scenario can be fulfilled and iterations, and have a meaningful time slot in the project life cycle.

Brad Barth:

Absolutely. That gets back to that connecting the dots across scope, cost, and schedule. And we do a great job of that in the planning stage, right? So we can help our customers and the different stakeholders look at, if we change the scope, what does that do to the cost and schedule? And do those what if scenarios. To Dan’s point we could look at, if we’ve got a fixed budget while that’s going to drive some compromises in the scope and some compromises in the schedule. If we’ve got a fixed amount of time, then likewise. We might need to spend more to get it done more quickly or less scope. But now I think we’re applying that same optimization a microcosm of a risk assessment, right? So as we look at those risks that pop up, we can apply that same value engineering to that list of stuff just like we do in the planning stage. 

And again, it requires that collaboration, right? Because none of the stakeholders can make those decisions in a vacuum. But having that data, having that ability to collaborate seamlessly, especially in today’s world, where you may not be sitting together in a trailer at the owner’s office. You got to be able to collaborate digitally to have all that data as a backdrop to help drive those decisions. It’s a lot harder to make your point on hand motions and a whiteboard these days.

Nate St. John:

Yeah, that’s great. Totally agree on this side. So, Brad, let’s round out this construction journey and I think we’ll have a few minutes to take, maybe one or two questions. So you mentioned collaboration via digital, via shared data. Let’s move to the turnover or hand over to an owner phase. Are risks still important during that phase? Are they left out of the conversation when we do a risk analysis? And what can we do to ensure a smooth transition of data visibility for an owner during a turnover at the end of a project?

Brad Barth:

Yeah. You could argue that, that stage, in that start-up and commission, you could argue that’s the most risky stage, right? Because that’s where the rubber meets the road. And all those risks that we mentioned there, beginning of this webinar, as part of scope into that project, the risks are coming along with it. You may not realize it, and it may not be until startup that you do realize that those risks are there in terms of, “Hey, this is not what we expected or functionality was not what we expected.” Or we run into punch list items that we hadn’t anticipated to take longer to get through. So yeah, I think it’s critical that that risk assessment process continues during that last mile, if you want to think of it that way. 

And again, that’s a very collaborative process as those issues come up, whether they’re QA/QC related, or functionality related. Being able to jointly mitigate those issues as they come up between owner, engineer, and contractor is the key to that process. And the key to doing it effectively and keep things moving along. Otherwise, we tend to just start with something, and let it sit and move on to something that we can get going on. And meanwhile, those risks just move down the cycle, right? So being able to service some visibility to them across all the stakeholders and make decisions on them picks that last 10, 20%, and make sure that doesn’t turn into 30 or 40% of the schedule.

Nate St. John:

Yeah, I agree. I think it’s picks up really, along the general theme of moving throughout these life cycle stages. You’re still collaborating across extended teams. You’re doing your best to eliminate gaps and silos for a smoother handover. Before we get to the few questions that we have, I’d like to give each of you an opportunity to last minute statements, or to round out any lingering thoughts as we approach the top of the hour. Dan, we can start with you.

Dr. Dan Patterson:

I’m not sure if it’s a lingering thought but maybe, just to add to Brad’s commentary around the latter stage of the project. So, even in the most simplistic project, you have this concept of everything converges towards the end. And so having as little as two parallel paths in the schedule, you’re going to have this bottleneck of convergence. The chance of both of them finishing on time, isn’t 50%, it’s 25%. Again, you have this natural challenge towards the end of the project. And then to your point about the handover from the contractor to the owner, for example, during commissioning, there’s a huge amount of knowledge transfer.

Nate St. John:

I might’ve lost Dan there, Brad.

Brad Barth:

Yeah. Let me, maybe just jump in. I think, the ability, particularly at that stage, we’ve talked through this thing, through this webinar, about the ability to capture knowledge as you go through the process. And I think a lot of times when we get down to that last 10%, where it’s that commissioning and handover stage, a lot of the decisions that are made at that point, I think don’t get captured. And we’re putting that knowledge library that we can leverage that information to do that through value engineering on future projects, or optimization on future projects. Some of the things that happened then, again, it might affect next time that same scope comes into a project, if you’ve got visibility there. All that stuff we had to deal with in the last time we had that same scope, we might make different decisions, or at least set more realistic expectations on the next project that involves that same scope. 

So hopefully, we’ll get Dan back here to finish his point. But the one thing I wanted to add was, we talked about machine learning and how computers, software have evolved in the last 30 years. And if you think of yourself as a steward of your organization’s success into the future, you think about what’s going to happen with machine learning in the next five years, and the next 10 years, and the next 20 years. It’s going to get more and more sophisticated. It’s going to get more and more democratized to use your term, Nate. It’ll be more accessible to everybody to leverage. 

But the key is the data, right? Without the data you don’t have the fuel ammunition to feed that machine learning process. So I think, the advice I would give to anybody out there today is just at the very least, even if you’re not using the power of machine learning to help validate your decisions and help surface risks, at the very least, start capturing that data and start capturing those data points. 

And again, it’s not just what was the cost that we expected, and what was the as-built, what was the schedule we expected? What was the as-built. Capture the assumptions in those models, cost models, time models, and validate the assumptions so that’s just more fuel for the machine learning process. Now, we’re in the future to operate again. So I think if I were the contractor, EPC, GC, design build contractor, I think that would be priority number one. If you’re not already doing a great job of building up that knowledge library and that history at the very least humans can use that to make decisions. But in the future, you’ll have more and more opportunity for machine learning to help you make those decisions from that data.

Nate St. John:

Yeah. That’s fascinating, really good insight. And it’s a perfect segue. We have two questions that we want to try to get to before the top of the hour and we sign off here. So the first one here, will AI take over or will I always remain in the driver’s seat? Thoughts on that Brad.

Brad Barth:

Yeah, that’s a great one. And actually, using the term driver’s seat, one of the most interesting AI and machine learning initiatives that’s going on right now, not in our industry, but just in general is what Tesla’s doing, right? So if you think of Tesla’s model of their belief that billions of data points that they’re capturing from drivers every day is going to make their autonomous driving system… It’s continually learning and getting better so that it can make decisions. Essentially, training them to make the same decisions that a human would make when faced with the same criteria that the human is aware of. And in Tesla’s case, they’re thinking, “Well, that’s going to obviate the need for expensive hardware, like LIDAR and all that kind of stuff that the car can get smarter and smarter.” So it’d be interesting to see where that ends up. 

But I think in construction, again, like we talked about, it’s all about that knowledge and all about the experience that drives that knowledge. Well, like I was saying, if we capture the data and make it accessible to everybody, well everybody gets smarter then. So I’d benefit from the knowledge that you gained on your projects and you benefit from what I gained. 

But then there’s that third party, which is the computer itself, and the machine learning or AI, back to the question that becomes another party in that whole process. It can also analyze that data, and analyze that history, and be predictive. But ultimately, the humans are going to make the decisions, or we’re never going to get to the point or at least I hope we don’t. Computers are making the decisions for us. They’re a party in that process, but not the ultimate decision-maker.

Nate St. John:

Yeah. I echo that sentiment too. Especially in construction, certainly there’s going to be advancements, like you had mentioned in machine learning, and leveraging data, connecting data. And it’s obviously easy to use a platform style like InEight. But yeah, ultimately at the end of the day, I do want to make the final decision. And I think the benefit also just to reiterate of leveraging and using the data, you can, again, take stuff that’s very complicated and very sophisticated, and give it access, and democratize it to the masses so that it can then be easily incorporated into this iterative system.

I think, we’re trying to do so, just at InEight, and I think we’re trying to say long are the days of big budget companies, and risk experts at a high dollar hour will always need some of that. But at the end of the day, these solutions are more than just what we had mentioned in the conceptual pre-planning phase. It’s necessary throughout the project. In order for that to be realistic and accessible, it has to be simplistic, easy to use, intuitive, but still maintaining the complexity under the hood.

Brad Barth:

That’s exactly right. If you think about what are computers good at, what are humans good at, the computer can do that massive iterative approach against a whole lot of data way faster than a human could. But I mean that Tesla analogy is perfect for our industry because every car is benefiting from the experience of every other car on the road. So that the next time my car gets into a certain situation it’s never been in before, well, there’s probably of millions, or hundreds of millions of cars out there that have been in that situation. So, we can set up all learn from the collective. And obviously in our industry, that’s contained within a particular organization. 

But again, it’s expanding on that. Not only the knowledge that any individual human can maintain and keep you accessible in your brain, or even in your ability to capture that information in the system. But also, just the horsepower that a computer brings to the analysis of that data, it can go way faster and way more iterations than a human could. Kind of like your Monte Carlo risk assessment in your schedule solution, your risk solution, where you can go through and do those simulations in order to come up with, what are the likely risks that we’re going to run into. We can do that same thing at every stage of the project, whether we’re creating that initial estimate, or that initial budget or schedule. Do that same what if scenarios and simulations help us arrive at more realistic plans and schedules in the first place.

Nate St. John:

Thanks, Brad. So I just got the 60 second warning. So final, one word, top of mind, very fast. If you were to describe the future in construction, using what we talked about, use one word, what would you say?

Brad Barth:

How about two words, knowledge, library.

Nate St. John:

Knowledge, library. I say, confidence. With that, we’re going to say a special thanks to Dr. Dan Patterson, who had to sign off for technical issues. And of course, Brad Barth. I would encourage you all to connect with InEight, if you’re interested in staying on the cutting edge of these sorts of conversations, planning, scheduling risk. And checking us out for a full platform access to Connected Data. So with that, I wish everyone a good day and we’ll sign off.