Mastering Scope Control: Strategies for Project Success

Shoshanna Fraizinger:

Hello everyone, and welcome to today’s webinar. Good morning, good afternoon, good evening, wherever you are. My name is Shoshanna Fraizinger and I will be today’s host of the webinar on behalf of the tech board.

And so while everyone is entering the room, I’m just going to go over a couple of housekeeping rules for today’s event. The speakers have an introductory poll as well as an exit survey that they request you complete. You’ll see the prompts as they move through their materials. The presenters will also be taking questions, so if you have a question, please enter it into the Q&A box. It’ll be down at the bottom of your toolbar. Don’t put it into the chat because what we’d like folks to do is upvote those questions that they are interested in hearing the answers to by clicking that thumbs up icon next to the open question, those questions will be addressed first. If we don’t get to your questions, the presenters will attempt to answer your questions in a follow-up email.

Today’s presentation is also CEU eligible. It’s also being recorded. Now, attendees will receive a copy of the presentation recording as well as the slides and the certificate of attendance containing those CEU credits within the next 48 hours or so.

Today’s topic is one I am really excited about. We’ve all had these kinds of challenges, so I’m really excited to hear about Mastering Scope Control Strategies for Project Success, which is sponsored by InEight. Our two speakers from InEight are John Upton. John serves as the vice president at InEight.

He heads up InEight’s control plan, progress, time center, design, contract, and change products. That’s a whole mouthful. John has spent over 15 years holding positions as a field engineer, superintendent, project engineer before he started delving into the construction technology space, including the most recent large engineering and construction organization. He uses his vast construction experience to ensure customers are receiving field tested and proven technology, and he graduated with a bachelor’s degree from Nebraska Wesleyan, I hope I said that correctly, John, University.

And along with John, we have Jake Sjuts. He’s a project manager at InEight, and Jake leads the vision and delivery for InEight design product, which focuses on engineering, project planning, resourcing and progress tracking. Jake also leads the platform product with a focus on suite administration, master data and API management.

Jake has spent the last 11 years in the engineering construction technology area and he’s delivered a number of products, ERP customizations and integrations. Jake holds a master’s degree in management information systems, also from the University of Nebraska, Omaha.

And without further ado, I’m going to turn it over to today’s presenters.

John Upton:

Thank you, Shoshanna. Appreciate the intro and good afternoon, good day.

As Shoshanna mentioned, we’re excited to talk about scope management and all the fun that comes with that. But before we get into that, a little bit about InEight. We are a leader in project control software for capital construction. As you can see by the diagram, we cover project information management, cost and scheduling, construction operations, change management and design management. And we are a modular and integrated platform. And as you can also see, we’ve been around a little over 10 years. We have customers across the globe and there’s a lot of money running through our products right now.

So before we get started, as Shoshanna mentioned, we’re going to run a poll to get a little better understanding of who we’re talking with today. There’ll be two questions, what best describes your organization, and what best describes your role. So if you take a minute or two to select the most applicable answer, we’d appreciate it. We’ll give you a couple minutes.

And while you’re making your selection, today we want to talk about what scope means to different roles throughout the project lifecycle, how do you align scope management across different stakeholders and all of the challenges that are involved with that. And there’s a lot. And then also why an integrated platform and strong business processes are essential for managing scope and driving accurate earned value management practices. So we’ll wait a couple minutes and see what the results look like.

See some old friends joining. Good to see some of those names. All right. All right, so looks like we have a lot of owners and consultants, general contractors from a role perspective, project management, cost controller, good. And scheduler. Yeah, I think we’re going to touch on a lot of those roles today. So, appreciate everybody partaking in that poll and we can get started.

Jake Sjuts:

So yeah, hi, my name’s Jake. So yeah, what is scope, right? Scope management is how, at a high level is how a particular role defines, manages and completes their portion of work.

But what we find when we really break up scope management, because scope management is kind of that broad topic, right? Scope management is typically made up of business processes, technology, government or governance, sorry, and standardized data collection throughout that project life cycle. And what we typically see is a lot of roles have their scope management processes, but a lot of times they’re limited by either business process, technology, data collection means that they aren’t necessarily getting that integrated scope management process that really drives improved project controls. So that’s kind of what we hope to talk about today. We want to really touch on the roles between scope… The relationship between scope and data on these roles and see what we can do to help you improve some of your processes that you in place today.

So leveraging a number of those roles we just kind of took from a survey perspective. So when we talk estimator role perspective, they do quality takeoffs, the cost controllers working with the work breakdown structure, they got their budget forecasts, et cetera. The engineers and designers of the world are tracking progress and earned value on their deliverables and trying to get those delivered on time so that way construction or the contractors can consume them as expected.

You have the superintendents, field engineers working on work packages, components, ultimately planning out the work on the execution side and building out the plan and ultimately the implementation and installation of all the work that goes on in the contracting, or construction side of things. The scheduler, trying to work with all these different roles to kind of understand where all these different groups at with their different pieces of scope and the delivery of those scope items. You have the document manager ultimately having their own document scope management processes where they’re managing the issuing of said documents, managing that document repository.

