DATA VS. INTELLIGENCE: THE POWER OF
INTEGRATED PROGRAM CONTROLS

Adam Palant:

Hello and welcome to this webinar, Data vs. Intelligence: The Power of Integrated Program Controls. This event is brought to you by Engineering News-Record and sponsored by InEight. Hi, I’m Adam Palant, special sections manager at ENR and your moderator for today’s webinar. Thanks to joining us. Now recent advances in construction program controls have transformative potential, but success requires a thoughtful approach that distinguishes between data and intelligence. Today we’ll explore how to effectively use increasingly large volumes of digital program controls data, as well as dive into how integrated project management information systems goes beyond data processing, turning data into intelligence and insights that drive successful project delivery. Joining us today are Rick Rients, director of client solutions at InEight and Osama Abdelfatah, regional program controls director for the Americas within AECOM’s global management group. I’ll be rejoining our presenters at the end to answer any of your questions that come in throughout the webinar, so don’t forget to submit them in the Q&A section of the webinar console. And now please allow me to hand things over to Rick and Osama to kick things off.

Rick Rients:

This webinar is really about integrating capital projects across all of the partners that are involved in these projects. And we think this is an important topic because we believe the industry is entering an important transition because enabling in technologies like InEight. I’m Rick Rients and I am the senior director of client success at InEight. I’ve spent much of my career implementing integrated software platforms or leading strategic planning for the implementation of integrated platforms like SAP and InEight for some of the largest manufacturing supply chain in construction and capital owner organizations in North America. Over the past three years, I’ve had the opportunity to work with AECOM as a partner of InEight to develop their program controls engine concept, which takes the power of InEight’s integrated platform and aligns its configuration with their standards and procedures for managing their customer’s largest programs, which results in a powerful repeatable program management solution that can be applied across their customer’s organization projects. Osama.

Osama Abdelfatah:

Thanks, Rick. Hello, everyone. Thank you for having me. My name is Osama Abdelfatah, I’m the regional controls director at AECOM. My background is in engineering and business. And prior to my control, I had the privilege of working on interesting programs worldwide, including the Guari Airport and Second Avenue Subway and other programs across the Americas and Middle East. Throughout my journey with AECOM family and program controls, I have been dedicated to supporting our clients in achieving their desired outcomes and building lasting legacy for them. Thank you.

Rick Rients:

Yeah. And it’s been a privilege to work with Osama and the team at AECOM because what we have built, you’re going to see, is really a great example of what it means to integrate a capital project and start to hear about some of the benefits. So before we get into the meat of the webinar, I wanted to talk a little bit about InEight because I’m not sure everybody is familiar with who InEight is. But InEight provides one of the world’s most comprehensive capital asset management solutions. There are hundreds of billions of dollars worth of capital projects currently being managed in the platform. It is a comprehensive platform that can help organizations manage the entire life cycle of a capital project. It includes the functionality necessary and things, estimating cost management, schedule management, risk management, design management, construction management, document control, compliance, quality commissioning and virtual design and construction. All are covered under one platform.

It’s an integrated platform where the modules communicate with each other and share the information they need between each other to help manage the program. It’s also modular though because then you can implement what you need when you need it. You don’t need to implement everything all at once. It’s a modern platform and so you can take advantage of the fact that it’s in the cloud, it’s available anywhere, it’s an open architecture. So integrating with the platform is relatively easy. I won’t say it’s cheap, but it is possible to integrate and we frequently integrate with things like ERPs because it becomes an important add-on as you’ll see later on. And then finally, it’s a very secure platform. We have very tight controls over access to the data and it’s a very safe environment. So at the end of the day, the platform is showing that it definitely can deliver project certainty for all of our customers.

So today for the webinar, we’re going to cover a couple of key topics. First of all, we want to talk about integration. What is it? What are the things to consider? How do we get to a space of becoming an integrated capital project management environment or organization? We’re then going to let Osama talk about the AECOM story and how we’ve worked for the past three years to develop this platform and have gone through a number of deployments and learned our lessons. So he’s going to talk about that. And then we’re going to get into a couple of details, just a couple of minutes about contracting and some of the best practices we see around contracting. And also for you folks in organizations that do a lot of the self-perform work, get a little bit into some things to consider there and then we’ll wrap things up.

