<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=2854636358152850&amp;ev=PageView&amp;noscript=1">

Hey folks, Phil Zito here and welcome back. In this post, we are going to be talking about how to review, scope, and estimate retrofit projects. Now some of this may seem similar to how to review, scope, and estimate construction projects, but trust me, there's a lot of nuances here that really will make the difference between whether you end up basically tanking a job or not winning a bid, or just having a disaster.

Alright, imagine this. You are sitting here in 2008 and the economy's tanking all around you. Construction projects are being put on hold, companies are losing funding, and you are a father of two sitting there looking at all this happening, thinking, “I work in service, what the heck am I going to do?” People are canceling their service contracts. Life is not good. Well, that's when we look at retrofit.

Now you may be thinking, “Wait! You just said people are canceling projects and are no longer doing service contracts.” Yes, but one thing I've learned, having been in the space for a long time, is that when construction is down, retrofits tend to be up. What happens is, companies that have money, or maybe municipalities that have funds, they tend to make investments in their assets during this time. Basically, they want to make sure that they still have work. At least, that's what it seems like to me. I can’t be certain, but the reality is that it does happen. I've seen it happen time and time again, during a couple recessions now.

Now, when you approach retrofit work, this is a little bit different, because quite often, the first thing that changes is the contractual structure of a retrofit project. Now, there are major retrofit projects that are run by general contractors and mechanicals. They have architects and engineers, but I will say that the majority of the retrofit opportunities that you run into in the building automation space are actually owner direct retrofit market opportunities.

So, when we're looking at owner direct opportunities, we really have to get dialed in on several things. The first thing is, we have to truly understand the outcome. Why is this retrofit happening?

As I look at retrofits, they tend to happen for four different reasons:

  1. The company or the business, they have an extremely aged infrastructure of HVAC and controls that needs to be updated.
  2. There is an energy or sustainability, sometimes tied to energy conservation measures, sometimes tied to facility improvement measures, that are going on, and these energy goals need to be met.
  3. There is an aging or an inexperienced staff and they need to bring that staff to a more modern control system. This is so they can actually maintain that control system.
  4. A controls contractor has basically been taking advantage of the customer, charging them way too much for labor and for material. You really can't get away with that anymore, because a simple Google search can inform you of GSA book pricing for most OEMs, and you can get a pretty good idea knowing that most GSA pricing is usually list plus 20. So, you can start to get a pretty good idea of what actual material costs and labor costs are and know if it’s unfair pricing.

So, understanding the “why” is going to be pretty critical because when you understand the “why”, then you're going to understand what you need to do from a retrofit.

Now, before I do any retrofit, the first thing I do, besides understanding the outcome, is to evaluate the current state, especially with owner direct work. It can be quite dangerous if it's a legacy unmaintained system, and you don't evaluate the current state. I know this takes time and I know time is cost. So, because the reality is, the person who is most likely going to evaluate the current state is going to be one of your service technicians, and that's going to be a sunk cost. Now, in an ideal world, you would follow a service contract with a retrofit opportunity, so you would already know the current state. But, if you take my strategy of a sales circle, you draw a circle around a Metroplex and you target customers who are outside of the typical range of OEMs, as establishing a beachhead of customers, then you are typically going to be calling, potentially, on customers that you aren't currently servicing, and thus you don't know the current state.

So, how do we evaluate current state? Well, there are a couple easy ways to do this. One, we can go into the control system, and we can run an offline report. So, we can figure out what's online and what's offline. Then we can run an exception report, what is within normal parameters?

Now fortunately, with most modern systems, there's an analytic solution. Whether it's SkySpark, whether it's an OEM provided analytic solution that enables you to scan the system and do kind of a discrepancy report, and based on that discrepancy report, you know, kind of, what the current state is. Then you have to actually go and evaluate the equipment as well. Take a look as to what is going on with the equipment, understand what is going on with the equipment, making sure that it is maintained, operational, not in bad disrepair, etc.