And then the owner itself, they just want to get information or data from all of these different roles and to be able to consume the data and the output from the estimator, from the cost controller down the list there, to get that information, to understand ultimately is my project on time and on budget. So that’s kind of where we wanted to start at today is just at this high level, this one we’re saying scope and with these different roles, hopefully taking a good picture of what we mean by scope.

But then ultimately we’re going to take a step down to really understand the data that makes up these scopes and then kind of really talk about the challenges of a lot of these scopes rely on the data from these other roles. And so we’re talking scope management, understanding that it’s important to build out the roles and the relationships with the data to be able to get to ultimately the automated reporting and information to come out of the system to be able to drive better business decisions, better project controls, processes, et cetera. So with that said, John’s going to talk about-

John Upton:

So let’s talk about how the scope is collected. So we got cost, we have schedule, drawings, work plans, we got all of this vendor information, actual progress and it’s all working harmoniously together at the same speed, no changes, everything’s like the gears you see there working nice and in tandem.

But that’s false, right? That never happens. There’s change all the time. And reality is it looks more like this. It’s a chaos. Timing’s rarely synchronized. Scope increases, decreases, gets omitted, and changes don’t flow systematically across all stakeholders. So scope in the middle there, as it changes, it has different effects on all those roles that Jake just mentioned.

So let’s talk through some of the challenges that this crazy page is trying to represent.

So we’re going to walk through an example here and going back to some of those roles that Jake alluded to earlier. We have our cost controller. So these guys and gals, maybe a cost engineer, maybe a project engineer. They’re managing what we’re calling cost items, or these buckets that you typically see on a cost report. The main purpose for these is they’re managing their budgets, their forecasts, their actuals, all in an effort to see, “Hey, are we beating budget? Are we making money on this project or are we going to be out of pocket?”

And some of the challenges with this is what level of granularity do you want to manage this level of detail at? For an example, if we think of two to six inch carbon steel pipe, I don’t need to know the cost or forecast each iso that makes up the entire project’s two to six-inch carbon steel pipe, but as a whole collectively I need to know that information, which ultimately that information being the budget for that sum of pipe, and obviously forecasting that sum of pipe ultimately to drive benchmarking and past cost for future work down the road.

Jake Sjuts:

Yeah. So what John kind of alluded to there, right? You have a cost item with that higher budget, rolled up data from a scope perspective on the cost item within that work breakdown structure.

But then you have the engineering and designer that made the discipline leads. You have your engineering management team that’s managing the deliverables that are ultimately going to be delivered as part of that cost item that’s over here and maybe in another system, maybe in the same system. But ultimately the data with the deliverables is related to that cost structure and to that cost item that John referenced there.

So the engineering design leads, they’re going to be looking to control scope within their scope management process. They’re going to do a takeoff of and going with the same example that John kind of started there with the installing and pipe. We got to go design out all the isometrics that are going to be required for said pipe. So ultimately I’m going to do a takeoff of all of my individual deliverables. I’m going to be able to be able to ultimately consume my budget information in, I need to be able to track process, progress that earned value management.

So as I’m progressing my way through those different deliverables, even though I might be working at them on different times, being able to understand where we’re at from a percent complete perspective and having the quantity of man-hours communicating back to that cost item. So understanding what data is going to be coming from that cost item and then what data is going to be going back from the deliverables to that cost item is kind of a critical thing to understand from a data perspective when you’re kind of mapping out your scope management business processes.

The engineering design leads are also trying to understand change management, as we’re working our way through these projects. How if owner request comes in, maybe it’s a constructability concern, maybe there’s… We’re added scope, removed scope, how are we going to add scope here? How is that scope going to become relational? How are we building in the governance for the life of the project to be able to control scope for those engineers and designers.

Ultimately too, on the engineering design side, we ultimately need to be able to allocate resources and understand when we need to allocate those resources. So dates are critical to be able to understand which deliverables, which isometrics are due when.

And then so from a challenge perspective, we need to be able to have my design scope be relational to that cost item, be relational to that schedule activity, be relational to my document control solutions so that way, as different levers are pulled within those different roles and business processes for scope of management, we can understand what that means for my independent process here and then report back accurately. So just being able to manage resources, dates and progress are critical from a design lead perspective.

John Upton:

Yeah. And then if we pivot that over to the execution side, we talk through our field guys and gals, our superintendents, our field engineers, they’re breaking those cost item, that two to six inch steel, down into all those separate isos and then they’re further breaking it up into construction work packages and installation work packages.

And their main objective is to be objectively progressing these components, as we call them, to the most accurate percent complete. The challenge being, as you can imagine, there’s thousands, I mean we have some projects that we see with 400,000 what we call components which are further breakdowns of those cost items that the field crew has to go manage. So back to our example with the 20 isos that Jake mentioned from the engineer, that could make up one installation work package in one area. And then you can exponentially multiply that by however many areas and installation work packages you have. And that becomes a lot of data.