So to get us started to think about integration and things to consider, first of all, the three things we really want you to take away from this presentation is understanding what an integrated capital project management solution looks like. And when I say solution, I don’t just mean software, I mean people, process and everything, governance. And most of us today sit in a world where we got P6, a cost management system, an estimating system, maybe a work planning and packaging system, SharePoint for document control. And these things aren’t integrated really. And so we need people to understand what it looks and feels like when we get into an integrated environment. Then beyond that today, we want to have folks understanding, okay, as an organization, how do I start dealing with and developing my organization to be more integrated and to take advantages of integrated systems like InEight.

And then lastly, we’ll get into some of the details around contracting and things like that, that really are instrumental in terms of not only inside your organization, but now starting to reach out to your partner organizations in a capital project and getting them to integrate properly. So those will be some of the three main areas we’ll be focusing on today. So think about the reality of capital projects, and I know all of us sit there in our own organizational bubbles and play our roles, but let’s all realize that when you look at the full scope of a capital project and all the partners involved in it, it is a wildly complex endeavor. I mean, every project is unique. The assets being built are unique. The locations of those assets being built are unique and contractual structures within these projects between partners are often different from project to project, industry to industry. So it is very complex from that perspective. Plus then when you look at the individual participants, the boxes on this diagram and you think about those organizations have their own processes they have to execute.

I mean, they are legal entities at the end of the day and they need to be able to report their results and manage their profitability. And they have their processes and they may not always be the perfect processes, but they’re there and they have to participate in this whole management process. And then lastly, there are all of these data flows that have to be managed, starting with the owner organization flowing down through the environments and the other participants. And that data is constantly being transformed into information that each organization needs to execute their part of the program. And then a lot of that has to get summarized and pushed back up. And so you look at something like this and you have to ask the question, is integration really possible? And I think the answer is yes, but it is going to take time and there is a process to doing that. Osama, I don’t know if you have any comments on that or…

Osama Abdelfatah:

Yeah, it’s great points, Rick. And that summarized the level of complexity that we deal with. And when we talk about program management and project management, especially program management, it’s accomplished integrator for all of these pieces together, getting all of the stakeholders and the insights and getting that transparency around them, putting all of these pieces together and tying their inputs and outputs and the interaction between the stakeholder is not an easy task. That’s why it requires more than just a solution. It requires that framework that you mentioned.

Rick Rients:

Yeah. Excellent. Right. There’s going to be a quick poll now that we’re going to do because what Osama and I’d like to do is understand who’s involved with this webinar. So if you would please take a second to go in and select the owner, the capital project roles that your organization may perform.

Osama Abdelfatah:

While we’re doing that, Rick, I want to mention that today I’ll be focusing on taking the side of the owner perspective and I will add more additional detail based on my experience with different solutions and five organizations.

Rick Rients:

Right. Very good. All right. Well, it seems like we are starting to settle in on a number, so let’s move on. So you can see we’ve got a nice cross section of folks involved with the webinar, so that’ll be good insight. As we move through this presentation and webinar, we will try to tailor some of our comments towards the fact that we’ve got not just owners and owner reps, but we do have contractors and engineers, architects and whatever other is. So maybe suppliers or something like that. But we will. And also as I’m seeing there are comments showing up in the chat, so please keep them coming. We will come back to those at the end of the presentation, so feel free to add those comments. All right. So we’re going to move on to the next topic.

So as I mentioned in my introduction, I’ve spent years implementing SAP and my first many years were dealing with manufacturing and supply chains and in many cases, global supply chains like DuPont or ITT, and helping those organizations to envision what their integrated organization would look like from a manufacturing and supply chain and distribution perspective in order to really automate their systems and their processes and increase their profitability and things. So I will say that the manufacturing environment and supply chain environment in my mind now that I’ve been in construction for 14 years is really easy compared to construction. I mean, if you think about it, in the manufacturing world, they have a set of products. Those products evolve over time through engineering changes and product improvements. The organizations and people involved in the process stay fairly constant, and construction is not that way at all. I mean, it’s a very dynamic kind of environment.

But having said that, I think there’s a couple of things that are relative and we should take as learnings from what I’ve seen over the last 20-some years or 30 years actually as I did my SAP implementations. And that is that first of all, in order to make those supply chains integrated, there had to be technology. I mean, the advent of ERPs and then broader integrations of communications between companies had to be in place in order to enable the growth and improvement in the expansion of supply chains globally. Secondly, I think is taking an inside out approach to becoming an integrated organization is essential because you have to start with your own internal processes, build them up, get them aligned, get them integrated before you can really effectively and consistently work with your partners in the process. And so I think those two kind of concepts I would leverage or I’m leveraging from my manufacturing supply chain experience in the construction management world. So I don’t know, Osama, if you had any comment on that.

