Hey folks, Phil Zito here and welcome back. In this post, we are going to be covering what a building automation standard is and why you should be using one in your contracting or system integrator business.
So, for those of you who are like, BAS standards, they're the things owners use to find point names, and graphics, and sequences. Well, yes, those are BAS standards for owners. We're going to cover standards for contractors. We're going to talk about why this matters, what a control standard is for a contractor/system integrator business. We're going to cover the difference between a standard process and procedure and why you should use these, and we're going to talk about how you identify your standards.
So, what does this even matter to you? I was talking with our sales team this morning on our weekly sales meeting, and we're talking about how when they are calling customers, every customer is saying that they've got backlog, tons of backlog, tons of stuff to do. We're thinking to ourselves, why do people keep choosing to use our training when they are swamped? Why is it that they feel that it's a good enough investment to make, even though they're incredibly busy?
Then, we started to dive into our most popular courses, and we realized that this summer, the courses that sold the most were the ones that were related to processes: our installation course, our programming course, our design course, our sales course; they're all process driven. While we still sold our theory courses, they didn't sell nearly as much as our process courses, and that was really interesting to me.
As we started to look into the analytics around that, we started to discuss why. What we came to the conclusion of is, everyone is super gung-ho about processes. They think processes are great, but they only start to actually implement processes when crap hits the proverbial fan, right? When they start to not have enough people to execute a project, when they are having a tech working 60 hours a week, they're running from site to site to site, that's when they start to implement processes. And that's like the worst time to implement processes.
It's kind of like you get diagnosed with high blood pressure and that's when you start taking action on it. So, that's what we saw in a lot of our customers, that they were starting to be overwhelmed and they had to find a way to improve things. So, they started implementing processes. How did they implement processes? The quickest way was to just take our programs and copy our processes.
But why does this matter to you? How can you come up with your own processes? That's what we're going to cover today. So, creating a standard is the first step to having processes. By implementing a standard, you're going to do what Michael Gerber and E Myth Revisited says. You're going to take the lowest skilled person and be able to have them do the highest cost tasks that they can do. So, whereas in the past, without a standard on installation, you may have to train each individual person and maybe only trust them with pulling some wire, or installing some thermostats, things like that. But with a process now, you may trust them with MSTP trunks, you may trust them with controller discovery, you may trust them with graphics setup, because there's a process in place.
Now what does that do? That takes that $20 to $30 an hour tech, and you have them doing things that a $30 to $50, more experienced tech programmer, etc, may be doing. So, you're taking those higher skill tasks and you're shifting them down to a lower cost, lower skilled labor set. Naturally, that lower skilled labor set is more plentiful than the higher skilled labor set. This isn't to demean people; it's just simply a matter of fact. So, that's one of the things, being able to execute work with more available talent.
The second thing is to reduce callbacks, reduce rework, eliminate labor related slippage, and ultimately reduce sub and material related slippage. Third, it’s going to give you a repeatable product that you're delivering to your customers. I know we think the product is the materials we deliver the controllers, the user interface. The product, actually, is the deliverable.
So, anyone can buy a controls product and install a controls product. It's how it’s installed, the graphics, the programming, the submittal set, the as builts, the O&Ms, the owner training. How all of that is delivered, that is your product, at the end of the day, what's going to differentiate you between that other person who's maybe 10 cents less per point, or 50 cents less per square foot.
So, what is this controls standard? This is an engineering standard.
I’m going to take you through this standard, step-by-step.
So, a standard is any approach that's going to include processes, procedures, and supporting documentation for something you do all the time. So right here we did a standard engineering standard. It consists of three areas: submittals, programming, and graphics.
So, when customers come to us from a consultancy perspective, and they ask us to help standardize their business and their processes, this is the approach we take. We sit down at a table, we bring in the stakeholders who are involved in this, maybe the engineering manager, maybe the programming manager, maybe the ops manager, and we'll say, “Alright, what are the common tasks that you do?” Once we identify those tasks, we’ll put them in buckets and those will be submittals, programming, and graphics from an engineering perspective.
Then we'll say, “Okay, what do you need to do to start submittals?” They'll say, “Well, we need to do takeoffs.” We’ll ask, “What are takeoffs?” They’ll respond, “Well, take offs are creating the bill of materials, doing spec review, and doing an MEP review, maybe a sales to ops handoff.” So, we have a process. That is this takeoff process.
Then we have procedures for each one. So, Bill of Materials Creation Procedure. This procedure is going to be supported by documents. And I know this seems like a lot, but if you really want to grow and scale your business, and make it repeatable, this is how you do it. So, take off process, bill of materials creation procedure, and then we'd have a checklist. So, we’d ask, as part of this checklist, what do we do? Do we have accurate controller count? Do we have controllers? Do we have accurate product names? Have we checked our ship times, and delays, and fulfillment times on these products? These would all be in a checklist.
Now a cheat sheet may be something like where you have an air handler. This is a standard bill of materials for an air handler. That's the cheat sheet, and then the company standard, this is going to be like your Excel sheet that your bill of materials goes in. Maybe it's controller name on the left, then product name, then description, then quantity, then submittal page, and that is what you put for every bill of materials. So, you don't have five different people creating five different bill of materials formats. There is one bill of materials format, and it's always used and that is the company standard.
So just to recap, checklists are points for when you go through the procedure. The procedure is going to be pretty literal, and sometimes will have another procedure in it. So, the bill of materials creation procedure may have the spec review procedure in it, so you’ll review the spec as part of the Bill of Materials creation.
What you'll do in this bill of materials creation checklist is it'll say to perform the spec review procedure, which means to ensure that you have the latest specs and addendums. Did you check Section 1: General, and your requirements, appropriate vendors, and associated sections? Did you check Section 2: Materials? Did you check specifics on products, submit any RFIs or RFCs for products that are delayed or just don't make sense? Then it'll have things like check the execution, which is where you'll get your sequences from. Then maybe it'll have MEP spec sequence mismatch. These are all things that will be in this procedure.
Moving along, we have our programming process sequence review. This talks through our process. Then you'll have procedures, and the procedures are tactical.
Now, if you never use our training services at all, like if you took this post and ran with it, here's what I would do. If I were in your shoes, I would go in and create my standard, create my subcategories of my standard, create my process for that subcategory, and then I would create my procedures. Then guess what? With each procedure that you've created, you've created your weekly or monthly training agenda. What you would do is you would grab all these procedures, you'd put them in an Excel sheet, and you would work with your team to rank these.
With your team, you would list them as a 1, 2, and a 3 and the first thing you’d train on would be #1. Now, how do you figure out the number and priority of procedures and standards? Well, if you've followed me for any amount of time, you know that I am huge on job task codes. You should be estimating using job test codes like, we have this many hours in install, this many hours in programming, this many hours in graphics, this many hours in checkout, etc.
You should educate your technicians and sales team on really needing to use these job task codes. They help us identify areas of inefficiency so that we can train properly, we can improve our efficiency. If you notice repeatedly, that estimating install labor is off every time. Maybe the install labor is estimated and executed above the allotted hours. You may think to yourself, we've got one of two problems: we either have a serious problem with an estimating, or we have an execution problem.
Let’s assume we have an execution problem. We determine we have an execution problem on install. Well then, guess what standard we should probably set up first? We should set up our installation standard.
So, here is our Installation Standard. We have contractor line out, wire pulling, point to point checkout, and trunk setup. And this is just me spit balling ideas. You can create this any way you want.
A lot of folks seem to really check out contractor lineout. They just really don't place a lot of importance on it, in my experience. So, how can we fix this? Well, we can say that we have a contractor line out procedure. So, what does this procedure include? Well, this procedure may include things like job walk and doc review. This may include stuff like electrical details training.
If you've been through our install course, where we do installation, you know that I’m a big fan of electrical details. So, you have a controller diagram, and it references like ED01, and ED01 may be, 120V 2 position actuator installation. Literally, we would train the contractor on this electrical detail, and we'd say, this is how you do it so it’s clear, and so we'd have electrical details that we would line out to them.
Maybe something to the effect of like a spot check process so that you don't get an electrician that does 100 air handlers, only to realize on air handler 99, that they've been wiring the entire thing wrong.
So, you create a couple processes, the electrical details process, the job walk and doc review process, and you create a supporting document around that, and then you train and empower your installers on how to do this. Once your installation tech is trained on how to do this, then they can go and line out the contractor, and you've just freed up typically a PM or senior tech who comes to do line out, and you train on that.
If you determine that’s your number one issue, then this is our number one training, our first training, and now we can implement this training. We can track the techs who are trained on it. We can track them from new job startup of, “Job is booked” and they start doing contractor line out. Do we see an improvement in that? If we do, then we say great, our process is good to go, our procedure is good to go, our standard is good to go. We ratify that and we build that into our employee onboarding and training. If we find out that that doesn't work, then we actually visit the site, we watch, we observe the process. If the process has gaps, we will detect those during the observation process.
Now, oftentimes, folks will ask me, “How do you map this out with a customer? How do you sit down, from a consultancy perspective, and do this?” Well, I like to do what I like to call a “fishbone chart”. If you've ever seen a fish, you know they have the head, the tail and then the spine projecting out. What I'll do is, I'll sit down with the customer, and we'll say okay, you have your submittal creation process, that's part of your engineering standard. We’ll start it with a document review.
We have submittal creation right here, and we would ask, “What is the first thing you do in your submittal creation?”
They’d respond, “We do a document review.”
We’d ask, “What documents do you review?”
They’d respond, “We review our MEPs, our specs, our scope of work.
We’d ask, “What’s the next step?”
They’d respond, “Well, we create the submittals.”
We’d ask, “What do you create in the submittals?”
They’d respond, “Well, we do a network riser, we do a bill of materials, controller diagrams, system diagram, etc.
We’d ask, “Okay, then what do you do?”
They’d respond, “We do submittal submission.”
We’d ask, “What do you deal with in submittal submission?”
They’d respond, “Well, we often need to know the requirements, we sometimes get rejections, and we need to know how to handle those.”
At that point, the submittal creation is done, but now this may actually be a dependency of the as-built process. So, the as-built process requires submittals being created before you can create as-builts.
So, now that we have this, we can then go back to the model I showed you earlier, and we can start to create our processes: document review process, submittal creation process, submittal submission process. These can have things in them, like procedures and checklists.
So, submittal requirements, did you go into Section 1 of the specification? Did you check the sizing of the submittals? Did you check how many you're supposed to print? 11x17, or is it some other size? Does it need to be in PDF? Does it need to be sent to a specific someone? All of this is so you can avoid rejections so that you can speed up your time. Then we have a rejection log process. How do rejections get logged? How do we submit the RFIs and RFCs related to them?
So, what I hope you're seeing is that you can map all this out, put processes in place, and then with those processes, you can then improve your business by automating your business, making it more efficient.
Okay, so how you would do this? At the end of the day, this is going to feel kind of overwhelming. You may be wondering how you’re going to approach this. Well, first things first, we're going to list this out, then we're going to list out our procedures. Then we're going to look at our job task data, or just have conversations with our team and just discuss, where do we have an issue? Where do things seem to fall apart?
This is where radical honesty and transparency have to exist within your organization. If people cannot openly admit that they suck at something, then this won't work. You have to have people who can be like, “Yeah, you know what, I don't think I do as good with this as I could.” Once you have that honesty and transparency, then things become pretty easy, because then you are having an honest discussion. At that point, as you identify weaknesses, you may be able to suggest a sequence review procedure, or cheat sheets, etc. to augment that knowledge that folks don’t have.
So, you would do that, then you would do a training on that. You would implement the procedure and you would see if things improved. If things improve, you set the procedure aside. That's part of your process now, and you move on to the next procedure.
If you did 12 procedures a year, if you pick the 12 things that your organization is most inefficient at, and you implemented a procedure and a training on that once a month, you would see some dramatic results in your business. This isn't just install, this isn't just programming, this is also sales and marketing. Your marketing, your sales, your operations, everything can be processes and procedures.
At the end of the day, this is all pretty self-explanatory. It’s not really rocket science, but a matter of just executing it. I was on a call recently with an organization, and I was talking with our Sales Director about it. I was just like, “They are in the whirlwind. They want to do it. They see the value, but this guy's got so many things going on that he can't just put his finger on what is the next step.” So, that's what happens with this, it feels overwhelming, so then people don't take action.
So, my challenge to you is to consider what is one procedure that you can implement this month. What is one procedure that you can implement that will improve your business? I mean, test me on this. Implement a procedure, train your team on it, and see how it improves. I'd love to hear from you about that.
We received a question about this topic:
“What are your thoughts on using submittal comments or RFIs as a feedback loop for process improvement?”
I absolutely think that that should be part of your feedback loop and that actually brings up a really good point. Part of your procedure and process should have a feedback loop portion to it, a feedback loop component. What do I mean by that? So, if you have a process for takeoffs, and you are repeatedly noticing that people are missing in the notes, things like BACnet cards, or installed by others, or provided by others, installed by BAS, things like that are being missed, then that should be a feedback loop mechanism.
That would be something like an Excel sheet or a Word doc that you could just type in these things and then share these things within your organization. Feedback loops, I will tell you, are much more impactful if you have engagement of the teams they affect. It's one thing to have a feedback loop on a submittal process, and you feed back the information that something was missed on the estimate. If the sales team is adversarial, and not also on the same journey and willing to take that feedback to adjust and build it into their own processes, then you're not going to have as much effect. So, you definitely should have feedback loops, but you also have to have a culture and an organization that is going to say, agree that you’re all on the same page and that they’re going to go and make changes based on what you’ve have learned already.
Well, with that being said, I hope this was informational and beneficial to you. Remember to reach out if you have any questions. I love answering your questions! Thank a ton for being here and take care.