And as I mentioned with the cost item, we don’t need to know the cost of each iso, but now with the field guys and gals, we do need to track the installed quantity. That’s their scope that they’re really focused on and we need to track that for each and need an understanding of the budgeted man-hour factor that comes along with each iso, and that comes from the cost item.

And then I use all of that to see as a field engineer or superintendent, even a foreman, knowing that budgeted unit, now I can plan my plan and if I’m planning to fail or if I’m planning to earn more budget based on my crew size and the plan quantities that I’m planning to install. So there’s a lot and we’ll continue to cover this, but the granularity of scope per each role fluctuates greatly. So next we have our scheduler.

Jake Sjuts:

Yeah. So with the scheduler, obviously what they’re doing and what everybody cares about is the dates, right? Everybody wants the activities, everybody wants to know which activities are related to which ones of my scope and ultimately when do I have to deliver on those activities, to keep the project on time and on schedule. The scheduler is also maintaining all the milestones, the logic, the duration.

But yeah, those dates are critical to the scope that’s maintained within all of these different other roles that we’ve been hitting on here. So going back to that designer engineer, I need to know when I need to deliver those deliverables, those isometrics, from a date perspective, those dates could roll up to the cost controller to the cost item to be able to forecast my cost accurately. So from if the duration of the activities related to that scope and that cost item is over X amount of time, I can start to my costs accurately. From an superintendent and execution side of things, I need to be able to know from a, well, ultimately when those isometrics are going to be delivered so I can plan my work on the execution side so I can ultimately look to deliver.

And where we’re seeing this is on a number of these kind of call it alternative delivery contract models, project models that are out there where you have your design build, your iterative progressive design build kind of projects where we might be designing a scope, that scope’s going to get handed off to the execution side, they’re going to go start to build it and the designers are already going on the next piece of the scope that they’re going to be scheduling out, or building out.

So getting the data and information to flow between these different roles just becomes more critical and understanding what those relationships are. Because John mentioned the granularity there, on the engineering deliverable side, I might have a deliverable that could be that I have an activity per deliverable but also at the milestone level for that deliverable. So I could end up with 20 isometrics with three milestones each. I might end up with 60 schedule activities, if that’s what your business process calls for.

So understanding how many of each data I’m going to have for each of these roles and how it’s relational to these other roles will really help creating those relationships when it comes to technology. But then ultimately with that data, we can group that all together and I can start to get the information that I need from a reporting perspective to kind of, well, A, get automated reporting, but then B, being able to do actionable insights off of those, off the information that’s pouring out of the system. I don’t have to have individuals try to pull the data out of this system and out of that system and merge it together. And then another system I can see… I can have it all kind of automated and get that automated reporting.

Yeah. John’s now going to talk to the contracts.

John Upton:

And lastly we’ll talk a little bit about contract managers. So these are the folks that are managing our subcontractors, or vendors on the project. And most importantly the purchase order and line items that make up these contracts, because the scope to the contract managers, these line items that ultimately a subcontractor is going to progress.

And there’s lots of risks with subs. I would say typically subcontracts, depending on your project, in my lifetime, they made up a large portion of the contract. But the challenge with subs is trying to efficiently manage them like we do our own direct work. So maybe we have a sub in this scenario that’s welding the pipe or testing some of the pipelines. We need to know how they are performing both from a cost perspective, because we still have to forecast that in our project, as well as the time that they’re utilizing for their work.

And so as Jake alluded to before all this is connected, which we’ll see here in a minute, but if we’re not managing them like we do our own personnel, we won’t be able to identify risks that could potentially result in change orders based on scope creep or a scope change in general. So as you can imagine, all of this information is connected. And Jake, you want to touch on that?

Jake Sjuts:

Yeah. And I kind of got ahead of myself there, but I mean the reality is that these roles, all this scope is relational. It’s relational at that data level and the business process really needs to drive home how and when this scope is taken off and needs to drive home, how are they relational? I mean from a quantity and man-hours perspective, certain attributes really come into play. Making sure everything aligns and making sure when we’re tracking a cost item that it’s going to reference those 20 isometrics that we’re going to deliver on the design side and all of these components that we’re going to ultimately go and install. And being able to make sure that you don’t have data conflicts as you’re kind of mapping out these different relationships.

Because ultimately when you kind of define the data that you need based on the information that you want, you got to go find a technology solution that’s going to be able to get you to be able to collect that data and then make that data available. So just making sure that you understand that data relationship.

And if we take that activity, for example, schedule activity for example, I need dates from those activities, but if my activity is not associated in my cost item or it’s not associated in my deliverables or it’s not associated in my components or my contracts, I’m going to have to maintain dates on my isometrics. So I have a set of dates here and it set of dates over here and I don’t really know what the source of the truth is. So the more you can create a relationship with this data, the better you’re going to be able to function off that source data and make your business processes simpler to be able to manage your scope.

And understanding dates are going to come from the schedule. My progress is going to come where I’m tracking my engineering deliverables. My forecast is going to come from my cost item and knowing which source data is coming from where with these relationships.

