Take the Risk Out of New Project Delivery Methods

Transcript

Ellen McCarton: 

Good afternoon and welcome to this webinar. Take the risk out of new project delivery methods. This event is brought to you by Engineering News Record and sponsored by InEight. I’m Ellen McCarton custom content editor at ENR. Thank you for joining us today. The lack of collaboration between the designer and contractor has driven the industry from the traditional design bid build approach to alternative delivery methods. These new methods have reduced unexpected change orders, improved project delivery time, increased client satisfaction and established a relationship between designer and contractor. However, everything is not as easy as it seems. Organizations have had to change how they traditionally executed their projects, which has led to analysis and change of existing tools, business processes, and program management. Today we’ll discuss Kiewit journey on the challenges they’ve faced with these new delivery methods and how adding standardization and process to alternative design method projects, help to fully complete its project controls integration.

 

Ellen McCarton: 

Please don’t hesitate to submit your questions to the panel in the Q&A tab of the webinar console, and we will do our best to tackle as many as possible. We’ll address webinar, excuse me, we’ll address questions that come in throughout the presentation and we’ll tackle a few more at the end of the webinar. Now I’m excited to turn it over to Catie Williams, vice president of product development at InEight, who will lead today’s discussion.

 

Catie Williams: 

Thank you, Ellen. As Ellen said, my name’s Catie Williams. I am very excited to be here today to have this discussion about alternative delivery methods. From a background perspective, I’ve got about 15 years in the data and analytics space, always in the construction and engineering industry. And I’m really looking forward to having this conversation. I think there’s been a lot of change and a lot of really good things that we can share from a panel perspective. We will kick off introductions. Nidhi, do you want to go ahead and introduce yourself first, please?

 

Nidhi Jain:

Sorry. I was unmute. I’m Nidhi Jain, I’m the director of engineering project controls for Kiewit. Kiewit is basically engineering led construction driven company, which has operations in infrastructure power in the industrial as well as oil and gas markets. And it had 12 billion in revenue in 2021. I primarily focus on developing and maintaining engineering project controls related tools and processes across all markets for Kiwi. I’m a civil engineer, I have a master’s in construction management from Texas A&M University. I have about 15 years of total experience in engineering construction and the technology industry. And I’m really happy to be here and share some of my project controls experience with all of you.

 

Catie Williams:

Thanks. Nidhi. Matt, would you go ahead and introduce yourself next please?

 

Matt Reuer: 

Yeah. Hi everyone. My name is Matt Reuer. I’m currently the engineering project controls manager for our infrastructure markets for Kiewit. I’ve been with Kiewit for about 10 years and prior to Kiewit, I worked for engineering consulting firm for the first 10 years of my career. I have a master’s degree in structural engineering and I’ve been supporting the project controls group here at Kiewit for the last five or six years.

 

Catie Williams: 

Great, thank you and Jake.

 

Jake Sjuts:

Hello. My name is Jake Sjuts. I’m a product manager at InEight. I’ve been working in the called construction technology space for about the last 10 years and really within this project controls realm and for the last four to five years. Looking forward to the chat today in terms of what Kiewit doing and how they’re leveraging InEight.

 

Catie Williams:

Great. Thank you, Jake. And as Ellen mentioned, please feel free to put questions in at any time. I will try to be watching that and ask the panel at any point, if you’re putting something in there, otherwise we will save about 10 minutes at the end to answer any further questions. I think maybe to just set the stage and maybe Nidhi you could start, if we could just talk a little bit about what is alternative delivery methods. Maybe share a little perspective on how things have changed. Well, I don’t think necessarily alternative delivery methods are all new. When we think of construction, we think of design bid build right as the traditional method and so there’s been a lot of change. There continues to be a lot of change, and maybe you could share a little bit more just so that everyone on the call is under is sure and clear what we’re talking about when we’re referring to alternative delivery methods and you’re on mute still Nidhi.

 

Nidhi Jain:

Thanks like you mentioned, design bid build was the traditional method that was used innate engineering and construction industry and design bid build. For those of you who don’t know is basically like the name says. It’s design bid and build. The owner what’s a contract to the designer to get the complete design done. And then they basically roll out a bit for contractors to build the design and then they award it. I’ll speak more on the energy market side. And I like Matt cover the infrastructure piece, but since the last 20, 30 years in the energy market EPC contract method is what’s the most common in which the owner really signs one contract with the contractor and the contractor is responsible for the engineering procurement and construction of the whole project. Some people also call it EPCC and EPCS because it’s also includes commissioning and startup. In more recent years, we’ve also started seeing feeds conceptual design studies, pre-feeds, integrated project delivery, as some other contract methods that have started emerging in the energy market.

 

