Hey folks, Phil Zito here and welcome back. In this post, I'm going to be taking you through the biggest barriers to project success and how to overcome them. So, we're going to be diving into issues that you will commonly experience in your projects and we're going to kind of break this out into a couple different phases. We're going to talk through the project initiation phase, then we’ll talk about the execution phase, and then finally we're going to talk about the project closeout phase.
Alright, if you think about a project, they tend to break out into three unique phases:
- The initiation phase
- The execution phase
- The closeout phase
We tend to focus almost entirely on the execution and on the closeout phase. We focus on the execution phase because we want to be able to bill out the labor that we're executing, and then we focus on the closeout phase because we want to get off the job so that we can go to another project.
If I look at the initiation phase, or if we talk about the initiation phase, that's where we will often run into a lot of issues. So, there's this thing called a sales-to-operations, handoff. The sales-to-operations handoff is one of the key barriers that I see in whether a project is successful or unsuccessful.
So, what is a sales-to-operations handoff? Now we've done an entire post on sales-to-operations handoffs, but most importantly, a sales-to-operations handoff is the process of taking a project that has been booked by the sales team, meaning it's been sold and secured by the sales team. Then it's the process of reviewing the mechanical drawings, the electrical drawings, the plumbing plans, the specification, and the scope letter, and it's identifying any potential issues.
Now these could be timeline issues, like there's no way you could effectively execute in a specific time frame. These could be issues related to costing, these could be issues related to scope, these could be material delays, which is something a lot of you are running into right now. The key point here is the sales-to-operations handoff is going to be a process.
Ideally, you'll have a checklist where you can review the scope against the existing drawings and specification and their addendums. You can review that scope, and you can make any adjustments. Maybe you need to add more labor to the job, maybe there's no way you can get it done in the appropriate time, maybe you need to submit a request for clarification or request for information. You can do all of this during the sales-to-operations handoff process.
Now, let's say you've completely skipped a sales-to-operations handoff, which a lot of organizations do. What does the antithesis to the sales-to-operation handoff look like? That really is what we're talking about here, the good, positive practices, and then we're going to talk about the antithesis of those positive practices, which is what most people encounter on their projects.
So, you don't do a sales-to-operations handoff. You're actually on a job site, and maybe you're the project manager, maybe your lead tech, and you get a call from a mechanical asking when your people are going to be out. The equipment's ready, and your electrician hasn't been on the job to install controls. Now that may seem a little bit ridiculous, but that happens way more often than you care to believe.
The salesperson sells the job, the job is booked. No one communicates to you at all that there is a job on the books. No one communicates to you that there was supposed to be a submittal phase. This is notorious on retrofit jobs. Next thing you know, you are sitting there late on a project getting yelled at, getting threatened with liquidated damages, getting told you're behind, being told all sorts of things are your fault. Okay? So how do you deal with that? You deal with that with the sales-to-operations handoff.
Now let's move a little bit further. This is kind of a border between the initiation phase and the execution phase. This is the submittal process. Oftentimes, in order for you to be able to properly execute a project, in order for you to be able to get off the ground running, bill out your materials, bill out your labor, you need to do your project submittals.
Well, what are submittals? We’ve done a whole other post on submittals as well. Now submittals are your submission of your interpretation of the design intent, according to the specification and the MEP set of drawings, and your proposed or accepted scope. Now, oftentimes, the submittals have to be done before anything is approved.
So, what happens if we don't have our submittals done, what happens if we are delayed in getting our submittals done, or we bypass the submittal process? Well, oftentimes, you're not going to be able to bypass the submittal process. If you are delayed in getting your submittals done, that's going to delay your submittal approval, that is going to delay your ability to order material, that's going to delay your ability to do billings, that's going to delay your ability to get your electrical sub out on the job and wiring things up. So, you can see it's a compounding issue of delays.
Additionally, I found that when you work late on submittals, you tend to rush through submittals, and that's where you tend to miss things. Submittals should be an iterative process. You should start typically at the terminal unit level, develop your controller design and your bill of materials, and then gradually work from there to the air handler, central utility plant, and then build in your associated supervisory devices, field trunk servers, etc. That's how you build out a solid submittal set.
Now, what does the antithesis of this look like? It looks like rushing through submittals because you didn't do a sales-to-operations handoff, so you're late, or you just ignored submittals till the very last moment when they were due. Then you submit those last minute and you take submittals from another job, you put them in, and then you forget to change the name of the project from the previous job. There's a slew of issues that this can cause. Not only can this cause delays to your execution ordering of material, and your billings, but it can also cause potential damages, because you are delaying other trades, or at least you're perceived as delaying other trades.
Alright, the next barrier is project success. So, the positive thing to do would be you get your submittals approved, and you line out your electrical subs. Lining out your electrical subs is where you actually sit with your electrical subs and discuss what is going on, walk the job, look over the electrical design, discuss how we're going to implement those design details, and how we are going to execute our installation in this manner.
That way, the electricians know exactly where the material goes, and they have a chance to ask you anything that may be confusing to them. They have an opportunity to engage with you in that way. Now, that's perfect because that will help you to avoid having project delays, having issues where your electricians are potentially not understanding what they are supposed to do on the project.
So, the antithesis of this is never to line out your electrical subs. You literally take whatever quote the salesperson got for electrical subs, you approve that quote, you tell them show up, and you tell them to coordinate with someone in the office. The electrical subs don't know what to install, they don't know how to install it, they haven't been trained on your installation processes and standards, they don't know where things go, and they don't know any details that maybe you just discovered during the sales-to-operations handoff.
Maybe you didn't do a sales-to-operations handoff, and because of that, you did not go about detailing out what these electrical subs need to know. Additionally, you probably don't have their materials separated by system, you probably haven't walked the job with them to show them where things go on the individual systems in any nuances. So, that's going to cause project delays, and proper installation.
That is going to pivot into our next point, which is going to be point-to-point checkout, and programming and design. With point-to-point checkout, the equipment’s been started up, the electrical subs have wired everything up correctly, at least we hope to have, and now you need to do point-to-point checkout. You need to go about looking at your IO, your inputs and outputs, and making sure that they are properly calibrated, and that they are properly installed and set up.
So, as a technician, you are going to look at each input and output, and you're going to properly use your tools like multimeter, magnehelic gauge, temperature, humidity probe, etc, calibrate your inputs. Then you're going to validate that your outputs are driving to the correct control modes.
Now what does the inverse of this look like? The inverse of this looks like not doing any of that. You completely avoid doing any point-to-point. As long as they don't create a punch list, I'm just going to get into and out of the job.
What does that lead? That leads to the systems that never worked, warranty calls, dissatisfied customers, potential liquidated damages, which are time damages based on your impact of the overall delivery of the project and certificate of occupancy. So, not doing point-to-point can cause some significant issues, as well as not doing functional test.
Point-to-point is the validation of correct sensing and operation of inputs and outputs. Functional test is the validation of correct function according to the mode of the sequence. So, when my zone temp goes above this point, I should be in cooling mode. When my zone temp goes below this point, I should be in heating mode, and you check the functional test associated.
I'm not going to get into issues with programming and with graphics design, because those are very deep. But suffice to say, not having a programming library, not having a graphics library can significantly delay and add cost to projects. Anytime you produce a program, anytime you produce a graphics set, you should be storing that in a library so that you can properly reuse that for similar building or system types.
Okay, so we now move to the as-built phase. As-built phase, we're starting to transition from that execution to closeout phase. The as built phase is where we literally create documents as they were built. So, this is where we take our submittal set, and we revise our submittal set to create these as-built documents.
As-built documents should take the systems as they were built in the field. Ideally, the different trades, so your electrical, your installer, your test and balance, your own technicians, are going to create their own as-builts, red lines as they're called. You're going to gather all these red lines together and a centralized person is going to convert those into an as-built submittal set. That as-built submittal set will then be used to provide training to the owner during the closeout phase.
Let's take the inverse of this. You do no as-builts, you do no documentation whatsoever. Maybe it wasn't specified. Maybe you're in a rush. The owner gets a system that they don't know how it works. Even if they are BAS savvy, they don't understand how the system should function. They don't understand how things should come together, and because of that lack of understanding and that lack of documentation, the first time something is not working as they perceive it should work, they are going to assume it's broken and submit a warranty call, thus causing damages to your profit. Thus delaying your closeout of the project, and overall impacting your ability to get off the job and get on to a another job. So, you really need to be aware of that. Not doing a proper as-built, can really damage your ability to get off the project.
Then we move directly into the closeout phase where we're now moving into warranty and associated owner training. So, the owner training is something that ideally, you're going to profile based on spec requirements:
- What type of owner operator do I have?
- How are they going to be using this system on a day-to-day basis?
Then you're going to create training, based on the most common tasks they're going to do. You're going to take this owner training, and you are going to customize it to the type of owner and the common tasks they're going to do. That way, rather than just showing up and walking them through, how to use the browser and giving them some doughnuts and calling it a day, you're actually preventing callbacks and issues. Now, you're training them on how to do the most common things they're going to do every day with that system.
What does the inverse look like? The inverse of owner training is either not doing owner training at all or doing owner training where you're basically just swagging it. You have an owner training checklist, they sign off on it, you log into the system, you make sure they all have a username and password, you walk them through how to override a point, how to change the schedule, and you call it a day.
That ends up with owner operators who cannot operate the system, who are confused on the system, the nuances of the system, and because of that, they're going to put things in override. Because of that, they're going to misinterpret graphics displays. Because of that, you're going to get callbacks and warranty issues for things that aren't callback and warranty issues, and that's ultimately going to delay your ability to get off the job. It's going to impact your profitability by eating into those warranty dollars.
So, there you have it, my friends, those are some of the common barriers to project success, and those are solutions to make sure that you don't get into those barriers in the first place. I hope this helps you. Please leave any comments or questions below.
Thanks a ton and take care.