John Upton:

Yeah. And as Jake mentioned, all of this is relational and you could draw arrows all across the place and it’s meant to look ugly because the reality is it’s all relational, but typically a lot of customers are relying on disjointed silos connected with Excel or SharePoint, emails or even phone calls and that’s just not advantageous to keep scope inline and integrated with all the other stakeholders that rely on that same information.

And I know we’re going to answer questions at the end, but real life example, somebody asked about the superintendent, are they in charge to develop your three-week look aheads or your daily plans? And I would say absolutely they should be involved with that. Obviously somebody in the field needs to be giving some rational reasons on duration expectations rather than a scheduler just making the assumptions himself.

But I have a cell phone between my superintendent and scheduler and lots of times back in the day, that’s how we communicated, right? We didn’t have anything integrated where I make a change as a superintendent with a duration of my installation work pack and have it automatically update my three-week look ahead or the critical path schedule because there was no option for that. There was just we relied on Excel and phone calls and emails.

And then obviously going through this scenario a little bit further, obviously change orders happen. Change is inevitable. Scope could be deleted. So in this example, as you can see, some isos might’ve been deleted, that’s an isometric in terms of piping, there was a question about that. And when that scope gets deleted, obviously that’s going to affect my work packages, it’s going to affect my activities in the schedule and it may affect a vendor change order from my contract manager to reduce the scope of my purchase order. We also know that not everything just gets deleted, but we could add or edit existing scope.

And the picture here is really meant to represent that all this scope is related. And when one change happens to one role, it has direct effects on everybody else. So now that we added scope, the scheduler, we might’ve had 10 days float on an activity that now is on the critical path because we’ve added additional scope. And if you’re relying on spreadsheets and other methods that aren’t integrated, it could be one duplicate of entry, a lot of it, and very error-prone.

Back in my former life with the company I was at before we went through our digital transformation, you get a change order and we would have to… That updated our budgeting units for example, but we had to go make that change in 10 different spreadsheets and hopefully keep everything in sync. And I’m sure everybody has their Excel wizards that use pivot tables and lookups and all that and you get one error in those calculations and it can really screw things up for everybody. So the lack of integration is quite the problem.

So why do we care, Jake?

Jake Sjuts:

Yep. Yeah, so I mean ultimately we needed to improve our project controls processes. We need to know that when we have integrated scope management, we can get a good transparent vision from the information that’s coming out of these systems of what are our project boundaries, and where are we at in terms of delivery on the scope within those boundaries.

So from a performance metrics perspective, understanding where our financial and our operational objectives are at and how are we doing and performing on that. We talked on resource allocation, right? Time is money and if we aren’t effectively allocating our resources, I don’t want to assign a bunch of people that are just going to sit around and not be ready to work because the package isn’t delivered yet, so on the design side of things. So I would need to be able to understand where we’re at from a resourcing perspective in terms of where the scope is ultimately getting delivered.

And really it comes down to improving communication too. And I kind of touched on this before, if we can standardize how we collect this data and then automate the information that’s coming from that data, then we don’t have to have the days-long meetings with all the different stakeholders to get the standard information out the door. We created standard set of reporting, it’s all automated, and then it could be distributed and maybe it’s a dashboard, maybe it’s an email, whatever the case is, whatever the business process calls for. But we could standardize that information and that information ends up being the communication piece to that.

So improving scope management and how we’re doing all that tracking and getting that data into the system ultimately gives us that communication piece.

And then quality, quality is a huge concern. And we have the ability, if we are standardizing how we’re collecting that data for scope management, we can put our control measures in there and we can track how are we delivering and are we delivering as we expected to be, or is there potential risks that we need to be able to address? And ideally the metrics and the information coming out of the system will raise that red flag so we can go dig into those issues and we don’t have to spend all of our time questioning is the data right, we can be looking at the information coming out of the system and being able to act on that information instead of questioning the data.

So it kind of spread the scope management piece within all these different roles, spreads to a number of those different project controls, disciplines throughout project controls.

John Upton:

And also we care because of earned value management. I mean, it’s pretty straightforward. I believe, I assume most of you’re familiar with earned value management, but it’s a methodology that integrates three key components of information to measure project performance and forecast those outcomes.

One of those being schedule, second one being cost. And what this whole presentation about? Scope. And I put that specifically as the foundation of this pyramid because without knowing your scope definitions, it’s impossible to know how much you’re going to spend or how long it’s going to take. And Michael or Andy, it’s not only dates… Oh sorry, cost is the focus here, but time is money. I a hundred percent agree that time is money. But if you don’t know the scope, you don’t know how much it’s going to cost or how long it’s going to take. And without knowing the scope as the foundation, you’re going to probably wear rose colored glasses and have objective optimism bias, sorry.

And in forecasting or progressing where you really think you’re at in your earned value. But if that scope isn’t defined, then you’re not really basing your answers on realistic data at that point.

Jake Sjuts:

So yeah, we’re going to kind of just review some things to consider, right? We’ve talked a lot about business processes, a little bit about technology.