Osama Abdelfatah:

Absolutely. This means integrating all of the program management and project management aspect within organization. So let’s think of that. Think of the power of integrating, of schedule, cost, risk, change, contract and document, all of these work together, and the benefit and the data synergy between all of these aspects. That would lead to even being clearly define each function internal process and define the handoff from one aspect to another. That was internal. Yes. And second, it makes us to think and how the handoff even between one organization and another. Yes. So that would lead to having contracting standards that can apply to any supporting organization and having a standardized data sharing structures. And we’ll be talking about that more in the next few slides as well.

Rick Rients:

Okay. Thanks, Osama. So next step, a lot of my work with these companies has thought about maturity matrices and using them as a means for customers to think about where am I at and what is my roadmap to getting to be world-class? And for this webinar, I did a little bit of work, a little bit of searching around to see if I could find a relevant maturity matrix. I struggled with that, so I made up one. It’s not perfect, but it gets to the point that I would like us to think about or the points I would like us to think about because, as I said before, we have to think about our internal process maturity first and then we can think about our contracting maturity second. Now, Osama and I discussed, well, reality is you can work on them in parallel.

But as I said before, in my mind, in order to get to the top level on the right-hand side here, you really got to have your internal house in order first. And then once you get your contracting things to get your partners integrated in, you can actually get to the top level. And I don’t know, Osama, what’s been your thoughts on this as you think about AECOM in this context?

Osama Abdelfatah:

Yeah. So let me share how we dealt with that within AECOM. So when we started our journey in configuring the controls engine, we already had established sets of standardized process and procedure as a mature organization. However, our goal was to refine them and to better suit complex programs and ensure consistent approach to delivering major programs. And one of the most valuable lessons here is that process requires continuous improvement and close collaboration with our clients to ensure outlining requirements within the contractual agreements, which is crucial, having that process and procedures, but we’ve not embedded in the contractual agreements that will lead to lack of application. So by doing so, we can achieve consistency and maintain a seamless workflow around all the stakeholders and the programs, and derive the desired outcomes. Transparency.

Rick Rients:

Right. Yeah. Yeah, and I’ve seen that with you guys too. It’s been interesting to come into an organization that’s fairly mature in their processes and then bring the two, technology and the processes, together and now have a vehicle to really drive for the client a greater level of consistency and speed of deployment and things like that. So I’ve got another couple polling questions here that I’d like you to do. The first one is related to how would you look at your internal process standardization/integration? So if you could, please go ahead and rank yourself. I’m sure everybody’s going to get the third bubble all the time, right? All right. Well, this is great. All right. I think we got most of the people. So here’s the results. And to be honest with you, I don’t see any big surprise here because my experience of implementing InEight, especially with many different types of construction organizations, capital project organizations, I see a fair amount of standard processes standardized.

But then when you get to the field, it’s like, okay, who’s ever in charge or doing the work tends to do what they’re used to. It’s a rarity, but I have seen a few organizations that come and do it, an implementation and already have a fairly solid set of standards that they try to drive across the organization. All right, next polling question. When you think about the contracting process that you have in place, think about the standardization of your contracts, where do you rank yourselves at? Excellent. All right. I think we got most folks involved. Looks like our rankings have stabilized. So again, I mean, I’m surprised. Although I guess I’m not surprised when I think about the contracting things. If I had the chance to have an offline conversation about folks that have and consistently use strong contracting standards, it’d be interesting to see what you think about the idea of how well they integrate with the other processes of a delivery of a project but… So yeah, this is good. This is good input.

All right. The last thing we’re going to talk about now before we go into the AECOM story is just the process associated with implementing these integrated standards. And I’ve used this kind of framework many times over the last many years. So it’s really about leadership, establishing a vision for the organization, what is the long-term goals of the organization, the scope of the role of the organization, what kind of framework do we want to place the organization in? And organizationally, how it going to change and how do they want to change it? And then using that vision to then establish a process framework and we’ll show you an example from AECOM later about high level, how do we break out our organization into the major process areas and how do those process areas interact with the participants in a program? And also, what are the key data flows that have to be supported?

