How to Schedule out Labor and Common Tasks

Hey folks, Phil Zito here and welcome back. In this post, we are going to be discussing how to schedule out labor and common tasks for your building automation projects. So, up to this point in our BAS project management and operations series, we have talked through sales to operations handoffs, performing takeoffs and re-estimates, creating submittals and project documents, and lining out our subcontractors.  

Now we're coming to a part where a lot of folks tend to get confused as to how to handle this, because there's a strategic piece to this, and then there's a process piece to this. Largely, how you go about scheduling out your labor and your tasks is going to be dependent on both the project timeline as well as how you're structured organizationally. So, let's take a look. 

So, how do we go about scheduling out labor? Well, the first thing we need to understand, and we should have figured this out in our sales to operations handoff is:  

1. What is the project timeline? 
2. What are the conditions of project execution?  

So, from a project timeline perspective, we need to understand: 

1. When does the Certificate of Occupancy need to happen? 
2. When do we need to hit our specific milestones?  
3. For example, when is equipment going to be started up? When is power going to be flowing? When is water going to be flowing? When are the hydraulic plants going to be working, if there are any?  
4. Based on those milestones, that will typically come from project meetings, we can then start to back in where do our people need to be?  

Additionally, we have to understand the specification. Does the specification have specific timelines? Usually, it doesn't have timelines around execution, but it does typically have timelines around submittal creation.  

So up to this point, we've talked about project meetings, and the project meetings and the MEP are going to have equipment, startup dates, power dates, water dates, etc, and your significant completion date, the specification, potentially, is going to have your date for your submittals. If there are any commissioning agents, they are going to have a commissioning plan and that itself is typically going to have dates as well. So, you'll understand, based on both the commissioning plan as well as the specification requirements, what level of involvement and labor you have to have.  

Remember, I said this is kind of a process and the process is, we take our inputs: 

• What's our scope of work? 
• What's our project timeline? 
• What is in the specification related to deliverables, and timelines around that, and then our commissioning plan? 
• Our test and balance and whatever we need to support there.  

So those are our four main inputs. Now you could argue, especially right now during the Coronavirus-era, is product and material delivery dates, because it seems like that is the phase gate to a lot of execution issues right now, and a lot of timeline issues is the delay in materials.  

I know here at Smart Buildings Academy, we use a lab kit for some of our courses and lab kit delivery days have been pushed out about eight weeks because of suppliers. So, we are with an eight-week lead time from the moment we place an order for a lab kit to actually getting that lab kit to show up. So, we're seeing significant material delays.  

Now, in order to properly schedule our labor, we need to also understand site conditions. So, we need to understand, is this a prison and we're going to have to add extra time so people can go through in-processing/security to ensure they're not bringing anything in, or they have to be escorted, and background checks, and all that. It takes time. 

Is this a working hospital where we need to put up screens, and that needs to be done in off-hours?  

Is this an accelerated timeline like an Amazon warehouse or an Amazon data center where they want us to work 24/7 because they're saying, “Hey, you need to man three crews with constant execution, because every moment that this is not up and running is costing the business revenue. More revenue than it costs to have y'all working double time or time and a half.” So, we have to factor in those things as well.  

How is our Team Structured? 

Once we have all those inputs and conditions, then we need to balance that against how we are organizationally structured. So, we're looking at how do we schedule out this labor and these common tasks? Well, we have to understand how our team is structured and a typical structure for a team will be: 

• A Startup Technician, who will be responsible for point-to-point checkout, uploading/downloading controllers, downloading graphics, and just doing basic setup of the system,  

• A Designer, who can be split into potentially two roles; a submittal designer who only does submittal creation and then a separate designer for graphics, floor plans, etc. Or, they can be one in the same, so the person creates the submittals, as well as creates the graphics at the same time. 
• A Programmer or Senior Tech, who is responsible for writing the programs, validating the programs, and validating functional test.  
• A Project Manager 

Scheduling the Labor 

Now we need to start to schedule out this labor. And how we schedule out this labor is by looking at our specific dates that we are going to be working with. So, the first thing I do is: 