But as we’re going through and just reviewing your different roles and what their business processes are and how they’re tracking their scope management, the business process, maybe do one more click there, John, it’s kind of coming up.

John Upton:

What… You need-

Jake Sjuts:

One more, I think. Kind of weird, but I’ll just start talking.

Ultimately we know from each of these roles and each of these scope management processes, what information do we need that’s going to drive business decisions, right? And then we kind of take it down and break it down a level further. We need to understand what data makes up that information, and who are the stakeholders that are ultimately responsible for collecting that data. And kind of what we were alluding to earlier with all the different roles and the data that they’re collecting for their different pieces of scope, a lot of those different stakeholders all have data that needs to be kind of relational.

And ultimately you need to have all of those different roles kind of functioning in lockstep to make sure that we’re getting all the data and those pieces of data are relational to be able to ultimately roll this data up to the information. So focusing on who those stakeholders are, what data they own.

So the scheduler owns the activities, but are going to have the engineering design leads own the isometrics, those engineering and design deliverables. So understanding that there are different people own the different pieces of the data and that they’re going to be the sources of that data. So if I am taking off an activity here, but it’s not in relational to any scope here, then I have a delta and all of a sudden I can’t potentially report on that. So making sure your business processes have the governance to be able to really define when we’re going to take off scope, how we’re going to manage scope and ultimately deliver on-set scope.

And then yeah, we talked to relationships. And then after all of that, will your existing business process work or do we need… If I need information and it requires a certain set of data that we’re not collecting today, do I have to cycle back and tweak my business process to be able to collect that data? And then if I do have to tweak my business process, do I have to go and actually train my staff to be able to collect that extra piece of data so that we can report on it and be able to get the information to the owner or to the different stakeholders on that project, depending on what’s required on that project. So from the business process, there’s a lot to consider of how we’re collecting the data and how all that’s connected.

And then from a technology perspective, are we utilizing all the technology we can to collect that data? So obviously we kind of hit on the data collection side. If our technology, if we can’t collect the data we need, and/or we’re not using the technology we have to collect that data, then that’s going to be a problem. The ability to integrate systems to get the relationships. The reality is a lot of the solutions out there, they’re in their silos and they don’t have the integrations available, so you’re stuck doing the spreadsheet thing. I’m maintaining my schedule over here and I’m maintaining my scope in the spreadsheet over here and we’re going to do some exports and I’m going to kind of try to mash this together and I’m going to spend a day of my week building out the reporting to get the owner the information they require to be able to know that the project being delivered as expected.

And then is the data available? Data volume. If it’s a ton of data, can I consume that data in a reliable manner to be able to get the reporting that I need? So being able to understand not only are we getting the data, but how much of it is it? And if I wanted to replicate it to kind of bring it together on my reporting end, can I consume it in a reliable manner and make sure that everything’s relational and as expected? So I mean ultimately with the goal there, being able to automate reporting to get out of the business and having to build those ad hoc or side reports to kind of appease all of our different stakeholders.

Theoretically, I could build it out for my organization ideally, but at a project level if not to be able to say, “Okay, for this project every day, every week, every month, whatever the cadence is, this report’s going to come out and we don’t have to massage the data, we don’t have to join it together manually. That just comes out of the system as expected because we have the business processes for scope management in place to be able to make sure that all of our scope has dates on it and we have the costs associated with it and everything like that.”

So with that said, I think the next slide we’re going to talk about walking through an example with those bullet items. So from a business process perspective, we’re going to go after some KPIs. But the KPI, we need the budget, the schedule and the progress data. And the reality is that those could be three different systems and none of those are integrated. Our controllers are owning that budget, our schedulers are owning the schedule, and our field engineers are owning that progress data. Those three roles and their scope manage processes, business processes all have to align so we can make sure our budget data relates to schedule, and our schedule data relates to progress.

And so kind of hitting on that, you need to understand when and how’s that data managed. And obviously we just touched on that, but maybe the budget’s kind of maintained monthly or whatever your process dictates. But then from a progress perspective, maybe we’re doing that daily and the schedules biweekly… And you want to click back one there, John?

John Upton:

Oops.

Jake Sjuts:

You’re all right. And ultimately understanding are we doing that in a system today? Are we doing that in a spreadsheet? And how do we bring that data together is kind of critical when we’re assessing our scope management business processes.

And so really when we’re highlighting what information is critical, these are kind of the steps that would kind of identify like, hey, we have a gap here and what can we do to potentially fix that gap? Is it a technological solution? Is it building out our scope management business processes? What does that look like? But ultimately realizing you have a problem first and then you can work to address that.

And then the last piece here is obviously we talked about those relationships, that one budget item, my budget item and my work breakdown structure could have many activities associated. So understanding if I’m going to be looking at that one budget item and all those activities, I may have to use a min and max schedule activity on the dates to be able to know what’s the earliest it’s going to start and the latest it’s going to finish based on all those activities.