And from there, now we’ve got a framework that we can start splitting up into teams based on the various process areas and go through that process of gathering requirements and designing the solution, and recognizing that that can be a somewhat iterative process that as you get into the lower details, you might realize, “Oh, I made some bad assumptions up above.” And so there’s a little bit of back-and-forth, but at the end of the day, you want the organization to come through with a design and then be in a position to pilot, deploy the design. And then from there, learn from those pilots, refine what you’ve got, and then move into continuous deployment of the solution. And what I like to think of as a learning organization, just a continuous growing and growing and growing of the organization, adjusting, adapting and improving. So any thoughts from you on that, Osama?

Osama Abdelfatah:

So I agree on all of that, Rick. It’s going through this process itself it’s a journey. Yes.

Rick Rients:

Yeah, yeah. We’ve been living it.

Osama Abdelfatah:

Yeah.

Rick Rients:

Yeah. So let’s hand this over to Osama for a few minutes to talk about the AECOM journey and story.

Osama Abdelfatah:

Thanks, Rick. Glad to share part of this journey with team here. At AECOM, our vision and leadership commitment extends beyond just leading the program management. We actually aim to drive the advancement of the entire industry. And we recognize that to elevate program management it’s essential to redefine and enhance the program control services as well. Next slide please, Rick. So we also understand that to deliver programs successfully and achieve the desired outcomes, it requires more than just an integrated system. In fact, we require a comprehensive framework of talent, integrated systems, process and procedures. And the solid foundation here is the governance. So this framework to deliver programs, must embrace the drivers of program success in order to create visibility and align goals, integrate the supply chain that you mentioned, Rick, and establishing a robust risk systems and also needs to address the program challenges in order to instill confidence among the stakeholders to ensure the achievement of desired outcomes. Let’s go to the next slide, Rick, please.

Rick Rients:

Okay.

Osama Abdelfatah:

So how we do that, and that’s where our journey actually started with the program controls engine, which is based on an ATS. It’s to have that framework in a centralized solution with a comprehensive program management and control scheme [inaudible 00:27:22]. So our vision to the program controls engine relies on few concepts and I’m very glad to share some of these concepts with us here. One is addressing all of the challenges around constructions and embracing the drivers to success. Two, having global standardized process and procedure for managing major programs. Third, which is extremely crucial, which is I believe that 80% of the processes and standards used to manage programs are common across the programs. And the rest of that 20%, which is what’s really unique about each program, we actually address that in our informed initiation phase. So applied all of our best practices and knowledge was in that framework was crucial and the controls engine with that vehicle to do that. But again, we learned that you cannot just create something and leave it. We need to continue improving.

So continuous improvement and application to the lesson learned is always backed in our theory and our practice to the controls engine. And this global standard would result in improving the oversight of the major programs and helping our clients to support their vision and deliver their legacy with them. So let’s go to the next slide.

Rick Rients:

Yeah. One thing I want to point out on this vision step is a lot of customers that I work with underestimate the importance of leadership and vision because if you don’t establish a vision and then drive it and manage the implementation of it, you’re going to run into resistance. And if the leadership isn’t pushing for the change, it may not happen. And so this concept of vision and leadership driving is essential to success.

Osama Abdelfatah:

Precisely. That commitment from leadership to push things around is extremely important. If we go again, Rick, to that slide, it really summarizes a lot. It’s all about data. Yes. And the concept here is to put data into actions. And as we all know that the life cycle of a project and a program, there is tons and tons of data that we’re dealing with. So that’s the amount of data that’s generated throughout the program. Life cycles need to put in action and we need somehow to transform data into information and intelligence that can drive our informed decision. And the most important thing here is as you see it, is the governance, yes. Even putting a data governance around all of that stuff to integrate all of that since you’re getting data from different stakeholders in a different forms, in a different format, different functions, how you integrate all of that stuff together, bake it, in order to drive that transparency and improve the delivery of major programs. Let’s go to the next slide.

As busy as that diagram, it’s extremely crucial to look at it because it summarizes all of the important aspects that we’ve been talking about. It summarizes what did the process require to plan and manage and measure programs. These processes represent the potential services that even any owner or companies like AECOM may serve the client with. Then it’s steps. So once we put and develop this process area framework, it’s the first crucial and important step. Then we start thinking about including all of the complexity around stakeholders and their interaction. Also, the data flow between all of the key players and the process areas. Then the level of integration between all of that stuff. And there is three levels of integration I always talk about when we come to this graph, which is the vertical integration, which is having the program level or even the enterprise level and the strategic level and the program level and then project level.