Now, a way to offset the cost of sales. So, cost of sales is when you have a sunk cost, very similar to opportunity cost, associated with going after a sales pursuit. This is why integration sales are so costly. There’s a high cost of sales of integration or energy saving company like ESCO work, MSI Work, that has high cost of sales, due to the high level of expertise required to execute that kind of work. That's why it not only has long sales cycles, but it also has high cost of sales.

Not retrofit doesn't necessarily have to have as high a cost of sales as those, it usually has a higher cost of sales than construction, but it also has typically, higher margins to offset that. One way to mitigate the cost of sales is to work on creating a project development agreement or an audit agreement, where as part of this engagement, you're actually performing a retro analysis of the building. So, you're essentially saying, “These systems work, these systems don't, these are the systems you have, this is the state they're in, this is their performance, and these are our recommendations.”

What you'll do with a development agreement is, you'll present these results and tell them, “If you choose to use us, we could roll the cost of this into the proposal, or even deduct the cost of this from the proposal and count it as engineering effort.” It just depends how you do that. Then, you could say, “If you choose not to use us, then you're going to pay XYZ dollars, and that is going to be basically covering your cost of sales.” So, that is a good strategy for evaluating current state of the building.

Okay, so we've listed out our outcome, we understand our outcome, we understand our current state. Now we need to decide on the level of retrofit. So, we haven't gotten to scoping or estimating yet. We are still reviewing and we're slightly on the edge of scoping now. So, now we need to decide a level of retrofit, and there's really three primary levels of retrofit.

You have the rip and replace, which is basically where we take the control system out and we replace it or a dual integration level. So, when I say dual integration level, there is a lower-level integration, which is field level and we're talking field controllers and IO devices. Then there is a higher-level integration that is typically supervisory device level and server level.

So, a field level integration is where you have controllers, that maybe it doesn't make sense to replace, they're great, they're integratable, either through a proprietary interface, through a gateway, or some way we can pull these field level controllers in. Now, when we're pulling them in, we are actually replacing the supervisory device in servers. So, we are adding our own supervisory devices and we are adding our own servers, if necessary. We're keeping the field controllers and we are keeping the IO devices.

Typically, what this will do is, as those field controllers die, we will then run a separate trunk, a secondary trunk, and we will pick up by replacing them with new field controllers. So, we see this integration quite often when there are a lot of field controllers, and it doesn't really make sense for us to replace all those.

We want that cost avoidance, and really what the customer’s looking for, key things they may say is, “We want to implement analytics, we want to implement mobile user interfaces. we want a reliable front end, we want better graphics.” Those are kind of key phrases, and in that case, despite what most people say, you can run analytics on most field level controllers. If you have the right point data, you just have to understand proper throttling, and understand things like baud rates.

Now, a thing to be aware of with this is that you are potentially going to lose the capability to modify field controller programs. Typically, what's going to happen is these field controllers are still going to require the manufacturer’s programming software to modify them. Additionally, and this is notorious, I remember I did a Native American hospital system, and it was a LON system, and it was Honeywell XL series controllers, and I pulled off the Tridium JACE. I was going to put in a Johnson Controls NAE with a LON trunk. I was new to LON at the time, so I figured it was just like BACnet. In actuality, there's all this stuff I didn't know at the time, and what happened is, those LNS databases had bindings between controllers. These were software bindings, and as soon as I pulled that supervisory device off, put my new one on, and put a new LNS database in there, I could program the field controllers with a LON plugin. But I did not have the LON files and the programmable software that was needed for the freely programmable controllers. So, I found myself in a world of hurt having to overnight some LON controllers, and costs were a little higher. Granted, we had priced it at high margins, so we still make profit on the project, but not as much as we could have made. So those are some of the dangers, as I mentioned, of field level integration.

Now, supervisory level integration is where you keep the same supervisory device, you keep the same graphics, and you actually replace your field controllers. Now this is a less common form of integration, but it is one that I see happen, where folks will have XYZ system that runs the campus, and they are wanting to rip out the controllers in a building, but they want to keep the supervisory devices, the servers, the graphics, and everything associated with it. So, in that case, the supervisory level integration, we're actually going to be simply just replacing field controllers and potentially field buses.