1. Let's say that this project is slated to take 12 months. I will create a 12-month chart, and your software tools that are in your system may do this for you. Across that 12-month chart, I will break out the labor evenly. I'll take the Technician, the Designer, the Project Manager, and the Programmer hours that I've got allocated, and I'll just break them out evenly across the 12.  
2. Next, I will look at the timeline, I'll overlay the timeline, and I'll say, “Submittal creation needs to be done by month 2 and a half,” so I'm going to pull a lot of those designer hours. I'm going to look at, “How many graphics do I need to create,” and I'll have a basic idea of, “A floor plan takes this,” or, “Oh, it's a 3D floor plan, that's going to take that.” So, I will understand that, “60% of the Designer hours are going to submittals, 40% are going to graphics. I'm going to pull 60% of those hours and put them in month 1.”  
3. I'd take 60% of those hours, we'll say it's 100 hours, so I'm going to take 60 hours, put them in month 1 and 2, with the 40 going in month 1 and 20 going in month 2. Sometimes, you can flip that if you feel like this is an engineer who is going to be sending you back a lot of resubmits saying to change this, change that, and then you can flip into, you know, 20 for month 1, 40 for month 2. That's how you start doing this as you start pulling the hours you need into the month, based on the phases you're going to be actually executing.  
4. Once again, using round numbers, say we have 100 hours of Technician time, and we know that immediately following submittals, we're going to order materials. We know that materials are going to take, let’s say four weeks, so that brings us to month 3, month 3 and a half. That's when material delivery happens, that's when subcontractor line out happens, maybe we need a day to support subcontractor line out, so that's 8 hours.  
5. Then let's say at month 4 and half, month five, subcontractors are done, the mechanical startup is done, and electricity is working, then we're going to start our point-to-point. So, maybe we pull 32 hours into month 5, month 6. So, I start moving around my hours. While I had them evenly distributed across my months, I now start to pull them into the months that are appropriate. 
6. All the while, I have this master list of hours, and this is why I've always advocated for task-based billing. Task-based labor doesn't have to be super complex, you don’t have to have super-specific task codes, but if you just have a Designer task code, an Installer task code, a Programmer task code, and a Project Manager task code, that's four task codes that you can break your labor hours across.  

Obviously, each labor hours can have a different rate, and what typically happens, is that my estimate I'm going to get from the sales team is going to be, “I have 100 hours of Technician rate labor, I have 100 hours of Designer rate labor, I have 50 hours of Programmer rate labor, and I have 20 hours of Project Manager rate labor,” something like that? Project Management is usually 100 hours of tech time. You'll usually have 10 to 20 hours of project management time, depending on the complexity of the project. So, the rule tends to be 10 to 20% of your technical time is going to allocate project management time. There's no rule of thumb for technical time, programmer time and designer time, because it's all based on the complexity of the project.  

**Now, the worst thing, in my opinion, you can do is go by points. You might say, “Okay, we've got 1000 points, and we're going to have so many hours per point.” Points aren't equal. You could have 1000 VAV box points, and that's pretty simple compared to 1000 ultra-complex.  

Okay, so up to this point, I started talking about how we lay out our labor, and how we look at it from a task-based perspective. Now, all the meanwhile, we are going to want to be looking at all the supporting tasks we're going to do. So, what I would typically do with that 12-month timeframe is say, “Submittals are due here, mechanical startup is here, commissioning is here, test and balances here, owner training is here.” Then, once I know those buckets, I know where I'm going to be placing my labor, so I start to schedule out my labor.  

It's really important that you do this, even on the small projects, because what will happen is you'll start to get really busy. This should be done for each project as soon as it's released. If you have a semi-accurate timeframe, and once you've done this enough, even if the mechanical and the general don't have an exact timeline, if you know what vertical market it is, this is plan and spec, or design build, and this is healthcare versus education versus commercial real estate. Once you know that and the Certificate of Occupancy date that they're targeting, you can pretty much back into what's going to happen. You can also look at your climate and say, “If this project’s kicking off in January, in Wisconsin, the likelihood of them laying the foundation in January's probably not very high.” So, we can already look at a potential delay taking us into early spring when the foundation gets laid, and the stub ups, and everything like that happens.  

That doesn't mean we can't do submittal approval. That doesn't mean we can't get material on order. Once again, if it's a design build project, this may be something where the submittal process is multiple iterations before we ever even get to construction documents. So, we may have significant delays and we want to be cognizant of this.  

Now the common tasks that we're going to perform, and I'm going to go through these, and then we're going to be talking about this a lot through the next several posts.  

1. Lining out our subcontractors 
2. Performing point-to-point checkout 
3. Uploading programs or downloading, depending on your software programs, to our controllers 
4. Mapping our controllers into supervisory devices 
5. Setting up our users and graphics, and point mapping 
6. Setting up any auxiliary objects like trends, etc, alarms, etc, and those are going to be driven, typically, by the specification 
7. Set up our functional tests and work with our commissioning agents for those, if we have commissioning agents 
8. Tab support, close out, and training and warranty.  