And then you go down deeper to the contract level or the sub-constructing. Tying all of that vertical integration is extremely important and having a seamless workflow around it, it gives a great opportunity to align between the top-down strategy of the program and the bottom-up execution strategy, which is extremely crucial as well. Why is that important? Well, when we put a plan, we always seek to optimize it. Yes. And without having that overall holistic view, it’s extremely crucial because you need to consider all your funding strategy, you need to consider your procurement strategy, supply chain and risk profile as well. And without having that holistic view, somehow things will go wrong. Second level of integration I always think about, which is having a framework can support the program from initiation to design to procurement to construction to close out. And that will require as well, part of that integrated system is crucial as well.

And the third level of integration is having all of these pieces together, talk to each other, cost scheduled risk management, have the ability to have a breakdown from the estimates that support the schedule, have the ability to create a risk adjusted schedule and risk adjusted cost, have the ability as well to push all of this information to our team in the field and the inspectors through an iPad or any tool to verify, apply all of their own value or the claims against what the contractor is claiming against and speed up our workflow. It’s always crucial as well. So having all of these pieces together is extremely crucial for managing complex programs. But again, it takes lots of steps and it’s always start with having that framework of process areas and then dive deeper around requirements and the design and that we’re going to discuss in the next slide.

Rick Rients:

So I’ll add a couple comments, Osama.

Osama Abdelfatah:

Sure.

Rick Rients:

Yeah, I’m going to add a couple comments. So this diagram is actually the diagram we worked with AECOM to define the process areas. And then within here, we drilled down into each box, looked at the next level of process and looked at the requirements of stuff. Now every organization is going to have a different type of process flow. I mean, a general contractor is generally not going to have the capital planning level of stuff in this diagram. They’re going to have things like pursuit management and estimating for a pursuit and scheduling, cost management, field planning, field execution management, things like that. But the point is if you look at this diagram from their perspective, from an owner’s perspective and from AECOM as a service provider to owners, I think hopefully you can see how this could be a helpful framework for really defining those requirements, which I think, Osama, is the next slide.

Osama Abdelfatah:

Precisely. And as you mentioned, Rick, as we said, it’s a complex process and it’s complex integrator as well. So bringing all of the stakeholders, getting the designers, getting the contractors, getting the owners, getting the consultants work together, that would shape that frame. And the next step, which is the next level from that graph, is more tactical steps. Yes. So as Rick mentioned, every block that you had in the previous slide, we went through it and defined that process areas from inputs to pinpoint to critical capabilities within, and then the process itself in order really to get the outputs. Yes. So that it’s a step by step, require a lot of thinking as well, a lots of experience that we’ve been there, we’ve been in the field, we interacted with every stakeholders and we know exactly what the pinpoints that we’re trying to solve for in order really to get the requirement for the design.

Rick Rients:

Yeah. And I want to make sure people understand. I mean, we did this over the course of a few weeks, maybe a month and a half, right? So we avoided the trap of analysis paralysis because you don’t need all of the details, you need the big picture, you need the large requirements, the critical requirements, and understand the high level flows because then when you get into the system design, you actually can deal with some more details and then it’s an iterative process. After you go deploy, you refine, refine, refine.

Osama Abdelfatah:

Precisely.

Rick Rients:

Speaking of deployments-

Osama Abdelfatah:

Great. Speaking of deployment. So the past couple of years have been successful story for us and for InEight as a partner with us. We deployed the program controls engine across several programs worldwide. In essence, we witnessed effectiveness and durability of our vision and design, but also we have lots of accumulated valuable lesson learned through this process. And that’s the key. The key here as I mentioned earlier, it’s continuous improvement. We can’t just drive something and leave it. Since the technology evolved, since the programs and the methodology evolve, there’s lots of lesson learned. Yes. So some of the lesson learned around these deployments are variability of program controls concept. So there’s tons of them. So we started with couple and then after that we realized that there’s more than that. We start baking that in our journey as well. And we were able to refine our understanding of how to apply all of different design concept to different programs and realize that even going through the actual implementation process with the team is forcing a deeper level of design details.

So as Rick mentioned, don’t start there. Don’t start big and you’re going to stay there. Start somewhere with incremental improvement, yes, and that would lead to that continuous improvement. Yes. It’s also critical to involve the program team in the design discussions. We can adjust in both something and we go there and just do it now. We learn that it’s crucial to involve the program team and get them to understand what we are building for them and provide the leadership direction when critical design decision need to be made. So part of what we always doing, identifying who’s the process owner, who’s the subject matter expert, who is the list of the key user they’re going to be using. So everybody knows exactly the governance around it, who’s doing what and how and the interaction between the team. Yes. Another lesson learned is the phased approach and why is that? We are trying not to consume the entire team. With the phased approach, we give brief to the rest of the team while we are focusing on something.