Nidhi Jain:

I think it’s really important for everyone to understand, like you said that most of these are not new contract methods. They have been existing for quite some time. It’s just they’re spreading across different markets now. And the reason we constantly keep seeing these changes or variations of these existing contract methods is mainly just risk management.

 

Catie Williams: 

Well, that’s great, Matt. I don’t know if you have anything. I know your background’s a little bit different if there are any additional methods to bring up.

 

Matt Reuer:

Yeah. Like Nidhi mentioned, from an infrastructure standpoint, you design bid build was always the norm up until about the mid eighties or so early nineties. The primary contract model was design bid build. And since then the alternative delivery methods design build CMGC, CMAR, P3s, and now we’re even seeing models termed like an Alliance model in Canada is really utilizing these Alliance models a lot where it shares the risk between the client, the contractor and the engineer, so that not one of those entities carries the most risk. In one of the most popular models that we’re seeing now is a progressive design build where the client will select a design build team before they really know the scope of the work that they want to design and build. And then they’ll work with that team to define what the scope is. And so all of these models, design build EPC Alliance, progressive design build, they’re a more of a collaborative approach between all three parties, the client, the contractor, and the engineer.

 

Catie Williams:

Thanks. And I think as you’re saying, they’re not new, but we’re seeing them grow in popularity. Obviously that change starts to create change in business process. The change management required internally. Maybe if Matt, you want to take, what challenges are we seeing because of the new methods and if you want to share some insight on how we’re addressing those two, you can but I’ll ask that as a follow up if you don’t.

 

Matt Reuer: 

Yeah. That’s a great question. And with that collaborative approach with these alternative delivery methods, the engineers in the contractors and the owners are all getting a little bit more involved with things that they’re not used to being involved with. The engineers may not fully understand how the work is going to be built. The contractor might not fully understand how the engineering gets completed. And there’s some inherent risk or some inherent conflict there we’re all working together as one team, but trying to build that trust in transparency between all parties to be mutually beneficial for the overall project.

 

Catie Williams:

Yeah. There’s some natural growing pains that happen as you try to collaborate and learn how to work with each other. Nidhi, I don’t know if you have anything that you would want to add in there before I move to the next question?

 

Nidhi Jain: 

I was again on mute. I think Matt has covered it well with everything that he has said as these different parties want to get more involved and understand each other’s processes, that’s where really the evaluation of project controls and how we manage things so that everybody can see what they want to see. But we also don’t share information that we should not share that is company proprieties. That’s where innate tools have helped us a lot. And coupled with our processes that we’ve implemented for Kiewit projects.

 

Catie Williams: 

Maybe you could share a little bit more about how the solutions that you’ve used are changing the relationship between the owner of the contractor and the designer. And if you have some specific examples that you would want to share, but go ahead. Sorry.

 

Nidhi Jain: 

I think the solutions that we’ve implemented have really made the relationship very transparent. It’s very open. The more transparent you are, we are giving them weekly reports, weekly updates. It just tends to make your overall relationship really good, happy and trusting that we know what you’re doing. It’s all open to everybody. Couple of examples that I can give is for example, on our EPC projects with NH design quantity forecasting, we are able to track engineering quantity updates which drive commodity based quantities for construction, like linear feet of pipe, cubic heads of concrete. We are able to track those quantity updates on a monthly basis, even before the design is complete. From the estimate to when the design is complete, we are constantly getting quantity updates as the design evolves and that really helps construction in reducing risk because they are able to plan if there’s procurement related changes, if there’s more quantity needed, or if the scope has increased so much that we need to have more staff or more crew on the construction site, they’re able to plan all that in advance.

 

Nidhi Jain: 

It really gives advanced warning is what the tool really does. That’s what this process helps with is that’s just one example of many examples that I could give, but that’s how we are transparent within engineering and construction, but those reports also go to the client so they can also see that, okay, the quantities have changed. That means construction will have to do this and it’s all really open communication.

 

Catie Williams:

Matt, do you have anything that you would add to that?

 

Matt Reuer:

Yeah, I’ll just echo what Nidhi said about the transparency with our tools and processes, utilizing the innate software and then our standard processes for integrated project controls, it really allows us to provide very reliable data in almost real time so that we’re not waiting a week or two to look backwards on what we’ve already done and lose focus on moving forward and what we have left to do with the importance of an integrated project CPM schedule, understanding exactly what work has been completed and how much work has left to be done is crucial to make our schedules, which in a lot of our projects are very tight schedules. And so having that reliable, transparent data that we can use to communicate between the client, the contractor and the engineer, so that everyone understands where we sit at any time is very critical.

 

Catie Williams: 

Absolutely.

 

Nidhi Jain: 

Sorry, I just thought about the engineering scope of work as Matt was talking about it. One other thing that we are able to do with any engineering is we are able to track the scope that involves just engineering, not commodities for construction. We are able to track quantities as sheets, but also as unit of measure that really drives our unit rates, which has helped us a lot in tracking productivity for engineering scope of work. And again, echoing what Matt said about weekly updates and providing weekly reports to all parties involved depending on the contract that really drives it home.

 

Catie Williams: 

Sure. And we know from an industry perspective that these methods are increasing. I found a couple stats that I thought were interesting, just that I included on this slide to just show how much more we’re seeing in terms of these methods for projects. I’m curious, again, you’ve alluded to business process change the technology from QT’s perspective or yours. What would you say is the biggest challenge you faced internally when trying to drive to these processes as standardization?

 

Nidhi Jain:

I think the biggest challenge we had with rolling out these processes and tools was really training. It’s a lot of training and engineering being engineering, we also get a lot of feedback. We are continuously improving our tools and processes and continuously training on them. And I think it’s important to understand that with innate engineering, at least for Kiewit we changed our processes to move the responsibility of claiming work to the person that’s actually doing it. The tool is really being used by every person that’s in the engineering group. 1600 to 1800 plus people. And so that’s really the biggest challenge as far as rolling out and implementing the tool goes, but with innate engineering, what happened when we rolled out innate engineering in 2021 for Kiewit is that we were already using in-house build software or tool that we had rolled out for engineering project controls in 2016. And it was rolled out with one market and that’s where all the tools and processes really changed. And we had to implement it on one market.

 

Nidhi Jain:

And once we started seeing the benefits in that market, we implemented it in other markets within Kiewit and over time as we implemented it, every market had their own unique needs and challenges. And so we adapted our tools and processes to address that while taking notes of things that we could do better. And then in 2020, when we start working with NH to develop NH engineering, and when NH engineering was rolled out in 2021, it is really a really sophisticated tool that answers pretty much all engineering controls, related questions for all markets. When that was rolled out for Kiewit engineering, it was really welcomed with open arms because it was much better than what we were using. From every perspective, ease of use, reporting updates, just all of it and so at that point, for us it was mainly training and communication was the main key. When we rolled out any engineering, we did update some of our processes, but all the updates were really for the better, more automated versions of what we had

 

Catie Williams: 

For someone though, maybe that’s listening that is not in the same place where the process is defined already. And I know you’ve been a part of the entire journey. Do you have any suggestions about how do you drive that business process change? You’re talking back to your 2016, it doesn’t sound like you suggest a big bang approach. You selected markets. I don’t know if you have anything else that you would make in terms of suggestions and then maybe a timeframe that you think is realistic to expect that type of change to be welcomed by the organization?

 

Nidhi Jain:

When we had rolled it. I think there were a lot of lessons learned because as we implemented these processes and tools for every market, we were learning ourselves too. As far as timeline goes, if you have executive sponsorship and if everybody is ready for the change, if they welcome it or even if they don’t welcome, if they have a positive state of mind about it, then it really helps a lot as far as implementation, I would say implement it on one project and then take your lessons learned and then move on to the next one. And then maybe once you’ve done one or two projects, then just applying it across one market and then going to the next market would be better or maybe do one project in every market at the same time and then expand it to the whole market. There were lessons that we had learned as part of the rollout so when we rolled out any engineering, we kind of implemented a lot of those lessons learned during the rollout of any engineering for Kiewit.

 

Catie Williams: 

Oh, those are great suggestions. Matt, I don’t know if you have anything to add to that as well.

 

Jake Sjuts: 

I guess I had one more question Nidhi and with those business processes, how did you go about standardizing data collection that you needed to derive the information you were looking to get?

 

Nidhi Jain: 

