Hey folks, Phil Zito here and welcome back. In this post, we are going to be talking about the glorious experience that is callbacks, scope drift and other project issues. We're going to start this off with just getting level set on what these terms are that I used. Quite often, we will find that the terms that we use in this industry, and I am personally very guilty of this at times, can differ from person to person.
Callbacks: When you have done a job, done a task, and you are called back to fix something related to that job or to that task.
Scope Drift: When you have a scope. A scope is a set of defined responsibilities for the execution of a project or task. So, for example, scope may be to install a controller on an air handler and start up that air handler. Or maybe it's to update graphics.
Slippage/Delays: Slippage is when you have an estimated cost, and you can have positive and negative slippage. Positive slippage is when you estimate a cost, and you execute under that cost. Thus, you get to take all that unbilled cost and transfer it as profit. Negative slippage is where you go over cost, cost overruns, and then you have to obviously take a loss. Then, delays are delays; pretty self-explanatory.
So, how did this topic come about? Well, I was actually talking to one of my connections on LinkedIn, through chat, and he asked me a question. He said, “Hey, Phil, we're getting a lot of callbacks, a lot of issues related to project work, that in my opinion, any rational person would reasonably agree has nothing to do with them.”
Here's the deal. What do you do? This is kind of the unspoken thing. Contractually, you can be like, in this case, they integrated an air handler. They integrated the points through a communication card. How are they responsible for certain things related to it? On the flip side, you can look at it as this customer, this is just phase one of work, and Phase two and three are out for bid. I don't want to piss these people off, so I'm going to really help them out.
Additionally, this has been a long customer of ours, we want to help them out. Maybe the mechanical has a lot more work for us. We don't want to throw them under the bus. There's so many fluid dynamics here when it comes to callbacks, scope drift, and slippage and we're going to try to factor those in. The textbook academic answer is, you do a Release to Operations where you define the scope. Any scope that's unclear, you do an RFI or an RFC to clarify. You adjust your scope, you positively or negatively re-estimate the project, you bring up those details also during the submittal process, pointing out any sequences that will not functionally work. You execute your work, you get sign off on your work that it's functional by doing a functional test, and then anything outside of that should be billable work, short of material failures.
That's the textbook academic answer. The real like, out in the field answer is, it depends on your strategy with that customer. It depends on your strategy with that mechanical, it depends on how much you actually implemented what I just described. You can't really defend yourself if you have no documentation.
Alright, so let's dive into callbacks. Why do callbacks happen? How do you prevent them and how do you protect yourself? Okay, for example, this person is doing a project, and they interfaced an HVAC system into a building automation system via BACnet. Pretty common stuff, right? Actually, we're seeing a lot more of this. It's called application-specific controls.
As the labor shortage increases, as talented folks leave the industry, we're seeing more and more that people are having to do communication cards, they're having to do things like integrating, in lieu of actually putting full blown controls on things. They're doing integrations because it's just easier, faster, cheaper from a labor perspective.
Now the challenge becomes, this guy, he has the system, brought it in, created some graphics for it, and now the system's not working. They're having issues with maintaining space temps within the specified space temps. There are a couple questions that should be going through your head, that should have been handled in the design phase. Are these temperatures even achievable? I will get pushback from controls folks who will say, “Well, that's why we have an engineer of record. That's why we have folks who do capacity design. That's not our responsibility.” And I agree, but if you see a 30,000 square foot auditorium space, and I'm just like throwing a number out there, and it has a two-ton unit cooling it, that's probably not going to work. So, there's a level of reasonability that we as controls professionals should understand and say, “Yeah, that's not going to work.”
I'm brought back to a music studio I did that had fan coils, cooling only fan coils, and the theory was that it would bring outside air, and that outside air would mix when the air was at saturation, and would dehumidify the air. Common dehumidification sequence is you sub-cool the air, bring it below saturation, wring out the moisture out of the air, heat it back up, and air is at a lower relative humidity. Basic psychometrics, except for when you're using outside air in a southern United States climate, which is 90 degrees, 60% relative humidity, you look at a psychrometric chart, there's no way mathematically that can work. Pointing that out early on in the design phase helps you to avoid these callback issues, or at least gives you the leverage to bill for these callback issues.
So, what is a callback issue and how do they occur? Well, they occur when something is wrong, something is not performing, and you're called back to fix it. I see three primary causes of callbacks and I’ll address each one. The first primary cause of callback is poor owner education. We've all been there, it’s the end of the job, we bring donuts and some coffee, and we go through a simple checklist. This is how you log in; this is how you change the setpoint, etc. The owner’s halfway present, we're joking around, we're trying to get through the training as fast as possible.
I know none of you do this, but you know, this has happened in the past. They sign the sheet and then the owner goes on to their next two-hour training session. It's booked for eight hours, you bill out eight hours, you make six hours of profit, but you really only do two hours of training. Now, the thing is, you do this and then the owner doesn't know how to execute or operate their building. Because right after you, they've got A/V training, right after that they've got elevator training, right after that they've got access control training. They don't remember any of it, and you didn't videotape any of it. Now, you get callbacks because they can't change your schedule. They can't change the setpoint data, etc, and you feel bad, and it gets charged warranty.
The next thing that tends to happen with callbacks, is what I mentioned, you have a 30,000 square foot space and you have a two-ton unit. There's no way it can perform. Naturally, it's a controls issue because undersized units are always control issues. I mean, it has nothing to do with the sizing of the equip. (I'm being sarcastic for any of you who have not listened to our podcasts in the past or read our blogs. I get a little sarcastic at times.) But that being said, that undersized unit is naturally a controls issue, thus you get called out to fix it.
The third issue is what the guy who emailed me was kind enough to share with me is, there is some sort of issue with the system, probably was sized correctly, but something's going wrong, and he only has monitoring, and potentially a set point command, capabilities. So, what do you do in these situations? How do you address them?
All right, well first off, obviously, proper training of your people. The more you invest in training your customers, the easier your customer is going to be. For the longest time, there was this fear that if we trained our customers, they wouldn't use us for services much. I think, you know, I don't have statistical numerical data on this, but I just have gut feel having run a service team in the past, having worked with a lot of service companies, the more educated customers are, the higher level issues they tend to find, the more they tend to use service, the more they tend to do retrofit projects, the more they tend to be collaborative with their account executives.
So right off the bat, educate your people, that's a super easy problem to solve. How do you do it? You can do role-based training. So, what is the role of the customer, what are they expecting to do, and then do role-based training. If they're an operator, they want to change set points, maybe acknowledge alarms, navigate graphics, etc. If they're an engineer, maybe they want to replace controllers. So, figure out what level of training and tailor your level of training, and then videotape your training. Give it to them so that they can refer back, try to structure your training into little five-minute segments, and then they can pull that little snippet video. You could do one on how to change to set point, or how to acknowledge alarms. By doing that, you're going to eliminate, in my experience, a large number of owner-based callbacks.
Alright, the next thing is design. Design issues need to be dealt with, ideally during the Release to Operations, but at a minimum, during the Submittal Phase. So, at a Release to Operations, you can easily look at the equipment schedule and the space and pretty easily figure out, if you've been doing this for any amount of time, if something is not going to reasonably work. Then you bring it up via an RFI or an RFC, typically an RFC which is Request for Clarification, and you would clarify, and that then becomes a contractual document with a response. You're going to point out the lack of capacity, or the fact that outside air in a southern state will not enable a dehumidification strategy, it's not a good idea. You can point that out, document it so that when it inevitably becomes a problem, you can point out that response and you can use that to justify you being able to bill for your services.
Now, let's talk about this issue of integration because this is a hairy one, right? This is what a lot of folks run into, which is they have this HVAC chiller, they have this air handler, they've integrated i. The first thing you need to do is you need to understand and be able to communicate what points you actually have visibility to and control of. So, I'm willing to bet that this has an occupied point and a temperature reset point. So, if all you have is an occupied point and a temperature reset point, then you can communicate that this is our ability to control x, y, z.
We can provide a temperature setpoint and we can provide an occupied command. As shown in these trends, both of these are being received and sent to the unit and received by the unit. At that point, your contractual obligation ends and now it becomes a strategic decision. Is there a Phase two Phase three of this project? Is this mechanical potentially holding more work for you? Is this an owner you've done business with for the past 20 years? Is this an owner where it's a single building, and you're never going to do any business with them ever again? These are all things you need to interpret and then you need to make a decision.
My personal recommendation was that you be respectful, but at the same time, you point out that:
“We'd be more than happy to gather this information for you. Realize that this information is outside of the scope of our project. Here's the scope in case you don't remember what the scope is (and I probably wouldn't say it that way). As explained, this is an integrated system, and we only control blah, blah, blah, blah, blah. So, we are willing to (and this is where you'd be nice) provide these trend samples, one time, and/or we're willing to show you how to gather the information from these trend samples one time. After that point, any additional labor will be billed at this rate.”
You communicate that right to them. That is how I would approach this. If it's a simple air handler or chiller, and all you have all those points, there is nothing else you could do. Now, you better know what you're talking about. I've seen people take this approach and they've said, “Oh, well, I've mapped in the chiller and all I can do is enable and send a temperature reset,” but we also happen to control the pumps, the valves, etc, etc. The issue is with us improperly controlling decoupled loop sequence, right? We didn't properly set up how we switch our units on and off based on decoupler flow direction and decoupler status. Now, that is completely your fault if you've gone and not properly programmed that, so you need to be aware if there are ancillary systems that support and supply this primary system. Do not take that stance because you're going to look like a fool.
Let’s shift to scope drift. How many times have you gotten a scope from someone, and you went out to the job only to discover that they didn't read the spec in the related sections that you're providing valves, you're integrating to lighting systems, these controllers that were supposed to be MSTP are now all spec’d to be IP. Scope drift can absolutely decimate your profitability on your projects, especially if you don't positively or negatively re-estimate during sales to ops handoff. If you don't have a sales to ops handoff process, shame, because you absolutely should have that.
So, why does scope drift happen? It happens for a couple of reasons. One, scope drift happens because there is a weak sales scope. The salesperson who wrote it, maybe they're new, maybe they're in a rush, whatever. There's a lot of great salespeople out there, then there's also a couple few who don't go and write good scope letters. So, you got some issues with scope, it often happens in the scope letter and that's because maybe they don't read addendums, maybe they don't read related sections in the spec. These are all things we talk about in our sales training courses, but these are things that often folks, unless they've been through a major sales training program, or have done it a long time, don't understand. So, how do you combat that? You do it through the sales to operations handoff, which we'll come back to in just a second.
Why else do scope issues happen? Maybe you're doing a design-bid-build project, maybe you're doing an integrated project development project, maybe you're doing a P3 Project, Public Private Partnership. These are all collaborative, just in time development-based projects where often scope will drift a little bit. You need to then manage those through RFCs and RFIs and change orders. Oftentimes, people wait to the last minute to issue an RFI or an RFC because they don't do proper takeoffs early on in the job process. How do you deal with late to mid project scope drift issues? You deal with those by using RFIs, RFCs, and change orders, and also understanding your spec.
The final type of scope drift is going to be where you come to the end of a project. The owner has not been involved at all, and they come in wanting to change graphics, or don't like how something works. They weren’t really expecting this. Those are issues. Those are called owner-driven scope drift, and in my opinion, they're the most difficult to combat. It's very easy to deal with a scope letter, especially if you get to the scope letter with the sales team, prior to the scope actually being submitted for bid. That is going to really help you out.
So, the first thing that I highly recommend is that any major project $250,000 or greater, there should be a scope review prior to it being bid. Because $250,000 in controls work is a lot of scope. So that's one way you can combat things.
Let's say you don't do that; you don't review scopes. Next thing up is the sales to operations handoff. So, you do a sales operations handoff, you evaluate the spec, you evaluate the MEP set, you look at the addendums, you look at related sections, and then you do a positive or negative re-estimate and adjust for scope accordingly. Hopefully, you've got an understanding customer and you could do change orders. Usually, that is not the case. So, just be aware of that.
Then as you move through the project as things change, and it's notorious if you've got a commissioning project. Commissioning projects are notorious for change orders. So, you'll have a sequence of operations, and the commissioning agent may write their commissioning test plan, completely different than the sequence of operations.
I remember when magnetic bearing chillers were first coming out, and the sequence of operations was written differently by the commissioning agent then by the actual specifying engineer, and we had to do a change order to reconcile the two. So, that would be a time where you use RFIs, RFCs, and change orders. Those are pretty easy.
Scope changes during the project are pretty easy, as long as they are part of like a new discovery or a new addendum. If there's something you missed, they're very difficult because general clauses usually have you accepting all of the scope, regardless of if you exclude it in your project. Typically, you can exclude like execution time periods unless they're in the general conditions.
Third is owner driven scope changes. These are the most difficult, in my opinion, to address. Now, owner driven scope changes are difficult to address because you can argue that they're part of the scope, but you can also argue that they're not part of the scope. Having to tailor the graphics to look differently for an owner, you could argue that owner acceptance and usually it's noted in the spec; owner acceptance is part of the scope.
But how much owner acceptance is part of the scope? At what point do you draw the line? It's not reasonable to go through and nitpick like, “We're going to provide three graphics changes, this, this, and this.” Like, it's very difficult to do that when you're running hundreds of jobs at the same time.
So, the reality is, this is another one of those, how do you feel about it? Is this a longtime customer? Is the customer never going to buy from you again? Is this part of Phase One of a potential multi-phase project? These are all things you need to be asking yourself and considering as you decide on your response.
Additionally, if you know that a customer is going to be picky, like certain things, I tend to try to address that during the submittal phase, I tend to try to do mock ups of graphics, etc, show them what we’re going to do and give them their one chance to provide feedback, versus putting the cost of developing the graphic, implementing the graphic, and having to adjust it later.
Slippage and delays. So, what is slippage? Slippage is everything we've just discussed, right? You go in, you have projects, you estimate the labor, you estimate the costs of materials, labor, and subcontractors. Those are the three areas that typically slip. You can have time slippage, but most of the time it's just labor, material, and subcontractor.
So how do you deal with these? How do you prevent them? Release to Operations is your best tool for dealing with these issues from day one, right? You want to go and look at past project performance, you should be logging your project data, should be logging your job task codes. Knowing for this vertical, of this size, for this scope, we typically take this long to execute this task. This should be information you should have. You should then use that information to analyze your costs, labor, materials, subcontractor, to then go and see if something needs to be re-estimated.
Additionally, you need to have no scope drift, and you need to have no callbacks, to avoid slippage. Scope drift is going to increase materials, subcontractor, and labor costs, and callbacks will typically impact labor costs. So, avoiding those, you should be able to avoid slippage.
Delays, there's not too terribly much you can do, other than communicate, so that you don't run into what I call accelerated slippage. So, what does that mean? You have an electrical sub, you have a mechanical sub, it's been raining, something's going on. They are not able to pour the slab. The contract person is not able to get the electrical in, they can't get it up and running. It’s going to delay you six weeks. Did the project timeline change? Oh, guess what, no, because this is K-12 or maybe this is an Amazon warehouse. They still expect it to be done at a certain time.
So, what happens? Well, there is probably an acceleration clause in the general conditions, which means that if project delays of no cause of the owner, associated to like environmental conditions, etc, cause the project to be delayed, contractors accept responsibility for any costs occurring based on project acceleration, in order to meet project timeline. So, that's a forefront slippage. Then the backside is what's called liquidated damages which are basically where we're going to execute at certain time, if we don't have certificate of occupancy or scope done at set time, associated to contractors will be handed damages.
How do you deal with these things? Well, it's tough. When you're a $10 million contractor going up to bat against a Walmart, an Amazon, the US government, you're not going to win. And no one wants to say that; no one wants to admit that, but it's the reality. One thing you can do is you can try to avoid the risks.
So how do you avoid the risks? Well, you can implement processes to make things as fast as possible. You can have good project management to identify slippage. I will tell you though, those kinds of slippage issues are the most difficult to deal with. If you have those clauses in the general conditions, you need to understand that and you need to price your labor and/or your margin accordingly.
I do not like to build in excess margin. So, excess profitability, to deal with potential slippage. I like to build in additional labor to deal with potential slippage. I like to try to keep my margin at the same percent, so that I understand what is going on with the projects. Here's the deal, let's say you block in 400 hours, and you increase the margin because of potential slippage. Now, when your operations manager and project manager are looking at their backlog, and this is very important, they're saying we have 400 hours we need for this project. They're not looking at, we have 400 hours, but we also added some margin to give us really 600 hours. So, what you really need to do is put in there, “This is a jail. It's going to take an hour and a half just to get in.” And you know, like jails are 2x labor, in my opinion, because you have to manage getting through turnstiles, carrying your tools, being escorted around, etc. So, you need to 2x that labor.
Now your ops manager can look at that labor forecast and say, “Okay, this is not 400 hours, this is 800 hours,” and can forecast accordingly. Now, if you end up executing it in 600 hours, and you take all that as profit, that's awesome. That's great. But if you don't, you've accounted for that labor, and you're not stealing from other projects. If you just put in excess margin, or you just increase profitability, all that does is that gives you this extra money that you can revenue, but it does not give your ops team a good look at forecasted labor.
All right. So, there we have it slippage, delays, scope drift, callbacks. So, knowledge is power in any of these situations, you don't know what you don't know. I encourage you all, if you haven't done this, to go through our Free Online Skill Assessment. It's completely free. If you take it, you'll know what you know, and you'll know what your teams know or don't know. Obviously, we're going to present our courses as a solution to close those skill gaps. If you want to use this great, if not, we'll shake hands, we'll still be friends, I encourage you to sign up for that.
Next thing I want you to do is please comment below. It helps share this, we give this out free, and I hope you find this as valuable information. All I ask in return is that you share this with your peers so that more folks know about this. It really helps to keep me motivated after doing so many of these to see people reading and engaging. It's just encouraging on my part.
As always, if there's any questions, any thoughts, anything you want us to cover, please just communicate to us. Thanks a ton and take care.