Once again, we need to be aware of any global logic things, we need to be cognizant of all of this as we approach this, so those are some of the risks with supervisory level integration.

Now, rip and replace is pretty straightforward, you just rip the stuff out, and you replace it. The question often becomes, “What can be leveraged?” I did Chicago Public Schools a long time ago, they had a Barber Colman system. Barber Colman used some unique inputs, and so I went there, I ripped it out, I was going to put in some Allerton VLCs, and the problem I discovered was the inputs could not be used. They were some specialized inputs, so I couldn't use them, and I hadn't accounted for that. Now I know, if I'm going to rip out a legacy system, I'm going to pull the product spec sheet on the primary inputs.

My rule of thumb tends to be if there's more than 10 of the same type of an input, or an input cost of like more than 200 bucks, I'm going to research it. Once I research it, I'm going to be looking for key things like, is this a common input like a four to 20 milliamp, or is this some sort of communication bus or some sort of pulse signal that I need to account for? That way, I can properly interface with these inputs. These are things I need to be cognizant of.

So, as I'm looking at this retrofit project, and I understand the outcome, evaluated the current state, decided on the level of retrofit, and figured out my strategy, once I've done that, it all pretty much falls back into the scope and estimate process. Now scoping, it's going to be quite simple. Once you understand the outcome, you understand the current state, and you understand the level of retrofit, you are going to do a couple things.

One, you're going to have something that while included in construction scope letters, is not typically filled with information. In a retrofit scope letter, you're going to want to pay specific attention to the Assumptions and the Exclusions section of your retrofit scope letter. So, if you come upon a chiller, and it's not functioning, or you come upon an air handler with a giant hole in it, you might want to point that out. So, those are things that are going to go into both Exclusions and Assumptions.

Assumptions are going to be things that you assume to be true, and realize, assumptions, hold less weight, if you are to get into a contract dispute. I'm not a lawyer, talk to a contractor or contract lawyer for further clarification. But in my experience, assumptions are like you're saying, “I assume this as a BACnet network. I assume that this sensor’s functional.” Assumptions are typically going to be things you're going to have to eat if it comes out to be that you're wrong.

Exclusions, however, and this is where things get a little wonky, if you're under a GC or mechanical, you are held liable to the general conditions of the contract. Even though you may exclude scope, it may be in the general T's and C's, and the general specifications that you can't exclude scopes. So, your scope exclusions may actually hold in the water. When you're typically owner direct, though scope exclusions hold more weights. So being able to hold a scope exclusion and say, “I'm excluding this because it is an older system, and it doesn't work,” that typically can be enforced in an owner direct scenario.

So, understanding those kinds of things will help you build out a solid scope letter. Additionally, in scope letters, as well as estimates, you want to understand what you're doing from an engineered services perspective. This is where things can get a little dangerous. I'll be completely honest with you; I've been on the risky side in this. I've gone and created a new scope for a retrofit project that did not have any sequence of operations for several schools and several buildings.

I've been like, “Yeah, I understand how this stuff is going to work. I'm going to find like control spec builder something or maybe grab some ASHRAE Standard sequences, and I'm going to pull them in there. And we're going to put together a basic submittal set.” No, I'm not a professional engineer. If something had happened in that case, probably could have been liable. I don't really even know the legal liabilities of that.

Now, it's really something you shouldn't do to be completely honest. But at the same time, I mean, if you've been in this field for a little bit, I'm sure you're nodding your head that yeah, you’ve done this, too. So, the reality is, can you get away with it with a commercial office building, where you're like, “Hey, it's a packaged rooftop with a couple VAV boxes and an air-cooled chiller, and it's kind of hard to mess that sequence up?” Yeah, you can get away with it. But if it's anything more complicated than that, it may behoove you to contract a professional engineer, if you don't have one in house, and work that into your scope. So, you know, professional engineering is excluded. It is at the owner’s expense, or you can carry it in your scope letter.