Since we’re talking about an initiation phase. Yes. We talked about we’re starting with 80% of same things and the 20% is the unique need for the program itself. Yes. So we try not to consume the entire team. We try to have it a phased approach. So the program itself or the team will be focusing on development of the BGM and getting the governance around the program itself, getting to understand the program and the details around it, getting them to interact with the client and then just have a better understanding of everything. Yes. So that’s another one of the huge lesson learned. And the last, hopefully is not extremely last, but one of the most important one too is adoption. Yes. Ensure continuous monitoring and support to the team. We always know that people tend to revert back to what they are comfortable with, which is fine, but at the same time we are pushing for change. That change would lead the entire industry. Yes.

So these are part of the lesson learned, but what are the benefit that were very tangible for us when we started learning? Well, was that having that 80% design and just the 20% that speed up the deployment? Yes. So we have a speed of deployment and then at the same time we empowering our team with a solid framework. Yes. It’s not a tool, it’s a framework. We are enhancing the capability within our talents. Yes. So the learning curve is always positive because we’re not starting from scratch like before, now a learning curve is moving up, everybody’s learning something in major programs, and we take that lesson learned and move to the next programs and you learn something new. So the learning curve is moving up and then improving the visibility and inform decisions around the programs. And then ultimately, which is the most important element for us as AECOM, is supporting delivering the program to meet the desired outcome from our clients.

Rick Rients:

Two last couple of quick notes. So let’s talk a little bit about contracting and then we’ll talk a little bit about what I’ll call self-performed type of work. One of the things we see as we’ve been deploying the program controls engine is the variability of contracting standards and expectations. And what we’re driving at now is to get out ahead of that and try and set expectations about what are the key concepts that we have to make sure we have included in the contracts and have them properly structured so that the organization, the vendor or whatever you want to call them, the expectations are properly set for the way they are going to be integrated. So as you look at this diagram, first there’s evaluated scope alignment. Well, what does that mean? A lot of times we’ll have things like bills of quantity and schedule of values and things like that. And usually those things are a very high level list of things, quantities with maybe a unit price kind of thing, potentially. And that’s a good start.

But what we really want to see going forward is to have that bill of quantities to be structured in such a way that not only do we see the total quantities, but we also want to start to be able to see where in the program or project those quantities need to be realized. They have to get tied into the schedule really so we can say, “Hey, at this point in the project we should be doing this kind of work or this vendor should be doing this type of work.” So properly structuring that is a huge value add from a management perspective and tracking. Then there’s also the concept of schedule alignment, which is different than bills of quantities. I mean, the schedule is the most important to document in a program or in a project because it breaks the thing down into what’s happening where and when and all of that good stuff. And if you’ve got multiple partners involved in a project, they all got to be looking at the same schedule and they need to have the expectation that their input into that schedule has to be properly structured and properly reported.

A lot of times we get the contractor submitting a schedule, well, that’s wonderful if I got a 25,000 line schedule, but how do I align that to what the actual project itself needs that goes beyond what that contractor is delivering. And so we’ve got to make sure that we set some expectations and standards around how that schedule is going to be structured. And/or if they aren’t providing a schedule, how do they interact with the project schedule? So there are activities in a schedule that apply to other people that they can go… Like in InEight, they can go online, pull up the schedule, see their pieces and put in the progress and remaining durations and things like that. So that has to be set in the contract. Then of course, how do they report the contract processing? If we’ve got a goods bill of quantities and schedule of values, it’s going to be pretty easy for them to submit their progress.

There could also be situations where there’s field inspectors actually recording things and we’ve got to just be clear about how that process is going to happen and set those expectations around who’s actually recording the official progress against the contract. And then lastly of course the invoicing, a seat of invoices with the appropriate supporting documentation and being able to look at that stuff and verify it against what has actually been recorded in the previous steps is another concept. And also submitting that stuff in a standard way into the document control system. So those are some things around contracting that we’re seeing that I think are lessons learned that I think we could do a better job when it comes to contracting.

Osama Abdelfatah:

Yeah, it’s crucial as well-

Rick Rients:

For our organization on-

