Hey folks, Phil Zito here and welcome back! In this post, we're going to be continuing our series on sales and estimating. Today, we're going to be looking at the four-point method for bidding retrofit work.
Let's get started on the four-step process to estimating retrofit work. So, in our last post, we covered how to go about figuring out all the risks associated with estimating retrofit work. Now we're going to cover a couple of examples of retrofit work. We're going to talk about a rip and replace scenario, a top-down scenario, and then a bottom-up scenario.
So, top-down scenario is where we are taking an approach where we are retrofitting the server layer and the supervisory layer and leaving the field layer intact. Bottom up is where we're going to be retrofitting the field layer, but leaving the supervisory layer and the server layer intact.
Okay, so let's take a look. You go to an office building, and this office building is part of a group of office buildings that a property management firm owns. They really want to consolidate on a single front end and a single building automation system. So, what we're looking at here is a top-down approach. In this building, we're going to have, let's just say, a rooftop unit. We're going to have a VAV box being served by this rooftop unit, but you actually have a multitude of vav boxes being served by this rooftop unit.
So, we have this rooftop unit, and it has a controller in it. We have a VAV box with a controller in it. This building is actually a slew of buildings that this property management is overseeing. Let's say that there is building one, two, and three.
Building One has system type A, Building Two has system type B, and Building Three has system type C. We're focused solely on Building One with system type A. Now, you could be Tridium, Johnson, whoever you are, you're repping that product.
So, from an estimating perspective, we're going to follow our four steps:
- Step 1: We're going to clearly identify the outcome, and that outcome is going to drive our strategic approach.
- Step 2: We’re going to define our approach.
- Step 3: We're going to identify our risks.
- Step 4: We're going to estimate.
Now, you may be asking yourself how this is an estimating process when we’re only talking about estimating in bullet point four. Well, what I see quite often is that these three bullets, outcome, approach, and risks, are actually going to develop scope. The clearer and more concise, or accurate, that your scope is, is going to lead to an easier estimate.
So, as we discussed in the previous post, we really want to get clear on our outcome. Our outcome is to have a top-down integration, where we are putting a server in place at some undisclosed location, and that server is going to serve up user interfaces for these individual buildings. In which case, we have a Building One, Two and Three, with three different control systems A, B, and C. So, we know our outcome is a single user interface.
Now, as I said, we're only doing one building right now. So, our server could be sized appropriately. But at the same time, we want to understand, if this is going to spread to all the other buildings that this property management firm covers, then we want to size our server appropriately, as well.
So, what is our approach? We've defined that our approach is a top-down approach. We are going to implement a server and we are going to retrofit supervisory devices in these buildings, and in our case, in Building One.
What are our risks? Well, our risks are that the control system in the rooftop unit in the VAV box may not speak a protocol that works with our supervisory device. Additionally, our risks may be that the rooftop unit and VAV controls are antiquated, or damaged, etc, there may be interlocks. Maybe there is a campus central utility plant that feeds these three buildings and these rooftop units feed back to that. Maybe we have hydronic rooftop units instead of DX rooftop units. These are all things that we need to figure out.
Once we’ve figured that out, though, it becomes pretty clear. Let's say for simplicity’s sake, because this is our first example, let's say that our rooftop unit, quite simply is speaking BACnet/MSTP, as well as our VAV boxes. So, what we need to do is just put a supervisory device in that building, most likely in a data closet, that will then interact with the rooftop unit and VAV boxes. So, we need to account for that.
Now, we also have to check out, like I mentioned, the controls supervisory logic that may exist. Maybe there's trim and response, so the VAV boxes are feeding back calls for cooling, calls for heating, to the rooftop unit, and we're seeing that kind of sequence be implemented. These are all risks we're trying to identify.
Once we've identified these risks, though, we can create a scope. Now, the scope I’m writing here is so dirty. It would be much clearer, and better English, and would look a lot more professional, if I was doing that on a job.
So, simply, it would be,
- Provide one server that can cover X amount of buildings.
- Develop graphics for X buildings
- T&B, CX, functional tests, training
In the previous post, we talked about test and balance, functional test, commissioning, etc. So those things T&B, CX, functional tests, training, all of those would be included, if needed. That is just kind of our server level scope, as well as our execution overall.
We can kind of bucket scopes into three things. We can bucket into our kind of top level, our labor and overseeing the project, and then our material and system specifics. So, system specifics would be:
- Install supervisory device and Map AHU, quantity (1), and VAV quantity (10)
- Perform validation
Like I said, this is a pretty dirty scope right here, but it gives us enough to be able to say, “Okay, we have a scope. Now we can take this scope, and we can feed it into an estimate.”
As I've discussed in many, many, many posts, there's the rule of thirds. 1/3 is going to be electrical, 1/3 is going to be material, and 1/3 is going to be labor. So, we're going to take our electrical, our material, and our labor, and we're going to start breaking these things out.
So, for our electrical, we're going to say, “We have to install a panel with the supervisory device. We potentially have to run some MSTP, so, 22/3. If we can't use the existing, we're probably going to have to do a 120 drop to the supervisory panel.” So, we can start to build that out into our electrical estimate.
We can also use our electrical estimate to feed our material estimate. With our materials, we may need a supervisory panel, we may need like a 16x20, NEMA 1, especially if it's going in an air-conditioned space.
As far as labor, we're going to need to create graphics, we're going to, potentially, need to perform test and balance, functional tests, etc.
So, we're going to see an interesting shift here in retrofit work in that, in a lot of retrofit work that is top-down approach, meaning replacing supervisory device and server, our materials are going to be quite low, and our labor is going to be high. So, our materials can tend to go down, and our labor will tend to go up. If it's a bottom-up approach, where we're replacing controllers, potentially replacing IO, that's where we're going to actually see our material go up and our labor go down.
So, we start to build out this material list and then we start to build out our labor tasks. If you've followed us for any amount of time, you know that I am a fan of labor tasks. So, we would want to break out like install, design, graphics, programming, and project management. We would want to break out these labor codes, and then we would want to assign labor based on these codes. Each code is going to have an associated dollar amount with it.
Now, let's talk about a bottom-up scenario. So, I'm going to take outcome, approach, risks, and estimates. Bottom-up approach is where we are actually looking at replacing the field controllers, and potentially the IO.
So, from this approach, we are going to identify the outcome. Maybe the customer likes the control system they have, they like the graphics, or maybe they just installed a new control system. What they're trying to accomplish here is, “We have this new control system, we have graphics, but we really want to replace our aging field controllers, and we want to replace our aging IO.”
So, what approach do we need here? We need a bottom-up approach. What kind of risks do we have? Whereas the top-down approach, in my opinion, is less risky, from a “stuff doesn't work perspective,” it's more risky from a “customer's not happy with the graphics, customer doesn't like how this looks perspective.” So, there's a lot more customer input.
Whereas with a bottom-down approach, there's much less customer input from a risk perspective, but there's a “we don't have sequence documentation, we don't have the proper material, our IO doesn't work, this equipment doesn't work” situation. Those are the types of risks you're going to run into.
So, we want to get very heavy on validation of operation. That's going to become very important. How do we do this? As I mentioned in the previous post, we do this through a couple things: through site walks, grabbing the O&M manuals, doing a system validation, looking at maintenance reports, etc.
But we want to build out a clear equipment schedule. We want to understand exactly what we have, how it's controlled, and then we want to understand the IO, what can be reused what can't.
So, let's talk about for example, maybe a school. This school is going to have a boiler, a chiller, maybe RTUs, maybe a unit ventilator, and let's say potentially some VAV boxes being fed off of this. So, a lot of different systems.
So first off, we need to build this equipment schedule. We need to get an accurate list of the systems, and that equipment schedule is going to translate into our scope. It's going to talk about what's in scope and what's not in scope.
Next, we're really going to want to figure out how its controlled. Are there already sequences of operations that we can utilize? If so, we're going to look at how it's controlled. We're going to take that SOP and we're going to basically just copy the SOP. If not, then we need to make a decision with this: Are we going to bring in a professional engineer to engineer these or are we going to take the risk of doing them ourselves? I don't recommend taking the risk of doing it yourself. I recommend contracting with a PE and getting sequences written.
Additionally, we have to consider how are we going to validate these sequences. So, validation and test and balance are going to be really important. Now in an ideal world, we would grab the test and balance, like the min and max CFMs and all of these things, out of the VAV box controllers, out of the air handler. Central plant controllers, sometimes you can't access the programming in those controllers, sometimes you can't actually get any viable information that you need, so, you may have to rebalance. Other times, even if you can get the information, how the other manufacturer is calling their balancing set points may be different than what your system is, and you may not be able to use those set points. So just be cognizant of that.
Okay, so we have scope, we have SOP, we have our professional engineer potential, we have validation, test and balance, functional tests, and now we need to understand what IO can be used and reused. As, I discussed in previous post, we want to look at, potentially, what the IO types are and then based on those IO types, we want to understand that we have these types of sensors. Are they common 1k nickel, or are they some proprietary sensor that we can't use?
Once we understand that, we can then build out our IO list. Now, we're not going to typically call out our IO list in our scope letter. We will typically just call out the material, we’ll call out any tasks like validation, test and balance, professional engineering, training, etc. Once we have all of this drafted out, we can actually start to build out an Excel sheet with a matrix.
This is something we use in our courses. We have an Excel matrix that basically becomes the BOM, and this Excel matrix, with a bill of materials, actually feeds into a scope matrix. So, you have a scope matrix that breaks down each system into a bill of materials, and this bill of materials is unique in that it has the material list, the product number/serial number/SKU, the quantity, and then we actually break out our labor and our sub, as well. This becomes our estimating sheet, and we build this out accordingly.
The nice thing about this is if you do it long enough, and you start to keep track, like for commercial real estate, or K-12, or health care, you can actually come up with some pretty effective swags, a swag being a rough estimate. You can come out with some rough estimates pretty quickly by having a database of pre-built scope matrixes and excel matrixes for Bill of Materials. If you have five rooftops, you’d take your typical and then you just tweak, and that makes your estimating so much faster. If you're doing this from scratch each time, you're wasting a ton of time. You should have these databases built out and use them accordingly.
Okay, so that was a bottom-up approach at a very high level. Once again, using the four-step process of really clearly identifying our outcomes, approach, and risks to build out our scope, which then feeds into our estimates.
Now, rip and replace is just a combination of the two, top-down and bottom-up. I'm not going to dive too deeply into that. So okay, we covered a lot of things here, and what I really want you to take from this and be clear on is:
- It is incredibly important that you lay out your outcome, and you get crystal clear on your outcome. You need to know that because otherwise, you will never be done with the project. As I discussed in a previous post, being very clear with the outcome with the customer, as “this is the outcome, this is what we agreed on, this is what's going to be accomplished,” we want to make sure that all of that is very clear. If you don't have outcome defined, then you will not reach your outcome.
- The approach. We want to make sure we're very clear on our approach, and that is top-down, bottom-up, or rip and replace. I've described when we would use those three.
- We want to get very clear on our risks. We want to identify the risks, and I've talked through the three different types of risks, all of that should package into a scope.
- When the scope comes, then we are able to do our estimate. When we are estimating, this all comes together.
Now I know this is called the “Four-point method for bidding retrofit work.” So, you might be wondering, “How do we bid retrofit work? You've described how to estimate and how to scope.” I probably should have been clearer in retrospect, but hopefully, you have made the logical connection that if you have a scope and an estimate, you can then bid retrofit work. So, you have to have a completed scope letter, and you have to have a completed accurate estimate for the cost associated with that scope letter, for you to be able to bid retrofit work. So, probably should have been more clear in that logical connection, but, hey, I do several of these on a weekly basis and things start to potentially get missed sometimes.
That being said, as we're talking about, the three steps up into the estimate, I really want to hammer home this point of building a library. For a lot of folks, doing retrofit work, especially estimates and scopes to retrofit works can be very, very difficult. People tend to struggle a lot with it. What I want you to take out of this is that, it doesn't have to be difficult, you don't have to spend a crazy amount of time, you simply need to make sure that you are building a library every time you do these, You should already be doing this with programming, you should be doing this with graphics, you should always be looking at how you can repeat and reuse. So, if you take that approach of repeat and reuse, you'll find yourself building out a retrofit library pretty quickly.
So, I hope this helps. I hope it gives you further clarity to what we covered in the previous post as well as some more tactical examples. As always, I encourage you to ask any questions you may have. I love to answer your questions. I'd love to help you better understand this.
Thanks a ton and take care.