But then that one budget item might have many components. So as we’re planning out the installation of those components, it could be staggered, there could be an installation in one system that’s going to be for the first two months, and then we’re going to take a two-month break and then there’s going to be another two months. So being able to understand at the component level, there could be a gap there from a planning and install perspective, but that’s where that component to schedule activity relationship comes in.

So you got all these data points that have different relationships and you got to really understand how those all connect to be able to get that information you need to be able to report on it accurately.

And then just continuing on that a little bit more. The technology side, and we kind touched on this, are we doing this in the system, or are these relationships available in the system? If they aren’t, somebody’s going to have to manage that externally, but understanding where those relationships live and how they’re going to live. If it is in a system, is that a data available? How am I going to get it? Is the refresh times, is it real time or is it updated nightly? And does that impact what we need to do there?

From a data volume perspective, we talked about the different sizes of data and then ultimately as you’re reevaluating your business processes to get that information that you’re after, will our existing business process work for scope management based on all these factors, or do we got to tweak it and maybe we need to collect some additional informations on a budget cost item or on an activity to be able to get an extra piece of data to be able to report on. So if we do identify a delta in the data we’re collecting, then we need to go train those different business process scope management processes.

So just kind of walking through a breakdown of some things we hit kind of commonly with a number of our potential customers, customers, where they have to really do a reevaluation of what information they want, what data takes to get there, and ultimately what’s the scope management business processes look like to collect that data for all these different roles and making sure that all the relationships are there to get the information they need some.

John Upton:

Yeah, thanks Jake.

And just to reiterate, Michael said to scope to find the money. Not literally, but if you don’t know your scope, if you’re basing something off of 50% design and now you get a hundred percent, well, that scope increase is obviously going to affect your budget. And that’s what I meant by that is, it’s the foundation for driving what your cost or your timing of the project would be. So thank you for running through that example, Jake.

And I guess just in summary, few closing topics before we open it up for questions, but change is tough. Managing scope is tough. Contracts are getting more and more progressive. Work typically is forced to start before designs are even complete, making the processes and integrations even that much more important.

Jake Sjuts:

Also, just a plug there, I mean, the owners require more transparency nowadays, or if you’re in those progressive design builds, the contractor needs more transparency going on… What’s going on in that design phase, right? So the days of we’re just going to design it in this bubble, we’re going to build it over here and then all of a sudden the project’s going to be done or… Those days are kind of gone, everything’s more iterative, and so we’re going to be working on this, it’s going to pass over to the next cog and we’re going to continue to work, and you’re just going to kind of iteratively work through all the scope on the project. So being able to convey and project transparency automatically, systematically is kind of becoming more and more critical as we get going and stuff.

John Upton:

Yeah. And even with some of the companies we work with that have their own engineering firms in-house, it’s still complicated to get that synergy between engineering and procurement and construction without integrated solutions. So it’s even probably exponentially more difficult when your engineering’s outside out of the house and the need is integration and it’s tough.

So all roles, we talked about a lot of roles today, but obviously there are many more roles on a construction project that have their own version of scope. And I think our point today was try to convey that while everybody has their own version of scope, it’s all related and reliant on other role scopes. We try to paint that picture through one of those diagrams.

But lots of people focus on their scope without technically realizing upstream or downstream effects that it may have on one or many roles and their specific scopes across the project. So communication is key.

Lastly, or another point being that the majority of our KPIs rely on scope as a crucial factor in the equation, right? Whether it’s gain losses or cost-first budget factors or indices such as productivity factor, cost performance index, schedule performance index, all of those KPIs rely on accurate scope measurement to generate realistic values.

We try to let our customers, through InEight solutions, be as objective as possible with their claiming and progressing. But if you don’t know your true scope definition saying you’re 50% of X with X being the scope doesn’t give you a lot and it’s not going to provide any KPIs that are worthwhile.

And start with the end in mind. I mean, you probably hear that a lot. We work with a lot of customers and you need to figure out what you need out of the data and then work back into how you’re going to manage it, whether it’s business process or technology to help you through that. But what do you need to drive critical KPIs and at what frequency? Where are the scope handoffs between the different stakeholders and how do scope changes permeate through the entire life cycle of a project?

And then how do you handle change, right? Change is inevitable and that can cause a lot of conflict within a project and cause time delays, over budget. So the communication and the integrated stakeholder conversations on a project are key in managing these scope data processes.

And then are you working in disjointed silos? I’m assuming a lot of people still are. It’s the world we live in. Everybody loves their spreadsheets and it’s hard to get them out of people’s hands, but just establishing business processes, as Jake mentioned earlier, that’s only half the battle, because if your technology can’t support timely integrated updates, then you’ll be making reactive decisions instead of being proactive and you won’t have the data in your hands at the right time to make decisions to move forward. You’re going to be fixing mistakes that have already happened without proactively identifying those through an integrated solution and minimizing them to be more, like I said, proactive.