Another retrofit gotcha is test and balance and commissioning, which we're going to separate out. So, test and balance is where you test the system, and you balance the system. So, if you've ever filled a cup with water, you keep filling it, the water overflows, right? Well, let's say you had a couple of valves in that cup, and you could open them up to let the flow of water out. Well, that's basically test and balance, right?

You have a finite amount of water or air circulating through the building to achieve the appropriate heat absorption or heat transfer. Then you basically have someone who's a professional balance that out, starting typically on the airside at the diffusers in the ceiling, working all the way back to the air handlers in their static pressure. The same thing with the central utility plant, starting at the valves, and then working their way back to the pumps, and the chillers, and the boilers, etc.

So, including your test and balance or excluding test and balance is another thing we need to be cognizant of in a retrofit scenario. So, as I was saying, test and balance is something you may need to exclude, or you may need to include. I'll tell you, I've done test and balance and I'm not a certified TAB person but grabbed a testing hood, a calibration hood, balanced diffusers, balanced VAV boxes, balanced air handlers. Not to disparage test and balance at all, but at least the air side is not too terribly difficult, until you get into outdoor air flow, balancing, stuff like that. Definitely water hydronic balancing can be difficult. It's very math heavy.

That being said, it's something you have to make a decision of, “Do we want to do it in house or do we not?” An additional thing is commissioning understanding. Is this part of a lead retrofit? Is this part of a validated environment, etc, where commissioning is required? What do commissioning resources look like? What do you need? Is this just functional test or is this a fully validated commissioning experience with a commissioning test plan? These are things you need to address in your scope, especially if you're owner direct.

Additionally, any permitting, any inspections anything of that nature that may have typically been handled by a GC, or by mechanical, you need to account for that as well as equipment startup, equipment shut down, and finally, you need to account for potential off hours work. These are the little nuances that can bite you if you've been doing primarily construction work from a scoping perspective, and you haven't done it in a retrofit environment, especially an owner direct environment.

Additionally, the big one I am really careful with in retrofit opportunities, especially owner direct, is that you really start to appreciate the contracting tier when you're in an owner direct environment and you have a dispute over certificate of occupancy, or what is deemed an operational system. So, you really want to get clear on what is deemed an operational system, what is going to take you from that POC 90% to POC 100%, so that you can get your retainer, you can get through the warranty period, and get off the job.

Sometimes, this is in the scope letter, sometimes this is an addendum where you're going to clarify out and say, “This is how we are going to validate the system. This is how we are going to ensure, and this is your responsibility, Mr. or Mrs. Owner, on validating that this does indeed meet the design intent.” So, that could be an addendum that could be in the scope letter, etc. From an estimating perspective, it's all pretty much the same. Realize that there may be additional cost in engineering in a retrofit scenario. Realize that you may have to put a little bit of a risk percentage on material, especially if it's very legacy. I like to say that for every five years, the system is, old, I will add a 1/2 to 1% risk. So, if you had a 30-year system, you would potentially have 3 to 6% risk, because just possibility of, “Hey, I'm working with the sensor, it worked fine. But as soon as I unplugged it, I can't get it to turn back on.” Or, you know, “This actuator just crumbled in my hands as soon as I touched it.” Those kinds of things happen the older the systems get. So, rule of thumb, for me has always been 1/2 a percent to 1% for every five years of age of the system.

The last thing I will leave you with here is, don't forget to piggyback service solutions. On top of this, you already have an owner direct relationship, you're already in a retrofit scenario. This could be a situation in which you could include a training service. This could be a situation in which you could include an analytic service, you can include a continuous commissioning service, there's a variety of add-ons. You want to increase that share of wallet as much as possible, while providing a valuable service to your customers.

So, I know this one was a little bit longer than normal. I hope this helps out. This gives you some strategies and some insights to performing retrofits, sales, scoping, estimating, and reviewing. If you have any questions, please ask. I love doing this. It's really a passion of mine to be able to serve all of you, to be able to help all of you in your learning journey.

Thank you so much for being here and you all take care!

Phil Zito

Written by Phil Zito

Want to be a guest on the Podcast?