Hey folks, Phil Zito here and welcome back. In this post, we are going to be discussing BAS project management. We're going to go from start to finish with BAS project management:
- How we initiate a BAS project
- How we handle a BAS project through the design phase
- How we handle it through the implementation phase
- How we handle it through the closing phase
When I look at any building automation project, and I've managed a ton of them from really big projects to smaller projects, I look it and I say to myself, “Alright, how can I make this project effective?” I first have to define what an effective project is.
So, this is Phil Zito’s interpretation of what an effective project is, and I encourage you to understand what your business views an effective project as, and I'm pretty sure it will be aligned with mine. If you know how your project effectiveness is going to get managed, that's going to drive your project management process.
On Time
I look at an effective project that is on time, on budget, and on scope, meaning that we execute the project within the defined timeframe. That's important not only for customers, but that's also important for our own internal business. If projects start to drift outside of the estimated timeframe, then we can start to have labor shortages or we can start to have labor conflicts.
On Budget
On budget. Making sure things are on budget is important because our projects, and you'll see me hammer this throughout this post, our budget should be their own profit and loss center. I look at each project as a profit and loss center, and what I mean by that is if you think of a business as a whole, a business brings in profit. Profit is the resulting revenue minus cost, right? So, this business brings in profit.
Each project initially is very cost heavy and revenue light, meaning you have to issue out labor costs, you have to order material, you have to deal with subs. All of these things are costs. Usually, the subs are the least impactful of the costs because you can have terms that say paid when paid typically, although in this climate right now paid when paid is usually negotiated away because subs are so high in demand.
That being said, your project kicks off, your goal as a project manager should be to get that project profitable as soon as possible, meaning that the costs that are hitting the project are overcome by the revenue that's coming into the project. That's important, because as a business, that enables you to not have to fund the project from business cash flow. You actually will fund it from project cash flow, which then means that that business cash flow can be diverted and focused on sales, marketing, R&D, etc.
On Scope
The third thing is making sure things are on scope. This is going to directly effect on time and on budget. The more scope drift you have, the more your budget is going to be impacted and the timeliness of projects could be impacted. Those three things are often known as the project management triangle: scope, project cost, and project timeline.
Now, as I mentioned, a project has four major areas. This is not following the PMP model, the Project Management Professional model. This is just a model that I've utilized throughout my career that has worked pretty effectively.
Initiation Phase
The first phase is the initiation phase. This is the phase where I see most projects fall apart for most businesses. If they're going to make mistake that's going to lead to slippage, that's going to lead to project timeline and cost issues, it most likely starts in the initiation phase. Now, granted, there is a labor skill component to this. If your people don't know how to execute work, or they don't have defined processes, that's definitely going to impact project efficiency. But let's just go with it and assume that your people know what they're doing, and they have good processes. If those are true, then if you handle the initiation phase properly, you should have a successful project.
What is the initiation phase? The first thing is release to operations. Typically, a sales process is prospecting, qualifying, proposing, closing, right? You prospect, you find an opportunity, you qualify the opportunity, you propose to the customer, that proposal gets approved, and you close, and you book a project, you book a deal. Now, between that booking a deal and executing a deal, there should be a process.
This is the first process we're going to talk about which should be the release to operations. This is where the scope document, MEP and spec set, and any addendums are gathered by the salesperson, brought to a meeting and discussed with the project manager and the technical lead. Why do I say the project manager and the technical lead? It just depends, right. So, in some companies, the project manager has technicians assigned to them. Other companies, project managers manage the financials, and then the techs are assigned to an operations manager and are distributed through a pool of people.
The purpose of this is you have the salesperson and this project manager coming together, they're going to review the scope against the documentation, against the costs, against the timeline. Then based on that, they're going to potentially re-estimate, and this is important. Re-estimates are important for a couple of reasons. One, it gives you an accurate representation of project costs so that you can communicate back to the sales manager where the salespeople may potentially be missing the mark.
You should positively and/or negatively re-estimate. Positively re-estimating is going to say, we actually can execute this in less time, or we cannot execute this in this time. Now, positive re-estimates usually happen at the end of the project whereas negative re-estimates usually happen in the beginning. You don't tend to positively re-estimate a project in the beginning, because you want to have all the executed costs accounted for and then you'll re-estimate the project if there's any additional margin.
The purpose of re-estimating is to feed back to the sales team. Any issues with their estimating, if they're missing materials, if they're missing labor, if they're missing scope items, you want to communicate that so that can be trained on that. Additionally, during the release to operations, you're going to want to go into initial 12-month labor scheduling, typically 12 months.
You typically have a 12-month running labor schedule if you're on construction projects. What you're going to do is you're going to pencil in, when is your labor, you're going to pencil in, when are your sub, and you're going to pencil in when are your material costs going to hit. That way, you can start to get an idea of how you're going to manage cash flows on this project.
All of that comes together to complete the initiation phase. Now that's a high-level look at an initiation phase, but what that allows you to do is that allows you to really kind of understand what is going on with your project and how you're going to manage that project throughout the life of the project.
Design Phase
Which brings us to our next phase which is the design phase. Now, if the initiation phase is the most critical phase, in my opinion, the design phase is the next most critical phase, and you'll probably be surprised to hear this. I believe the implementation phase is the least critical phase of project management because if you've done initiation and design properly, the implementation should take care of itself.
The design phase is your first barrier to profitability on the project. Quite often, in the specification, you'll see that you can't order materials until submittals are approved, you can't go and bill out until submittals are approved, you can't go on site and start executing work until submittals are approved. So, all of your profit-generating activities, the activities that you're actually going to be able to revenue against, all of those tend to hinge on the submittals.
So, I see a lot of folks who like to hold off on the submittals until later. I firmly believe that in most cases, that is a bad idea. The reason why is, as I mentioned the submittal, unless it is expressly called out in the general conditions or in the project timelines, the submittal should be the first thing you do, and it should be done almost immediately after the release to operations if you're at 100% CDs, 100% construction drawings and documents. If you're at 100% CDs, the likelihood of addendums that are going to mess with your submittals are very low. I mean, you could even go 75% CDs in some cases, but what that means is now you're going to be able to create these submittals, and with the submittals you're creating, you're going to be able to bill out for that. You're going to be able to get those approved faster, which is going to enable you to start billing for material orders.
Now, material orders are really nice, because depending on the distributor you're buying from, you can also have paid when paid terms, or things like that. So, you can order the material. If you have the right terms from your distributor, and the right terms in the project, you can actually get some positive cash flow going on material orders, and you can also get some positive cash flow going on submittals because there's a lot of automation software that will automatically create baselines submittals from your initial proposal and scope letters.
So, you do all that, right. You create your submittals, you get your materials on order, you also do sub reviews and takeoffs with your subcontractors and your lead installer. It's at this time also, that if you're doing any really IT centric or integration centric project tasks, you want to start getting ahead of those. The worst thing you can do is an all-IP controls job and have no interaction with the customer until the closing portion of the project, and only then find out the customer's IP addressing scheme, or their process for adding devices on their network, or their ACL and firewall schemes. You want to figure all these standards out initially during the design phase, and then putting that information into your submittal documentation. The reason why is the sooner you get engaged with the customers IT group, the better.
It's also at this time that you want to start coordination with your commissioning agent. I often find that a lot of project managers just accept that there's commissioning agents, and they do no coordination on the front end with the test plan. By missing coordination with the commissioning agent, while they're developing their commissioning test plans, you are losing the opportunity to influence that test plan. There's nothing worse than getting a test plan that is simply not capable of being executed. If you can get ahead of that and realize what the commissioning agent’s doing, the test plan they're creating, and how they're going to measure the success of this project, then you're going to be able to really avoid a lot of pain during the closing phase of the project.
Implementation Phase
Alright, so now we move to the implementation phase of the project. The implementation phase of the project, like I said, and folks are either going to agree or disagree; there doesn't tend to be any gray area here, but in my opinion, this is the least important phase from an impacting of the project. If you've done your labor scheduling right, you've done a proper RTO, you've done a proper submittal design, you've done proper takeoffs and reviews with your subcontractors, then implementation should go smoothly.
You should be having standards that your subcontractors are trained on, so the install portion should go easily. You should be ordering your materials specific to the equipment. Air handler 1 has a pallet that shows up with the equipment for Air handler 1, and that has electrical details specific to those pieces of material. Those electrical subs have been walked through that, and you validated with your electrical sub that whoever is going to be leading the sub team understands that, and you're not walking through with someone who's never going to be on the job site, and you're then going to have to retrain a whole new team. If you've done all that, your install should go smoothly.
Additionally, if you're using automation tools, your graphics should come from your submittals. Part of your submittal should be understanding customers color scheme, their expectations on graphical layouts, if they have any graphical or naming standards, all of these things should have been fed in and discovered during the design phase and should make your graphics pretty easy.
Then programming. I don't know why so many folks get hung up on programming. A lot of folks act like programming changes; our programming has really not changed in the several decades that we've been doing graphical and line code programming. Sure, there's been a couple things that have come out with Guideline 36 and Title 24, but for the most part, we still do our PID loops exactly the same, we still do our sequencing exactly the same, and if you're writing programs from scratch every single time and not using design patterns, then you're really being inefficient. You should have install graphics, programming, all of that should be a common process with common standards that you're utilizing.
That's why implementation should be the easiest phase of project management. Now, granted, are there accelerated projects? Are there like lab projects, or tier four data centers that are extremely complex? Are you sometimes doing multi-system integration that's extremely complex? Yes, definitely. I would still argue that even in those cases, of true MSI work, where you're doing multi-system use cases, that if you get the design, and you get the user mapping, and you get the proper use case mapping done during the design phase, your implementation still should be easier than everything else.
Closing Phase
So, saying that, we now move on to the closing phase. This is the phase where everything tends to fall apart. You know, you're at POC 70%, right percentage of completion 70%. You start to move into this closing phase, and people get lazy, or people say, “Well, it's not in the spec, I don't need to do it.” All that ends up creating are callback issues, warranty issues, and project slippage. I have seen more costs burnt during the commissioning, during the functional tests, during point the point, than any other part of the projects. If you've done a lot of project management, you know what I'm talking about? If you've done your initiation and design phase, right, implementation should have gone smooth. It's usually in the closing phase where you lose your project efficiency and where costs start to pile up.
So, how do we avoid that? Well, first off, it comes back to, yes you guessed it, processes. We you should have defined checkout processes. At a minimum, you should have point to point processes. Point to point checkout, some subcontractors will actually do this for you. This is becoming increasingly more common. We have a lot of subcontractors that are putting their people through our training specifically our install courses so they can assist in the point to point and they can take on that part of the project.
Next up is functional test, functional test. In my opinion, if you have a major custom built air handler, or you have a central utility plant, or you have any Title 24 or Guideline 36 sequences, you should do functional test. So, you should do functional test, because the callbacks related to systems are almost always point to point, right? The VAV box isn't stroking right, the incremental floating valve isn't stroking right, we're not getting proper flows on our boxes, our chillers not getting proper control to the secondary loop, etc. Those are combinations of either point to point, people not doing proper checkout, which ultimately it comes back to properly lining out their subs. But they're not doing proper point to point checkout, or they're not doing proper functional test.
Commissioning, if you've done point to point and functional test, and you've influenced the commissioning agent and their test plan, should go rather smoothly. Commissioning something that a lot of people get nervous about, but it doesn't need to be something that makes you nervous if you are really engaging with them early on. I think people get nervous with commissioning because oftentimes, they haven't engaged with the commissioning agent and their test plan until the end of the project. Then this gigantic test plan comes out with all these functional tests, and they realize they’ve got no time left in the job for this or, how are they going to do that, or they didn't write their program to be able to do that.
Simply, if they had engaged earlier in the project, they would have realized that they can understand what this test plan is going to be, and they could build in a graphic for the commissioning agent, they could build in a test and balance graphic, they could build in special points to their programs that enable them to force it into a cooling mode or heating mode, so that they can test things.
So, you've done the checkout, and you've done a good job. The checkout exists for three reasons:
- Obviously, make sure the stuff works
- Make sure that you've validated that the stuff works, and it's documented, so that when someone says it doesn't work, you can come back and say, “Well, it did work, and it's documented.”
- Make sure it's actually installed right.
You can get a floating valve that works on the screen, you command it to 0 to 100%, and it closes 0 to 100%, but maybe someone set it up on a normally closed valve instead of a normally open valve. So, you think you're commanding that normally open valve, commanding it open, but you're actually commanding it closed, and vice versa. So, those are things that you want to get physical eyes on.
Now, as-builts. Things are going to change during projects. It's just a fact of life. Unless you want a customer to repeatedly call you back, because the system that's installed does not represent the system of the design, then you need to do red lines. Red lines are going to say that this controller was actually put here, this com trunk runs through this area. That's really important, especially when you get hard lead ceilings. Additionally, you want to produce O&M materials.
Now, why do you want to do this? One, it's typically contractually obligated, so you have to do it. But also, you want to make sure that you're providing your customer with a guidebook that they can utilize to be self-sufficient. At the end of the day, this is like a general rule that I've experienced in life with customers and control systems, the more your customer utilizes the control system and understands what they're doing, the less likely you are to get callbacks, the less likely you are to have warranty calls, and the more likely the customer is to engage you for service, engage you for retrofits, and engage you for expansion of system capabilities.
You know, if someone utilizes something, they're going to start to find things they'd want to improve, and that's scary to a lot of people. They think that if we teach them to do all this stuff, they could mess it up, or they could go and cause issues. What is worse to me is that you don't teach someone how to use something. They're getting yelled at by their boss because it's hot in the CEOs office, and they try to figure it out on their own. They're overriding stuff, they're changing min and max flows because you haven't set up graphics for users, so everyone has the same graphic. The next thing, they're changing K factors and all sorts of craziness, and you're getting calls because the system no longer works, versus if you had simply taken the time to train them, to map out what this user is going to have to do, record the training, document the training, and give them processes like step-by-step how to change setpoint. These things are going to ensure that the customer can execute and they have a checklist to follow. That's going to reduce callbacks, and it's going to reduce them messing with your system.
That's why I say closing is where most of the profitability is lost because people rush through it, and they can't defend themselves when someone says something never worked, because they never properly documented point to point. The customer doesn't understand what they have, because the as-builts aren't accurate, and the customer is trying to make something work. You scheduled training, you showed up with the donuts, you took them through the two-hour training, customer forgot what they learned by the end of the day. After your two-hour training, which was meant to be eight hours, but you only used two hours, and you're happy because you saved six hours, and the customer’s happy because they think they saved some time, but no one learned anything, and immediately after those two hours, they went to a bunch of trouble calls. Maybe that afternoon, they went to an access control training, and maybe then after that they did lighting training. By the time that day is done, they've completely forgotten everything you've taught them, they have nothing to refer back to. When they get that call about the CEO’s office being hot, or the patient’s room being hot, guess what they're going to do? They're going to override stuff; they're going to change stuff and try to figure it out.
This then leads us up to warranty. It leads us into warranty calls, it leads us into a customer being dissatisfied. This is often the customer operations team. This is often their first experience with your business, and because of that experience, this determines quite often, whether they're going to use you for a service contract.
But warranty should not be something you dread. It should not be something where for 12 months, you're just like, “Holy crap, I hope no one calls me. I hope they forget we exist.” Unfortunately, that's how a lot of people approach their projects. Warranty should be an opportunity for you to start having discussions with the customer about service opportunities.
Oftentimes, the operators who receive a building system, receive that system that was designed by the construction team, and usually, the operators were not consulted around that design. So, they're going to have things they want customized. You should not be customizing these things as part of your project unless it's in scope, by the way. So, don't turn warranty into a customization fest, you should be paid for that.
That being said, it should at least open up conversations. “Oh, you'd like this graphic,” or, “you'd like this tool? Oh, you're interested in a programming class because you would like to be able to make some changes to this or that. Great! Let's talk about that.”
Okay, let's recap. Initiation, Design, Implementation, and Closing: a four-phase process to BAS project management. Yes, I know, it doesn't map up with PMP. Yes, I know, there's a lot more to project management. There's stuff like call planning, project initiation strategies, project mission, stuff like that, but we have to realize that while you have those more capital project areas and domains that are specific to the PMP methodology, we are often a sub of a sub.
So, you have the GC, the mechanical, and then controls. So, our ability to influence the project charter, our ability to influence the project mission, the project communication plan, the project RFI and RFC management process, we often have those dictated to us. We often do not influence those. So, that's often why I leave those out when I teach project management. Project management from a BAS perspective, while it is important to understand proper communication and the legality around communication management, things like text messages, emails, written documentation, how those are legally enforceable versus just talking to someone on a job site and them saying, “Oh, don't worry about installing the VFD.” That's a completely different legal conversation.
That being said, where we're able to influence, if we look at that kind of Pareto Principle, what is the 20% that will impact 80%? Well, initiation, design, implementation, and closing, if we get those right, the statistical likelihood of our project executing profitably and doing well is significantly higher.
Okay, so that wraps up all the information I have for you on how to manage your BAS projects from beginning until end. So, we had some questions come in regarding this topic and I was thrilled to be able to answer them for our readers.
Question #1: Would takeoffs be the responsibility of the design team or the estimating team. For example, VFDs, control valves, stuff like that?
Well, it really depends on your organization, and how your organization is structured. Typically, with control valves, and VFDs and things like that, that should be captured during the takeoff on a plan and spec project. First, notes should be checked on the equipment schedule to see who actually owns this, and the spec should be checked as well, because quite often there will be “furnished by but installed by” or “not furnished by installed by”, or “furnished by not installed by” language. So, that affects both purchasing of material as well as installation labor.
Those are two separate chunks, right, furnishment of material and installation labor. You need to recognize that sometimes you may have the installation labor, but you may not have the furnishing of materials. Additionally, with things like VFDs or integration cards, those are things that, done right, if the spec says so, you may be able, although I don't recommend it, to completely control that VFD or that chiller via BACnet card and not hardwired. Now, I will always point back to you should have hardwired for things that you're integrating like a chiller, like a VFD, etc. I just don't trust integrations. It's too easy, even if it's wired up perfectly, for someone to install a BACnet MSTP device on a 9600 baud trunk that is 38k4 baud and take down the trunk or start causing data collisions, and now your integration is no longer able to control. So, in my opinion, you should use integrations for monitoring, but you should use hardwire for control.
Now, who would be responsible for these things? It depends, once again, on your organization. If your organization has a sales estimator, who estimates things then obviously, the estimating team should look for that. If your team is smaller, and you just have a straight up salesperson, and all that salesperson does is quote, maybe based on point count, device count, then yeah, that might fall on the design team.
I will caution you that you really do want to try to pay attention to these things, because if you have 100 VFDs, or you have 1000 control valves, the difference between a control valve with one CV and the control valve with another CV rating, that can be a significant cost. Stainless versus brass, things that have resetting versus non-resetting actuators, things that have floating actuator versus a proportional actuator, these costs can significantly add up.
Question #2: After completion of a job, we have financial reviews. Should the project estimator or estimating team be involved?
First off, that's freaking awesome that you have financial reviews after a project like that. The reality is that most folks that I talk to, they're too busy to do an end project review. If you've followed me for any amount of time, or if you've been through any of our courses, you know I'm a big advocate of job tasking. That's basically like you have an install task, a design task, a programming task, and your technicians will record those tasks at the end of the week. Then those tasks will be measured at the end of the project, and they’ll be compared to the estimated tasks. From there, you'll realize where inefficiencies lie.
You can then you'll decide:
- Do I mitigate this through training?
- Do I mitigate this through processes?
- Is this an estimating issue?
- What is the issue?
- Is this specific to a single vertical market?
- Is this specific to a single salesperson?
- Where is this inefficiency coming from?
Then you have data from which you can say that this is a training issue, this is a process issue, this is a sales discipline issue, etc.
So, yes, the project estimator should be involved in those kind of meetings, because I'm assuming, based on your question, that the project estimator is the one who estimated this, and that's how your organization works. So definitely, they need to be able to say, “Well, no, hold on, I know it looks like we underestimated cost, but you have to realize that this was rushed by the GC, and we had to estimate during 25% DDs so we had to put in this cost.” So, if that happened, and that estimator had to estimate during 25% DDs, and it was not very clear what the potential scope could be, then they can say that's why they did that. That's why they put so much labor or material padding, or that's why they put so much risk in here, because of those issues. You can't just blindly critique something without having the full contextual awareness of why that thing happened.
Question #3: Would you agree that with value engineering, which is one of the PM’s responsibilities, there's an impact and effect of on quality of the project from the customer's perspective?
So, yes and no. So, quality of the project, in my experience, while there is like clear value engineering impacts, like using a less complex system, or using terminal equipment controllers which are like wall mount thermostats, using those instead of using a full-blown control system, yeah, obviously that is a functionality difference. In my experience with customers, communication and presentation, have a very large impact. What do I mean by that? When you communicate through both verbal and written communication in a clear way, your submittals are clear, your point-to-point documents, your functional test, your training is clear, it's concise, and it's actionable, that has a big impact on customer perception.
If I walk into a training class, I’m all disheveled, I haven't shaved in two weeks, and I say, “I'm here to teach you controls, and that's the training I do,” if it looks like a turd, it's going to be perceived like a turd. Versus if I go in polished, I have a sign in sheet, I say, “I've researched that you are this role, and based on my understanding of this role, this is what I'm going to cover in the training. Do you agree that that's what I should cover in the training? Are these the tasks that you believe you're going to be executing? Walk me through a day in the life of your role.
Based on that, you can say, “I was going to train you on this, but based on this conversation, I'm going to train you on that. And if you're okay, I'm going to just videotape it with my little GoPro here, that way, I can give you the video afterwards so you can refer back to it. Oh, and by the way, you said you need to change set points, you need to change schedules, so I'm going to send you some PDFs afterwards with screenshots that show the most common way to change schedules and change set points.”
These are almost no cost to you, but it gives a perception of professionalism. It gives a perception of quality that will overcome. Now granted, a wall mount thermostat is just a wall mount thermostat. If you're just using like a home thermostat to control the system, you're the ability to deliver complex sequences just isn't going to exist.
Question #4: Can I spend a few words on how to write down the manual on the building automation system to give to the customer?
Okay, O&M manuals. They're often clearly defined in the specification. It’ll say that you need to have this document, it needs to be in this structure, this many pages, this many copies, etc. Oftentimes, it follows kind of a guide spec mentality. So, how do you take something that's contractually obligated, and make it useful to a customer?
I mean, you could totally just swag it and be like drop a 1000-page programming manual, or a 1000-page supervisory device manual and tell them to have fun. In my opinion, this doesn't necessarily begin as much as a manual. I am admittedly bias because I run a training business, and we produce training, and we utilize videos that do training, and we are heavily processed business, we teach processes, because I find that the quickest way to augment skill is to teach someone a process.
So, my answer to you is going to be, you have this O&M manual, but you also have training. You usually are going to have training with the customer, and so in my opinion, how you will solve this is in the training portion. You give them documented spreadsheets or checklists on how to do common tasks. So, the nice thing is it feels kind of overwhelming, but when you actually do a job task breakdown, you realize very quickly changing schedules, viewing alarms, viewing trends, navigating graphics, changing set points; those five things will take care of the majority of the things a common building operator needs to handle.
You're not going to teach them HVAC, right? If they don't know HVAC and they don't know controls, send them to us. We'll teach them. Yeah, there you go, shameless plug. But other than that, you give them those five process checklists, you record the training as you do those five process checklists, you tie it back by saying, “Let's open up the submittal set, let's open up the as-builts. Okay, we can see this air handler has these points. Now let's go find it on the graphic because you need to change the setpoint because it's too cold or too hot. Okay, now let's go find the setpoint. Now let's walk through it.”
You walk through it once videotaping, and then you have the customer walk through it. That's how I would approach this. I wouldn't be pigeonholed into a manual. I would look at it as how I can approach from a process driven perspective.
Alright folks, that’s all the questions we have. Thanks so much for taking the time to read through this. I know it was a little bit longer than usual, but I love the opportunity to be able to engage with our readers and listeners and push that information back out to you.
Thanks a ton. Take care.