I think we standardized a lot of things when we rolled out innate engineering because like I said, the in-house software that we had built was first developed just for one market. The things we did with innate engineering rollout and innate engineering is really flexible. You can really set up things at an organization level, at a market level or at a project level. And with innate engineering rollout, one of the things that was really beneficial was we had super users identified for each market. There was one key person in every market that was given access to the tools and processes and reports, I would say like two months before everybody else in the company and so they were given access to the test environment so that they could test everything out and make sure all the processes aligned with their markets needs.

 

Nidhi Jain: 

And they became the point contact for that market as far as innate engineering questions go. And then as far as standardizing data integrity, what we did was we had workshops that included all markets and we all agreed on these are going to be our standards. And because it was everyone participated in developing the standards, everyone tries to comply by them and if there is any change, we make sure that all markets are involved in approval or, reviewing any suggested changes to standard data sets that we are using across all markets, all projects, which will really help us in consolidating all that data and then analyzing it in the future as we have more and more projects under our belt in innate engineering.

 

Catie Williams:

Matt, if you wanted to, I don’t know if you have anything. Otherwise I’m going to change direction to go beyond change management. Any last thoughts?

 

Matt Reuer:

Yeah, I would just echo the training aspect that Nidhi mentioned is, from an infrastructure market, we work a lot with third party or outside designers and just training them on our processes and our tools and really focusing on the standardization of our schedules and the standardization of our progress claiming and the standardization of our account codes for control budget purposes and the benefits that those standards provide us. That training is probably the biggest hurdle that we’ve had.

 

Catie Williams: 

That’s a great segue to the standards and the information that’s being driven from the end. What are some of the insights? The question we got was maybe more specific about what KPIs are actually being tracked that go across owner designer and contractor. I don’t know if you could share the information that you’re getting now that you didn’t have before with this new system and the new process. And Matt, I don’t know if you want to take that or, okay, go ahead Nidhi. Sorry.

 

Nidhi Jain:

Sorry, can you repeat the question I’m really sorry.

 

Matt Reuer:

Yeah, I’ll go ahead and jump in here. Our standard KPIs, we don’t deviate much from the industry. We track schedule performance, we track cost performance and performance factors. But one of the biggest things that we really focus on is quantities. And Nidhi mentioned this earlier, quantity management and quantity growth. And when we are producing design and we’ll submit to the client at a 30, 60, 90, or preliminary interim final phases of the design and every one of those phases, we will do a quantity takeoff, and we will measure our quantities against what we have in our estimates so that we can see whether our quantities are growing or whether they’re shrinking and how that’s going to one impact our final cost forecast, but probably more importantly, is impact our schedule and communicating that to the client of here’s what’s happening and here’s what to expect.

 

Catie Williams:

That’s great. Nidhi did you want to jump in on that?

 

Nidhi Jain:

I agree with everything Matt has said on that topic.

 

Catie Williams: 

Great. Another question that came in and I think Nidhi, this would be to you, how has procurement changed with progressive design build and then in particular, when compared to a DB procurement or contractors propose a fixed schedule and price.

 

Nidhi Jain:

I don’t really know how procurement would’ve changed with these methods. I don’t know Matt, if you would know because they’re more infrastructure focused contract methods.

 

Matt Reuer:

Yeah. Specifically for the progressive design build, we mentioned that it’s a way more a collaborative approach early on with the client because they don’t know exactly what the scope of the work that they want completed is. And so during those early phases of a progressive design build, it’s very important to stay flexible with our control systems because we don’t have a fixed price and we don’t have a fixed schedule, but continuing to progress to a point where we can get a fixed price and a fixed schedule. And from an overall project standpoint, the amount of risk that is reduced in this model is substantial because in a traditional design build the contractor and the engineer are asked to develop a fixed price and schedule from a design that is maybe 20 to 30% complete. But as we develop the design and go through constructability reviews through that process of a progressive design build the quantity uncertainty and the cost uncertainty continues to drop. And so the owner gets way way more price certainty, and schedule certainty with that progressive design model.

 

Catie Williams:

That’s great. Thank you. Switching gears, maybe just a little bit, because I had a couple questions come in more specific to how you’re using innate and I don’t know Jake, this might be a good one just to high level talk through the process that’s supported by the innate system or if Nidhi you’d rather take that too, but the question was if we could get some clarification around how innate supports these alternative delivery methods. Do you want to take a stab Jake maybe first?

 

Jake Sjuts:

Yeah. Again, I’ll break it first. From I can call it the design process management. We have a suite of tools that enable you to estimate budget forecast, track design progress. We have the scheduling solution, we have a document solution all with ties, from an integration perspective to one another. And we’re continuously working on building out more and more integrations as we go. But it’s a suite of solutions that a project controls solution that it’s obviously been tested heavily on the construction side, but we’re also now going into that design engineering space and looking to leverage the solution from that angle as well.

 

Catie Williams: 

The emphasis is really on the integration. And so go ahead, Nidhi, I think you were going to add something there.

 

Nidhi Jain:

Yeah. I would just say that using the innate suite because all of their modules talk to each other. It’s all integrated. For example, as you claim work or progress work in innate engineering with a push of a button, which is really just sync and you can see that progress in it control, which is where we track cost. And it is important to understand that the level of detail in which we track work in both of these modules are really different. Cost control is at a very high level than scope, but they’re always in sync. And that’s just one example, you have other modules that are also linked to each other, like Jake was mentioning innate plan, innate design, quantity forecasting, we all talk to each other. It really helps with business processes.

 

Catie Williams: 

I think bringing up the data is a really-

 

Matt Reuer: 

I was just going to add one more thing there, Catie, sorry for that. And just the importance of that data integration. In the past, I know most of us have dealt with this on jobs when scope changes and trying to go back and revise the schedule to incorporate all of the scope or when the schedule changes, how is that going to impact my cost forecast? And so in the past, we’ve done a lot of manual work to force feed that information into all of these disparate systems with the innate suite now, and all of this data tied together there’s no more manual processes. We can see the impacts to one system when we change scope or schedule or resources.

 

Catie Williams:

That’s exactly where I was going to go. That was perfect Matt, thank you. In regards to, this is another question that came in. I know I didn’t prep you with this one. It says, regardless of delivery method, we’re seeing a lack of flexibility in contracts to address changing ground conditions during construction. Do you have a recommendation or a preference on how ground risk should be addressed in contracts?

 

Matt Reuer:

I can speak a little bit on this and primarily with the Alliance models that we’ve seen in Canada, where all three parties share the risks. And so it’s not just the contractor that owns the risk of site conditions, the engineer and the client also share that risk as well. And so the more collaborative approaches where that risk is shared really helps to promote the sharing of information and the sharing of the benefits of the project as well.

 

Catie Williams: 

Thinking to the future. As we see new delivery methods and recognize that there could be more, how does what you’re doing at Kiewit support, adapting to that. As new things come about, does this process scale to different delivery methods, changes different new markets? How do you address that inside of both your business process and the technology you’re using?

 

Nidhi Jain:

Yeah, I would say the processes, as well as the tool can be applied to any delivery method and any project size. You might have to make some tweaks or some exceptions based on the contract or the project size. But in general I’ve said before, the tool is really flexible and the process that we have implemented are really general processes that could be applied at large to any project. What changes by project size is really the level of detail that you want to track. If it’s a really small project, you might not want to spend a lot of hours or cost into tracking entry level of detail. If you control the level of detail you want to track, but the processes and the same process and tools still apply. The work being claimed by the person who’s doing it, progressing schedule weekly, maybe for smaller projects.

 

Nidhi Jain: 

If we don’t have the enough budget, then we might not do it on a weekly basis. We might do it every other week. It just depends on the contract and the budget, but I think it’s pretty scalable. And you decide the level of details. You control how you’re going to do it, deal with it,

 

Catie Williams: 

Matt, I’m not sure if you have anything to add on to that one as well.

 

Matt Reuer:

No, I think Nidhi covered that pretty well.

 

Catie Williams:

Okay, great. Another question about the overhead required on this process. So again, you’ve talked a little bit about how you think it scales, but how does that work? Is there a shared service in place? If a new project is being set up, how does that set up process work to get them on this process and method that you’re following?

 

Nidhi Jain:

The overhead is I think, if an organization on a market decides to follow the processes, similar to what Kiewit has, initially I would say to make sure we have success we need to make sure that the markets take some time and develops their processes has executed sponsorship, has a good training and communication plan that’s been communicated over and over again. And if all that is done, then I would say, before you even implement it on a project, if you’ve really taken the time to develop your processes and train and communicate, then everyone should already be aware of this is what’s going to happen. So in that case, if everyone is trained, you just need the estimated data in the format in which innate engineering accepts it and basically decide your format, the company needs to decide their own standards.

 

Nidhi Jain:

Kiewit has standards that we have implemented and those standards that we’ve implemented for execution jobs have been communicated to our estimating departments. If we win a job, we are basically given that information. Our setup time is quicker, if it’s estimated in a certain way. If we don’t have those deliverables from the estimate phase, then we’d spend some time doing all that. Does that make sense? It’s really dependent on what level of detail you got from estimating.

 

Catie Williams:

And another question-

 

Matt Reuer: 

The one thing that I would add to that. Sorry, Catie. The one thing that I would add to that too, is just proper planning as early as possible. Not waiting until the job or the project is awarded to plan the work. Especially for engineering starts day one. And so you can’t wait until you’ve been awarded the job to start planning how you’re going to execute the design. Developing a good, solid baseline schedule for engineering, developing a plan for how you’re going to claim your progress and really defining what the scope and your deliverables are, is crucial. We’ve experienced a handful of jobs where we waited too long and engineering was 20 to 30% complete by the time we got things in our reporting set up and running and that’s just too long. The more that we can plan ahead of time, it reduces the amount of overhead during setup.

 

Catie Williams: 

Well, that’s great. Thank you. What, oh, go ahead Nidhi if you wanted to add onto that.

 

Nidhi Jain:

I just said I agree. 100%.

 

Catie Williams:  

Yeah, those are great suggestions. Thank you. What is different if design is already scoped and complete from a process perspective or systems you use? I don’t know. You want to go ahead?

 

Nidhi Jain: 

Yeah. If the design is already scoped and complete, as in design is done, and you’re just talking about the construction piece of it at that point, then in that case, you can just use innate plan and load all your scope in that, and then progress of construction work in innate plan and tie it to innate control. So it would be a completely different-

 

Catie Williams: 

I think we probably have several people though, that don’t know what innate plan is. Maybe you could just talk maybe from a business process perspective. What you mean when you say that?

 

Nidhi Jain: 

Yeah. Innate plan is the innate module that is used to progress work, or claim work, earned value tracking for construction projects. As you get engineering drawings, and then you take off those drawings, that’s what Kiewit does and we load scope into innate plan and that’s used by the team on site to claim work and progress work, and then it gets synced with innate control for cost person complete. And it’s also synced with innate design quantity forecasting, and that’s what we use for project control. As you claim in plan, and then it gets synced with innate design quantity forecasting, we progress our schedule activities based on that claiming. It really is tied to everything cost, progress, schedule.

 

Catie Williams:

Yeah. I think the theme, just that’s that integration is so key that everything is talking to each other and doesn’t exist in a silo and walking away from this. It’s really about making sure those pieces are all connected. And then from a people perspective, you’ve got that collaboration to then manage that data and as it’s moving through the different pieces of the process. A couple questions that came in that I know that we didn’t discuss prior, but maybe you could talk a little bit about the accounting system that’s also used. What does Kiewit do for that? And how does that play into the integration that you have with design? I don’t know if that’s one Nidhi or Matt, either of you would feel comfortable talking about at a high level, Matt.

 

Matt Reuer: 

Yeah. I can jump in and take that one. Our ERP system that we use is SAP and SAP syncs directly with innate control. As our engineers are completing the work on a weekly basis they fill out a time sheet with the WBS that they were working on or the scope of work that they were working on broken down into the work breakdown structure in SAP, then that cost and those hours get automatically synced to innate control where our budgets in our quantities live so that we can also see what we’ve earned on a weekly basis from innate engineering to identify performance issues. If we spent more than we earned on a weekly basis, if we’re forecasting to go over budget so SAP is where we actually collect the spent cost and time, and then that sinks directly with InEight control.

 

Catie Williams: 

That’s great. Thank you. Something that I don’t know that we’ve talked about is there anything left that you’ve talked about that the solution works really well, but what’s missing. What would still needs to be tackled from either an industry perspective, a technology perspective what’s left on the table.

 

Nidhi Jain:

There are a few features that have already been discussed with innate and Kiewit’s technology group. And those features are on the roadmap for innate engineering. I’m only talking innate engineering at this point. I’m sure there are roadmaps for every module for innate, but there are some features like tieng in each document to innate engineering. Some other features like lead planning tools where the leads can do what of scenarios within the tool to see that, what if this deliverable gets delayed by two days, then how does the other deliverables get impacted? How can I move the dates here? Or if I move this resource to this scope item, and then I move that resource here, how does it impact the overall schedule or resource loading and being able to do what if scenarios and then picking one, and then basically just say, this is the final.

 