So, you want to be able to schedule all these tasks out, and you want to really understand where it is your labor's going. That’s going to allow you to not only make sure that you know where your revenue sources are coming, where your expenses are going, and also what your labor demands look like. It can also help you from a staffing and talent management perspective. If you notice that you have 100 projects on the books, and these are taking 10,000 programming hours, but you have one programmer, you have a significant problem there. With one programmer, ideally, you can get 2000 hours a year out of this programmer. That's ideal, because while someone may work 2080 hours, if you have 52 weeks x 40, and then you take away 80 for vacation, you give them 2000 hours. The reality is, people like to say that they get 100% utilization out of their labor, which means that every hour they're working is billable to a project, but that's not realistic. You typically are getting about 80% utilization, because people have to drive to job sites amongst other sorts of things. So, of actual labor, not commute, not transport, you're typically getting 80% efficiency, at best, from your staff, and that's if you can keep them really focused and super engaged. 
 

I believe, personally, that effective utilization is actually more in the 60-70% range. Because if you're sitting there, staring at a screen doing graphics all day long, I'll be honest, your effectiveness and efficiency starts to degrade. You tend to get 4-6 good hours out of people, at which point their effectiveness starts to degrade. That's why, whenever I see people working 10, 12, 14 hours as a BAS technician, I start to cringe because I've been in their shoes, and maybe it's just me, but everyone I've seen who work those kinds of hours, their effectiveness starts to degrade after about 6 hours. You would be better off getting a second person and having that person working another 8 hours than having someone work 10-12.  

Now I know it's easy for me to say that sitting here recording a podcast, with the market being as it is, but if you at least are tracking your labor and understanding your labor requirements and your backlog, you can start making talent management decisions. You could say, “Oh, this person's retiring, these are task-based skill gaps that we have, we need to hire for these roles, we need to backfill these positions, and we need to have a business continuity plan for when this person leaves.”  

These are all things that at Smart Buildings Academy, we can help you. We provide consulting services and training programs that close these talent management gaps and help people with their talent management strategy. You really should, even if you don't work with us, you really should consider,  

• How do I use my project scheduling?  

• How do I use my backlog management and all that information that I'm getting?  
• How do I use that to make decisions on how I staff my team, how I train my team, and how I position my team to execute work?  

It is, of my opinion, that project timelines are going to both become more compressed as well as longer. So, what does that mean? How can something be compressed but also extended at the same time? What I think you will see, and we've seen this already and I think you will continue to see is, project timelines extended, but with dead periods.  

You will have compressed work periods where people get approval to work, and then they've got to jam all this work in that time period, but then maybe a shutdown due to COVID regulations or something like that slows things down. Then it opens back up, and slows things down, and opens back up. I believe that at least, for the next year or two, that will be how a lot of us are executing projects, and we need to be tooled up to do that.  

Those compressed timelines, they tend to be driven by policy, by local policy within a metro or a county, and that local policy is going to hit all projects at the same time. So, if you're depending on 12 months, stretched out across 12 honest months to execute a project, and all the sudden you have three months compressed, or six months compressed, to execute a project, and that's across multiple projects, you're going to find yourself short staffed and unable to execute.  

That's why I highly recommend, if you're doing labor scheduling now, that you consider a compressed timeline, an extended timeline, and a normal timeline. Say to yourself, “How could we handle if our city closed down projects for X amount of time, and then opened all projects back up? How would we address that? What would be our strategy? At least have some ideas so that when that hits, you're not surprised, because at the end of the day, everyone else is going to be suffering the same thing. Everyone else is going to be struggling to get man up projects and execute, because we simply have limited labor and limited staff. So, being able to prepare for those situations is going to be important, but also being able to be reasonable with those is a delicate balance. You're not going to work all your people 80 to 100 hours a week, or at least I hope you wouldn’t do that. Not only is that inefficient, as I just mentioned from a utilization and diminishing returns perspective, but you're going to burn out your people, they're going to quit, and they're going to go somewhere else where people aren't expecting them to work those kinds of hours.  

So that being said, that's a look at scheduling out labor, common tasks, and some strategies, theory, and thought behind it. I hope this has been helpful. If you have any questions, please do not hesitate to reach out.  

Thank you so much, and I look forward to enlightening you in our next post where we will start to discuss how to manage project costs. Thanks a ton, and take care!