And lastly, we’ve touched on this numerous times, but integration, integration, integration. Scope evolves and touches numerous stakeholders that rely on timely updates, right? If a drawing changes, that’s going to change my budget, it could change my work package, it’s obviously going to affect my schedule, may affect subcontractors as well. So, integrated systems are needed to optimize that efficiency, reduce the duplicate of data entry that happens more often than it probably should. And enhance the accuracy of the data across the project, giving you more time out in the field like we all want to, do focusing on the work rather than hand jamming updates in the office.

And with that, we will take some questions.

Shoshanna Fraizinger:

John, Jacob, thank you very much. You touched on a lot of areas that I think we’ve all experienced challenges in, and it’s a topic that’s near and dear to my heart because scope, you’re right, there’s the scope in the contract, but how it gets parceled out between the various players on the project and the understanding of that is so critical.

So we do have a couple of questions in the chat as well as in the Q&A, and I know you took the time to answer a couple of them as you were going through, but I’m just going to reiterate, we answered that an iso is an isometric drawing, just to make sure that we’ve got that there. And I believe you did answer the question about the superintendent being in charge of developing the schedule to the level five in order to plan their activities based on the level three.

Was there anything that you wanted to add to that answer now while we’ve got a little bit more time and you’re not working through your material?

John Upton:

I mean, I would say I think there’s a big need for integration, especially talking from a scheduler working the CPM schedule, to your foreman superintendents working on your three-week, four-week look ahead, whatever you want to call it. Because a lot of times those are done in silos.

When I was in the field when we had a big white board with the pinstripes and people would just go make Magic Marker updates and someone would then have to key it in and go update the schedule. I mean, it was brutal.

Now, even in InEight, we have the capability of working on that three-week look ahead in context of the CPM schedule. So you can see that, hey, based on my crew size and the scope that’s remaining, the quantities I have left to install, that’s going to push out this duration an extra week. And I can see, it’ll highlight, “Hey, this exceeds the activity in the CPM schedule.” So the scheduler then knows, hey, we have to ask some questions, we have to make an update, or is there something we can move around to still keep everything on time and on track.

But yeah, scope and schedule, I mean, scope, schedule, costs, obviously it’s a triad, it’s what all of us focus on. And they’re all related, but I still think, in my opinion, scope’s the most important thing.

Shoshanna Fraizinger:

You’re right, all of the rest flow from scope and having tools like yours to give visibility both to the impact on scope, but how each individual’s silo of scope impacts others and what this group needs out of their data set to be able to facilitate and inform what needs to happen elsewhere is so crucial. You’re so right there.

Okay, so we had another question about… I think these are sort of correlated both of them from Michael McQuilliams. So they’re looking for screenshots or snapshots of some of those apps, and actually asking what some of your preferred apps are, because clearly Michael is very familiar with InEight’s products and recognizes you’ve got things to track design progress, assign design teams, et cetera. And so preferred tools for managing all of those comments and corrections that may come in as they’re doing PDF markups, et cetera. Have you got some suggestions there?

John Upton:

You want to take that one, Jake?

Jake Sjuts:

I mean, probably the best thing I could recommend is just hopping out to ineight.com. I mean, we have a ton of all of our products documented there with the integrations. I mean, that’s how I would reference the different screens and snapshots and just seeing what we can do at a high level.

But obviously we don’t have anything today, but if you do want it, maybe just send an email afterwards. We can always reach out with additional apps or screenshots from there.

Shoshanna Fraizinger:

Yeah, perfect. And I know that your contact details will be shared with all the presentation materials when the follow-up happens.

And I just want to remind everybody as we’re kind of going through these questions, I’m going to move out into those that last one in the… Last couple in the chat, actually in the question and answer. They’re all coming in there now.

But before I get to those, I just want to remind everybody there is a QR code on your screen. Please take a moment and answer that survey or open it up and take a moment after we close to do that survey. But please don’t not do that survey.

So let’s go back and sort of take a look at some of these. Look, everybody is engaging here. That’s wonderful. So handling change orders to avoid over budget is obviously, Yasur is asking, the best methodologies there. I think that might be a bit broad to discuss here, but if you’ve got something quick that you might want to take a stab at with an answer?

John Upton:

Yeah, I mean, with an integrated platform, just speaking from our InEight perspective as change orders arise or even as issues arise, being able to have visibility as a cost controller that in the field, snap a picture, there’s an issue and I can start pricing that out even before I know if it’s going to be approved or not from the client, we can still incorporate those dollar amounts, or even the revenue effects into our revenue or cost forecast without it being approved as unapproved revenue or as a pending budget that, hey, we know that this is 75% likely that it’s going to happen, so we can apply that to our unapproved revenue and then still forecast all the costs pending that gets approved or not.

So I mean, it’s like you said, it’s kind of a broad question, but I mean through integrations and having visibility, which is… I think there was another question about different stakeholders and the levels of granularity that each need to focus on. It’s a valid point and absolutely true, but without integrations, you lose some of that visibility. And then there’s another reporting question on there.

Obviously you have to have a robust reporting solution that can bring all of that together because not everybody’s going to be looking at all these different minute details. They’d rather see summarized versions of the project as a whole. And so reporting is kind of the glue that holds all of this together. I don’t know if Jake-