Nidhi Jain:

And it would automatically basically sync with all our reports that are given for schedule updates and other things. That’s where we are heading for the future. One other feature that’s that innate already has, that will be rolled out for Kiewit pretty soon is like I said, adding dates at a scope item level, which really helps all engineering companies that have small gap projects or projects that don’t really need P6 or a schedule file because generally all engineering companies have some small gap or task based projects or really small projects where you don’t really want to put scheduling resource where you can just manage schedule on your own. You can use that feature of a need.

 

Catie Williams: 

Matt, from your perspective, are there any gaps that still exist?

 

Matt Reuer: 

No, I think what Nidhi said about resource planning, that’s kind of the next focus at least from our standpoint at Kiewit is really helping to integrate our resource planning. As our engineering groups grow and we work with more external design partners, understanding where our resources are being utilized across projects and not just within one project, that’s kind of the next evolution I think that we’ll see from our standpoint.

 

Catie Williams: 

Sure. We’ve got a lot of questions and I’m going to switch to just purely the audience questions, but before I do that, are there any final thoughts that you want to make sure to mention? Maybe we start with you, Matt.

 

Matt Reuer:

Yeah. I think probably just to reiterate what we’ve already talked about is just innate engineering, the innate suite for those tools to be effective, there has to be the trust built between the parties involved between the client, the contractor, and the engineer. That trust and transparency is crucial. You can put information into the tools, but if there’s not the trust and the transparency, then it doesn’t matter.

 

Catie Williams:

Nidhi do you have any final things you want to highlight?

 

Nidhi Jain:  

I think one thing that we’ve not mentioned till now is that we are also able to track our engineering partners in innate engineering and not just engineering partners, even the different engineering firms that we have within Kiewit across different geographical locations. We even track that scope of work within innate engineering, and we can report off of it. We can give access to engineering partners to basically manage their own scope of work. There are a lot of other features that I would like to say about the tool, but I think that, and then Matt said, if the data that’s being put in is not taught through and the business processes are not if you don’t have execute sponsorship and the business processes are not followed properly, then you don’t get the benefit of organization level, analysis cross project analysis, and being able to do resource planning, seeing the demand for all projects combined together to see the organization level projected demand. I think the tool is flexible and ready to do what you want, but we also need to follow the processes and the data needs to be clean.

 

Catie Williams: 

Absolutely. And Jake, I know you have a unique perspective having designed the solution right to these business challenges. Maybe you have a different perspective that you would want to highlight now that we’re at towards the end.

 

Jake Sjuts:

Yeah. And it’s kind of come up in the previous topics, but the topic of trust. Trust and flexibility were kind of the two main focus points for us. As we built out the tool, we focused a lot on making it as configurable as possible. If there are different markets with different business processes, we could accommodate that and then when they’re entering data and progressing that data through the system, and then they’re going to leverage that analytics to make business decisions that are coming from outside the tool, we needed to make sure that data was reliable and available for them. A lot of the focus for us was on making it configurable and making sure that the data was reliable, that we’re capturing the system.

 

Catie Williams: 

That’s great. We are going to switch over to the Q&A but just as a quick housekeeping note, there will be a survey that’s popping up. If you could please take that and provide any feedback, things that you want to know more about, or ways we could improve. That would be great. We have a lot of questions, so and only 10 minutes left. I will try to get through as many of these as we can. I thought this one was great and relevant to everything we’ve been talking about. From an owner’s perspective, how do you sell them on alternative delivery methods? How do you gain them to see the value or how would you sell them that this is the direction that they would want to potentially go from a delivery method perspective? [crosstalk]

 

Catie Williams: 

Go ahead.

 

Nidhi Jain: 

I think most of the delivery methods are like I said they’re not really new and I don’t believe it’s really the BLM really take care of it for Kiewit. But for example, for energy market APC has been there for a long time. And that’s what we follow in general outside of feeds and pre-feeds. I feel the alternative delivery methods that we are referring to here are really to manage risk. And most of them actually help the owner in reducing the owner’s risk in putting the risk onto the contractors and the designers. I would think unless the owner has specific needs on, they want to see the design completely done before it’s built, or they want to move do a feed study before the project is rolled out for bid, or they want to do PDB for any specific reason. I feel it’s to their advantage. That’s just my perspective, but Matt, you can add more, because I know you deal with a lot of different contract methods and infrastructure.

 

Matt Reuer: 