Osama Abdelfatah:

Sorry, Rick.

Rick Rients:

Sorry?

Osama Abdelfatah:

It’s always crucial to have that embedded in the contractual agreements to apply them.

Rick Rients:

Yeah. Exactly. Yeah. And then the last thing before we wrap this up is really thinking about what I’ll call self-perform, but we’ve got our engineering firms here that have their deliverables and their teams and resources involved. You have contractors that are actually doing the construction work and have their crews and equipment. So you need to be thinking about in this system, how do I integrate that into my budget and schedule? How do I break that down to a level of detail to where I can actually see what are my deliverables, who’s working on which deliverables, how much have they completed? And are they on target for the amount of effort spent versus what we thought it was going to take? What’s their earned value of the work they’ve completed? And so within the system, you want to tie it into the schedule structure and tie it into the budget structure so you’re really seeing true earned value based on progress and effort and expense expended on the project.

So having said that, as a wrap-up, we’ve introduced the idea of what is integration in the capital project space and what’s the process of getting that implementation and improving your integrated flows and integrated processes. And we’ve looked at some of the contracting and self performed kind of things. And I could say that InEight is capable of supporting all of that. And the things that we’re seeing across our customer base at this point is there are some significant benefits around certainty of project delivery, controlling costs, controlling issues, managing risk, mitigating safety concerns quickly, dealing with quality issues quickly. All of those things are becoming instantly available as they occur on a program because of an integrated platform. Any final comments from you, Osama?

Osama Abdelfatah:

Rick, I think this is very insightful and I, myself, learned a lot here today.

Rick Rients:

All right. All right, so we’re at the Q&A stage. Adam, I think you’re going to take over.

Adam Palant:

Yes, I am. Thank you so much, both of you. That was a great presentation. Now before we address your questions that came in throughout the webinar, I would like to remind you that we encourage your feedback. Please take a few moments to complete our webinar survey, which you will see on your screen now or you’ll be redirected to it at the end of the program. So let’s get to our first question. So how do you see the role of artificial intelligence impacting this issue? How important is AI usage governance at a corporate level?

Rick Rients:

Well, that’s a great question and we are thinking a lot about that these days. But I will say that actually the story begins probably 14 years ago when the company I was working for, a large general contractor here in the US or North America, keyword, they were all about data analytics and things like that, which to me was a forerunner to artificial intelligence. Artificial intelligence is a far more efficient way of doing it. And what I will say is that the foundation is AI’s fundamental base of greatness, if I could say that, is having good data underneath it. And so having a platform that captures data consistently gives you a place from which to start your mining of data. And that’s what artificial intelligence at least in part is going to be doing, is it’s going to be looking at past projects, past costs, past schedules and pulling out of those things, lessons learned and making that information available to future projects.

And so to me, in a very high level and possibly simplistic way, that’s how AI fits in. Now have we figured out exactly how that’s going to work from a software platform perspective? No, but we do have some places where, like in InEight in our schedule environment, you can have a very rudimentary kind of artificial intelligence going on where you’ve got a database of past schedules and you can compare your new schedule to the past schedules and identify where you’ve got inconsistencies, as you’re going to see things like that or benchmarking. You’re going to be able to see when you’re doing an estimate, the ability to go out and mine data and be able to come in and say, “Hey, this type of operation that I’m trying to estimate is showing me [inaudible 00:51:54]. And it’s got these kind of parameters around the environment that we’re doing it in the climate, the location and is what I’m estimating comparable to what artificial intelligence would tell us?” So I feel that’s where it’s going to head at least when it comes in the near term. Longer term, I can’t see beyond that.

Osama Abdelfatah:

Great point, Rick, if I may add. So assume that we’re putting a plan for major programs and it requires a lot of complex steps. Yes. So let’s assume that we need to integrate all of these together and then run lots of scenarios to get the optimization, think of the steps that we need to do. So think of the time currently we need to do and take to really get to that optimization and run tons and tons of scenarios and get to the optimum scenario. So if AI can help us doing that, considering all of the factors, considering all of the risk profiles and the strategies around delivering major programs and put all of that together and then come to a point that we pick or select the right scenario and then look at other scenarios as well just in case if… What are scenarios around it too if something happened like this? What is the right mitigation measures around it? AI can support on that drastically and that’s what I’m really looking for in the future.

Rick Rients:

Yeah.

Adam Palant:

That’s outstanding. Yes. So we may have covered this and we may not. How do you see controls differing for self-performed work versus GC, sub management work?

