Hey folks, Phil Zito here and welcome back. In this post, we are going to be talking about scope creep. We're going to talk about how you can manage and eliminate scope creep within your building automation projects, retrofits, service calls, etc. That being said, the goals of today are to identify common scope creep issues and to provide examples of how to solve.
So, what is scope creep? If you've ever been on a project, and you've had all of a sudden, this enormous scope change. Maybe you had a chiller that was going to be BACnet/IP interface card, and next thing you know, you're completely controlling the entire plant with controllers, IO, etc. You're like, “Oh, my gosh, I didn't budget for this! What the heck, how did this happen?” That, my friends is scope creep. It is an increase, or in some cases, a decrease of scope that's brought about by a specific set of circumstances. We're going to talk through what those circumstances are.
Now, the first reason why we tend to see scope creep, and you've heard me talk about this again and again, is the release to operations meeting. That is where our sales team and our ops team meet, they discuss the scope, they review the MEP documents, and they review any addendums. They go through a checklist in which they look for potential scope creep.
The idea of this release to operations meeting is to get clear on the scope and to define what is called a scope statement. Now, scope statement is going to define explicitly, what, when, who, and how. Now I know some of you are cringing when you hear that because you do plan and spec work, you bid the work, and you're often held to the spec, you're often held to the general conditions and the associated sections within the spec.
So, how in the world can you write a scope narrative? How can you establish scope boundaries to create a solid scope statement. You don’t want to write a 500-page book that is your scope. You would never ever be able to play the plan and spec numbers game. You would lose every time.
So, how can you go about dealing with that in specifically a plan and spec environment? In design bid build, in owner direct, yes, you do definitely have scope creep, but you also have the ability to implement some other tools that I'll describe shortly.
Okay, so we are doing this plan and spec job. We have a set of prints that was handed off to us, maybe they're 75, maybe they’re 100% CDs, construction documents. So, we're pretty solid on what's in there is not going to change too much.
This is where basic things we can do to have a clear scope. These are things like reading the mechanical plans and the details. I can't tell you how many times I've had someone working with me get a set of mechanical plans and it says, “an existing chiller,” or it says, “actuators provided by other,” or it says, “VFD provided by so and so.” These things get missed, and it's not such a big deal when it's a one-story office building, but when it's a campus environment, or when it's a hospital wing improvement, etc, there's a variety of material things that can cause scope drift. We want to get a clear scope statement of what systems we’re doing.
I do not advocate for listing out a bill of materials, I've seen these and it's painful to sit in there with some of our customers, especially our distributor customers, and look at some of their folks, some of their customers who come to them, and we're looking at how can we improve their sales training. They bring in literal bill of materials that are 20 pages long, you don't want to do that for a scope statement, but you do want to say, “we're doing these air handlers with full controls. We're doing these air handlers, BACnet interface card only,” etc.
So, how do we do that? We go through our spec, we go through our MEP and our addendums, and then we'll use the RFI/RFC process if we can, as part of the selling process. This is a whole other sales strategy topic but do realize that you can be strategic in the questions you ask and the questions you don't ask. You also have to be aware of if you're asking specific questions during the discovery process, do these get shared with every other bidder? Do they only get shared in a direct response? There's a variety of things, because if you see some glaring miss, that's going to give you a huge price and scope competitive advantage, you may not want to let everyone else know about that glaring mess as well.
Now, if we're not dealing with plan and spec, it becomes a little more interactive. This is where we come up with what's called a scope narrative. A scope narrative essentially tells the story of the scope we're going to be able to do. We can also do these with what are called use cases. So, use cases, as we'll describe a little bit later when we talk about not having customer agreement, use cases talk about who the user is going to be, what they're trying to achieve, and the systems associated with that.
This becomes very important when we talk about systems integration. Not having a clear scope and not defining a scope statement, and like I said, on plan and spec that may simply look like a list of equipment you're controlling, all the way to design build, integrated project delivery, P3 projects, etc. These may be narrative use cases and even further, these may be full blown technology designs.
So, the next issue that comes up that immediately follows not having a clear scope is not having customer agreement. Now oftentimes when we hear customer agreement, we think of owners, but customer agreement is also the contracting tier, since the majority of the work we do in the space is plan and spec work. Having customer agreement on what is in the plan and spec, is critical. Now, like I said, initially you would solve this with a scope statement, you would define that, and you would work that out in your release to operations.
But as you move further into the project, having a customer agreement, as you move through the project, is critical to avoid things like the electrical not being done on time, and thus you being held accountable for an accelerated or actually condensed timeline to execute your controls. We've all been there. Things like the mechanical system not being set up properly, or things like it being assumed that the mechanicals carrying the interface card. These are things where you have to have customer agreement.
Where do you want to gain customer agreement? You don't want to gain it on every single hill, you don't want to die on every single hill. You look at project dependencies, and you look at things that are potentially out of your control. That's where you should have customer agreement.
Are controls and materials out of your control? Well, I mean, in today's market, yes, there's lead time issues and things like that. But you're the one who sources the controls, right? You're the one who sources the IO, you're the one who largely installs it with your electrical sub. So, these things, these items, are going to be under your control.
So, now where do you need to gain customer agreement? You need to gain customer agreement on the areas that are not under your control. These are going to be areas like the electrical, the mechanical, the IT, integration, commissioning, etc. So, anytime something that could potentially be out of your control in a project, you should be involved in that discussion.
For example, commissioning. If there's commissioning on a project, you should be looking at the commissioning test plan. You should be looking at the plan being developed by the commissioning agent to understand and to clarify if their scope is different than the specified scope. Oftentimes it will be. They'll interpret a sequence differently, they'll look at something in an unclear spec, and it'll say, you know, “BAS is to support commissioning.”
Now, your interpretation may be that you're going to run through functional test, or your interpretation may be something as simple as you're going to just answer whatever questions they have. Their interpretation may be that you're going to help them write their test plan, their interpretation may be that you're going to sit alongside them and reprogram to whatever their standards are. Those are two totally different interpretations, and you can already see the scope creep that's happening.
So, by being involved upfront, identifying unclear specs, and this is something that comes with time, identifying things that are vague statements, and vague statements are things like, “will support, will assist, will guide, will be available.” Those are things that do not have the what, when, who and how.
Anytime you see something like, “The building automation contractor will be available to assist the test and balance,” or “will be available to assist the commissioning agent,” that should scare the crap out of you. That should be a glaring red flag where you're asking what does assist mean? When do I assist them? Do I assist them during the submittal design? Do I assist them in designing their test plan? Do I assist them at the end of the project? Do I assist them in owner training? What does this mean?
Because without clarification, and you can clarify that with RFIs, you can clarify what assist means, you can clarify what support means, and you can put boundaries around that. Sometimes, you can even put that in your scope letter, depending on general conditions. But I hope you're starting to see these are the things you should be recognizing and thinking about and considering as you're getting agreement.
Now, if you're dealing directly with an owner, things get a little different. You typically are going to be owner direct, there may or may not be engineered plans. Depending on the type of retrofit or work, you may simply be giving a scope letter that just is time and material or is just some targeted outcome. This is where you really want to develop a narrative and use case map with the customer, especially if it has to do with integration.
Developing a narrative is going to be as simple as, you know, “We have an existing pneumatic system, and we want to take that pneumatic system and replace it with a DDC system.” Now, would that be a good narrative? If you said no, that's good that you said no. But I've seen too many times where a scope letter came across my desk, back when I was an ops manager, from a sales team, and they would say, “We're going to do a pneumatic to DDC retrofit for this building. We've allocated $100,000.” There was no, “We're going to do this air handler, we're going to do this chiller, we're going to replace the terminal.” You have to get specific in the narrative.
Now, if it's integration, we want to get onto customer use case mapping. This is where we're going to map out the integrations, we're going to find out what the customer wants to have happen, and we're going to get agreement on that. We're more importantly going to get encouragement from the integrated vendors as well.
Now, before we move on, I just want to tell you, if all of this feels a little overwhelming, and you don't know what any of these things are, definitely check out our Project Management Course and/or Certificate Program.
So, you've probably run into this if you've done this for any amount of time and it's called the sudden issue problem. It's an issue that suddenly becomes a problem. You're sitting there, you're happy, your submittals get approved the first time, your electrical sub’s executing stuff and you're looking at their work, and it's great. Everything's going all well and good, and then you're told, “Oh, by the way, when are you going to have the central plant up and running?” And you're like, “Central plant? I was working on the air handlers. Central plant is on a totally different building automation system.” And they come back with, “Oh, yeah. Well, you were supposed to integrate with it and pull it into the new building automation system.” Ah, well, that's a problem.
So, this is where you need to be able to be aware of regular status meetings of the projects, you need to be documenting what is being discussed in these meetings. I mean, obviously, you need to be doing a project review at the beginning, but anytime these things come up, like the customer just changed their mind and decided they liked your building automation system so much that they now want to integrate the plant, and everyone knew about this integration, except for the person who's actually supposed to execute this, happens way more often than you think it does.
The problem is, the project manager has 60 projects on their books, they depend on their technician to hop into the job site meeting. Maybe the technician’s new, doesn't really understand what's going on, and so that's why you need to be in touch with the mechanical, with the GC, understand what is going on in the meeting minutes, read those, and start to create a dependency, a deficiency log, and a change log. And these should be on your side.
If there's a deficiency, if a BACnet air handler was provided with a LON card or Modbus card, that's a deficiency. That's something that needs to be brought up. This should be caught during the submittal phase, you should be reading through the mechanical submittals and seeing what they're providing. You should catch that as part of the deficiency log and as part of your dependency log, because you need that BACnet interface card, and then you submit that as a problem up the chain.
This is how you avoid the sudden issue problem. Oftentimes, issues, they don't just blindside us. “IT not being able to give us the network ports,” well you should have talked to IT in the beginning if you knew this was going to be an IP controls job. Oh, you didn't know the IT contact? Well, you should have asked. Things like BACnet cards are notorious for getting the wrong card. While you should have read the mechanical submittal, “Oh, you didn't see the BACnet card in the mechanical submittal even though it's says in the MEP set that the mechanical is providing the BACnet card?” Well, you probably should have clarified that during the submittal phase.
Now, I know it's difficult because all of us have way more work than we have manpower to execute. That's why you need to set up processes and checklists. So, everything I described in here so far has been a process. Release to operations process, scope review process, customer agreement process, your job site status processes. These are all things that you should have very simple processes that the most unskilled person on your team can execute.
It's just a simple checklist:
- Do we have BACnet integrations? Yes or no?
- Okay, then are we providing those integrations? Yes or no?
- Okay, who is providing those integrations? The mechanical?
- Have we seen the mechanical submittal set on their BACnet cards? Yes or no?
- Yes/No. Okay, well, then we probably should check those out.
- Okay, then are we providing those integrations? Yes or no?
Very simple checklist process, very easy to implement.
Alright, let’s move along to change order disagreements. Oftentimes, the joke is that everything's controls fault. You know, you'll see pictures on Facebook or LinkedIn of a disconnected ductwork, and you'll be told that this is controls fault. This is the fault of the controls team. Oftentimes what I see with change orders, the issue I see is that we don't have a defined process for changes and that issue can be really dealt with pretty easily.
Like I said, everything is controls fault until it's not controls fault, right? You'll see the picture of that disconnected ductwork and it's controls fault until it's proven not. Well, if you have a change process, you'll tend to avoid this.
Well, what does the change process look like? A change process looks like this:
- What is the request?
- What is the impact of the request?
- Who owns this request?
- Are we liable for this request? If yes, then you accept the request. If no, why not and the impact.
So, you'll do this change process, you'll run through that information, and then you'll present that information back to whoever your customer is. That customer may be the mechanical, may be the GC, may be the owner, but you have to go and basically run that process.
Before you can run that process, though, you have to define your scope boundaries. Now, this circles back to our scope statement, right? Our scope statement is going to define our scope boundaries, and this is where we need to be specific with what, when, who, and how.
The what is, what are we doing?
The when is, when are we doing it and when is it due?
The who is, who is doing this and who is supporting the doing of this?
The how is, how are we doing it?
An example of how would be, “we're going to upgrade this pneumatic air handler to a DDC air handler.”
The what is, “we're going to upgrade this air handler to a DDC air handler. If we wanted to take that what with a second what we could say, “Okay, what is going to be upgraded?” Then we could say, “The actuators are going to be upgraded with E to Ps. We're going to keep the pneumatic actuators, but we're going to use EDP transducers, we're going to use solenoids for some of our fan commands,” stuff like that. “Then we're going to replace the sensors and the safeties, and we're going to pull that into a centralized BACnet controller.”
The when is, when is this going to happen? This is going to happen over a two-week period when campus is going to be out for spring break, and that's when we're going to shut things down.
The who is, who is going to do it? Okay, that's going to be done by our building automation team. They're going to do the mechanical and the control side of it and they're going to do functional test.
The how is, how are they going to do it? Well, they're going to do it with the E to Ps, with the bill of materials, etc.
Those are your scope boundaries. Now, if a change comes in, and they suddenly want to replace the fan, pull it out, put in a VFD, and now use a VSD so you have to change out the motor and put a pressure sensor in, that is a change order. It's outside of the scope boundaries, so we run through our change order process.
That being said, there will always be a small amount of slippage that you're not going to fight. A customer may come along and they're a great customer of yours, you lay out the graphics and they want some minor tweaks done. You know, you've got phase two, phase three, phase four, this customer they've been with you for 20 years, you're not going to nitpick them, and be like, “It's a change order time! This is what is called risk.
So, I'm a big advocate of tracking metrics and data as you're well aware if you've followed me for some time. So, how do we do that? Well, we track job task codes, we track our vertical market, our material slippage, our subcontractor slippage, and with that information, we have what is called our slippage. Based on our slippage by vertical, we can assign risk. We can have a risk percentage; this can be anywhere from 1% to 5%.
So, a prison would be a higher risk percentage due to project time delays, check ins, maybe the person is not there, maybe you can't take your tools with you, etc. An empty commercial office building would probably be pretty low risk, especially if it's a more modern building. So, we plan for slippage by having risk metrics and risk data so that we can apply risk to our estimates at the beginning of the project.
Ok, to summarize, when it comes to scope creep, scope creep is when you have a project scope, and it increases or decreases outside of the scope boundary. We deal with that by having a scope statement, because oftentimes scope creep comes from not having a clear scope. We also ensure that we have agreement throughout the contract tier and with our direct customers. We make sure that we are avoiding the sudden issue problem by having proper communication and documented communication. Remember, email is legal communication. So, if you get an email from someone saying that you are liable for this or not liable for that, that is a legally supported document, in most states. I'm not a lawyer, so talk to your lawyer to verify that. And then finally change order disagreements, we avoid those by enforcing our scope boundaries, having change processes and planning for small amounts of slippage.
Thanks so much, folks and take care.