Yeah. I would just say for any owner or client that is not utilizing alternative delivery methods, the benefits to them would be accelerated schedule more cost certainty, and less change, in a design bid build where the engineer and the contractor aren’t working together simultaneously. The engineer doesn’t know how the contractor plans to go build it. And the contractor doesn’t know the assumptions and the design criteria that the engineer used. And so there’s a lot of rework and a lot of change to the scope that happens on a design bid build delivery. And so it’s in the client’s best interest to be involved in that process and get in the middle of it.

 

Catie Williams: 

And just owner Matt, what level of access are you providing to the owner in terms of the modules, the data I know you’ve both referenced transparency. Could you elaborate a little bit more on what level of access that means they have?

 

Matt Reuer:

Yeah. Really it’s how much they want. There’s obviously information that is proprietary to Kiewit but we really push for transparency in our schedules, transparency in the progress that we’re making. That there’s no surprises really. That’s kind of the key word is no surprises.

 

Catie Williams:

Yeah. Were you going to add something Nidhi?

 

Nidhi Jain:

No, I would say the same thing as Matt. And I’ve said before, we provide weekly reports depending on the project size, obviously but we try to provide weekly reports, which go to the construction partner as well as the owner where they see all progress. And also our remaining work.

 

Catie Williams:

Sure. This question, I think Jake is probably one you could best answer. Is the tool limited to the construction industry only? Or could it be used for other industries, for example, Biotech.

 

Jake Sjuts: 

Yeah. It’s that kind of goes back to the flexibility portion. We’ve built it in such a way that it comes down to however you want to execute a project. You’re going to have resources, you’re going to have the cost, you’re going to have schedule, a budget, and then you’re going to have progress on the scope that you track. The tool is flexible enough to kind of do work for what you want. And you’re not kind of really limited to just instruction or just engineering or design. It can be flexible and work for a number of different scenarios.

 

Catie Williams:

Great. Thank you. I think this came up a couple different times. We talked about it a little bit, but from your perspective, and this might be the last one we can get to from a time perspective and Nidhi, if you want to start is integrated project delivery, the future of construction. And I think maybe elaborating on, do we see design bid build going away, or if you had a crystal ball, what would you say is going to happen from your industry perspective? And then Matt, we can talk about infrastructure as well.

 

Nidhi Jain:

I really cannot predict this, but I don’t think any contract method is going to go away or anything is going to become predominantly dominate the market. But I think because it really depends on the owner’s reference, I do feel that the design bid build is going to slowly go away. We don’t see that, I want to say at all in the energy market, it is still not common, but it is still being followed in the infrastructure market. I think it’s owner preference on what they want and maybe the contractor’s preference if they want to bid on those type of projects, but it’s going to switch more towards everyone gets the profit and everyone gets the loss, which is integrated project delivery is what I think. But again, like I said, it’s really owner driven and contractor driven on what would happen. I’m not an expert.

 

Catie Williams:

We’re recording so we’ll come back in a let you know if you’re right in a couple years or so. Kidding. And Matt, I know we only have about a minute or two left. I don’t know if there’s anything from your perspective of what you would predict happening in the future.

 

Matt Reuer:

I’m not going to try and pull out my crystal ball, but I would keep it very short and sweet that it really depends, like Nidhi said, it depends on the client, depends on the project. Traditional bid build is right in some circumstances when the risk is low and there’s a lot of shovel ready jobs that are ready to go. They just need a contractor to go build them. I don’t think that bid build will ever go away.

 

Catie Williams:

Sure. Well, thank you so much. We’re out of time. I appreciate your expertise. It’s been great to hear about this journey that you’ve been on, and I’m going to hand it back over to Ellen to close our webinar. Thank you.

 

Ellen McCarton:

Thank you so much, Catie. And thank you all great presentations and insights that you’ve shared with us today. Please join me and thanking our presenters as well as our sponsor InEight. If you have any additional questions or comments, don’t hesitate to click the email us button on your console. If you haven’t already had a chance to complete it, you will be redirected to our post event survey at the end of the webinar. Please take a moment to share your thoughts with us. We look forward to hearing how to make our programs work better for you. Please visit enr.comforward/webinars for the archive of this presentation, to share with your colleagues as well as information about our upcoming events. Make sure to tune back in for tomorrow’s webinar, Where Your Steel Comes From and Why it Matters airing at 2:00 PM Eastern time. Thanks again for trusting us with your time today. Have a great day.