Rick Rients:

Well, I think it’s the level of detail that you have to manage, right? I mean, if I’m a piping contractor, I mean, I’m going down into a lot of very detailed weeds about pipe diameters, materials, weld types, hanging structures. All of this stuff is incredible amounts of detail that has to be defined and understood. And I will say most contractors understand their work. So now it’s a question of, is there a system that you can put that into to say, “Okay, I’m doing this type of work. What are the materials I need? What are the equipment I need? What are the people I need? What are my productivity factors for this type of a weld?”

So being able to though bring that all inside of a system and even at the estimating stage, being able to use that information to estimate that work accurately and then be able to put together a bid based on that estimate is very different from an organization that deals with contracts because they’re going to either have a gut feel about how much some certain operations may cost or they’re going to go to a contractor and ask for a bid, and so they’re not going to deal with a bottoms up. And then owners are even at a higher level of less detail than the others. And so to me that’s how this all comes together and is capable of being done in the InEight platform, in an integrated platform.

Adam Palant:

Excellent, excellent. All right, beautiful. So next question, what data flows between partners are the most challenging?

Rick Rients:

Oh. Yikes. I’m going to say schedule. I find schedules, some are so detailed and the structures. And that scheduled world today in the current world is so isolated. If you’re a scheduler, you own that space and hardly anybody else gets access to it. And then trying to apply standards all the way from the bottom to the top, the contractor through the general contractor up to the owner, really it’s a challenging nut that we are starting to crack, but I see that just the complexity of all of the data structures are very complicated. So I see that as the hardest space. The next hardest will be model data, which I think timing of the available amount of data is often difficult. And then aggregating and standardizing model data is pretty hard as well. And then lastly, integrating model data into the project, the delivery process is another level of complexity. So those two areas are mine.

Osama Abdelfatah:

Yeah.

Rick Rients:

Osama, what do you think?

Osama Abdelfatah:

I would say it depends. Yes. I would say it depends on the maturity of the organization, the owner, and what is the requirement around cost of schedule or risk remodel. Yes. I would say if we have the requirement already embedded in the agreements, contractual agreements, make things a lot easier. I would say the most complex thing is the alignment between different process areas, aligning between cost structure and the schedule structure, the WBS and the cost breakdown structure or even bringing that risk as well. That alignment when it gets to a major programs, it becomes really difficult. And the number of stakeholders. Yes. So similar to whatever you mentioned, Rick, on the schedule itself. If you have different contractors working on the same project or a program and you don’t have a list of requirements around how the schedule look like or what’s the metadata or the coding structure or the WBS, same way if we don’t have that on the cost side as well or how the schedule of values should look like and tie back to the cost breakdown structure and then you tie that to the schedule as well.

That’s why I said it depends. If you have a requirement around things like that, makes easier. Lack of requirements would actually make it harder from schedule or cost or others.

Adam Palant:

Here’s a good one that came in and it came in a couple of times. Can you talk to the challenges getting vendors to get on board with your integration approach?

Rick Rients:

Yes, it’s challenging. But you’re the customer, so you have to be willing. I mean, first of all, you have to have your game plan in place. You got to know what you really want from them. As I said on that vendor contracting thing, there’s certain data flows that you’ve got to be clear about. And if you’re clear about that, most vendors don’t seem to rebel too much or charge you an arm and a leg. But if you come back later and try to ask them to do more work, it becomes a change order and costs you more money. But yeah, there’s certainly some resistance there, but I think having a good standard and a good structure upfront and going to them upfront with that makes a big difference.

Osama Abdelfatah:

And the keyword here is contractual agreement. Put all of what you need in the contractual agreement. Nobody would actually resist.

Rick Rients:

That’s right.

Adam Palant:

Excellent. Well, those are great answers and these are great questions. Thank you, everybody. But unfortunately, that’s all the time we have for questions today. Please join me in once again thanking Rick Rients and Osama Abdelfatah as well as the sponsor, InEight. Now if you have any additional questions or comments or if we didn’t answer any, please do not hesitate to click the email us button on your console and we’ll share them with our presenters so they can respond directly to you. If you didn’t have a chance to fill it out earlier, you’ll be redirected shortly to the post-event survey. We look forward to hearing how to make our programs work better for you. Visit enr.com\webinars for the archive of this presentation to share with your colleagues as well as information about upcoming events. Thanks again for trusting us with your time. Have a great day.