Jake Sjuts:

And just to plug the data there, I mean, as long as you’re capturing everything at a granular level, you can roll it up. So different roles are going to have different requirements from reporting. So if the one stakeholder needs it at level C, but this next stakeholder needs it at level A, you can roll that same data up to level C and level A and it’s just visually depicted a little bit differently. So getting your data right is the first step, and once you have that data right, then you can do whatever you need to with it just to appease all those different stakeholders and the requirements there.

Shoshanna Fraizinger:

Yeah, and Jacob, I think you just reinforced the question that Sandy had in the Q&A, and the key really is the reliability of the data. Once that’s there, as you said, we can into integrate it, we can roll it up, and the key is to make sure that we’ve got visibility for that decision making.

We have a question here about barriers of communication between the essential departments, like engineering and strategies, to make that move and flow smoothly through the project life cycle and working across those various functions. Obviously an engineer is focused on the design solution, the estimator is focused on building those quantities. The planner and scheduler is focused on the schedule. And they don’t maybe necessarily understand each other in terms of what’s required. So beyond just barriers of language, there can be barriers from an understanding of what the product and deliverables look like. How do we handle that?

Jake Sjuts:

And I can take a stab at it first, John, if you’re good with it.

I mean, to me, and that’s kind of where I was going at with those steps and the processes of analyzing ultimately what information we need. If you have management that needs information X, we have to see that data A, B and C make up that information. So if we go and say, “The designers have A, the estimators have B, and the controllers have C,” we then start to build a good story to go to management to say, “If we standardized how this is all done and connect the dots this way, we can give you what you’re after.”

But it’s really being able to understand the information that’s required, the data that makes it up and who actually owns that data is the best way to start to chip away at that. And then once you can lay out that picture for management to say, “Hey, if you do all these things, and we standardize and have good governance around it, you can get this however frequently you want to, you don’t even have to request it.” So it’s like data just kind of grows and builds from there.

Shoshanna Fraizinger:

Yeah. And I think going back to your point about integration. When you have that conversation, the next step in that conversation is understanding when that data can actually be available within the project. Sometimes that is a missing link too, from a communication perspective. The thing that we want just physically can’t be produced yet. And so being able to see that too, I think is part of the conversation.

So let’s see. From Preston, can this process in InEight’s offerings be utilized on a traditional build, design build, to manage project scope, schedule budget for the project with different entities? And they list a couple reporting status during the planning, programming, design and construction. So I think they’re talking about can this do all of the permutations and combinations we see.

Jake Sjuts:

Yeah, and if you want to take-

John Upton:

No, go ahead. Go ahead, Jake.

Jake Sjuts:

Yeah, I mean, I’ve seen a number of different… It comes down to different business processes, right? Obviously because you have those different contract methodologies, you’re going to adjust your business processes. But that’ll just adjust how and when that data is collected in those different processes. But the technology solution itself is scalable to kind of meet all those different contract types. And it just comes down to, again, that data and that information.

So as long as you kind of really build out what does build mean for us, what does design build mean for us? And for all the different roles for those different contract types, you can kind of evolve how the tool’s used, but the tool definitely works.

Shoshanna Fraizinger:

Yeah, absolutely. And I see that there are some very specific software and software integration questions about which types of software can be integrated into the InEight systems and do they generate… Do your systems generate automatic KPIs? And so again, that seems like a fairly broad topic with some very specific answers depending on their situation. Would it be fair to say that for those types of questions, they should contact you guys directly to have those conversations?

Jake Sjuts:

Yeah, I mean, I’ll just plug, we do have kind of a whole library of RESTful web services or APIs available that they can either consume and/or put data in the system for a number of our entities. It’s something that we’re continuously always evolving.

But yeah, I mean obviously from a detailed perspective, I can’t dive into each of them, but we do have an entire library of APIs available for either consumption data out of the system from a reporting perspective. We do have out of the box built-in dashboards to kind of give you some of that KPI information. But again, it’s just going to always kind of depend on the customer and their needs.

Shoshanna Fraizinger:

Yeah. So we’ve got two minutes left, and so I think now’s a good time to wrap up, because I think we have a couple more questions in the chat, but we could probably spend all day having this conversation, and I want to make sure that we respect everybody’s time.

So I want to thank everybody for joining us and thank of course our InEight presenters for today’s webinar, and a reminder that we’ve got the CEUs eligible for this and that the attendees will receive their certificate. I’d like to turn it back over to both you, John and Jacob, if you have any final words for everybody who’s attended today.

John Upton:

Yeah, I would just like to say thank you for the opportunity to present today. We greatly appreciate it. And at InEight, we strive to help teams match outcomes to expectations regarding scope, schedule, and cost. And I know Michael or somebody was asking for screenshots on how we do this at InEight, and we would love to show you that because we do tackle these challenges that we discussed. And feel free to reach out to us or visit our website for additional details, but we’d be glad to follow up on those requests.

Shoshanna Fraizinger:

Amazing, amazing. And so I think with that, thank you all for joining us. Have a wonderful day.