How to Create Submittals and Project Documents

Hey folks, Phil Zito here and welcome back! In this post, we're going to be discussing how to create submittals and project documents. So, if you've been following the series and you are of the operations or technical side of the business, you're definitely going to want to read each of these posts because it's really going to make clear to you exactly how projects are executed, what deliverables are required during the execution of projects, how to manage those deliverables, and you're also going to get some tips and tricks along the way.  

I'm not going to assume you understand what submittals and project documents are, so we're going to go through those first, then we're going to go through what's required, discuss how we find out what's required, and then we're going to go through each individual piece of submittals and project documents that you're going to be producing, how to produce them, and how to approach it.  

So, what are submittals and project documents? Submittals are the interpretation of the building automation contractor of the designer or owner’s intent for the project. Typically, we will get an MEP, mechanical, electrical, plumbing, set of drawings. Usually, these will be released for construction, sometimes they will be during the CD phase.  

So basically, in construction, we have where the architect comes along, they create, with the engineer, a set of schematics that are based on the architectural drawings. It's mainly the engineer who builds all of this. From there, the schematic design goes through, and then we create a development design. From there, it's a construction design, and once the construction design is approved, the plans are released for construction.  

This goes along with the specifications. So, whereas the plans are the visual representation of where everything is going to be laid out, of how it works, the specification is going to detail out the details such as, “What products are we using? How should these products operate? How should we communicate that information in the form of submittals?”  

So, submittals interpret all of that information. The controls company will interpret that information into submittals, and they will submit them to the engineer of record for review. They will typically submit accompanying project documents and product documents that are required as part of the submittal.  

Now this is all detailed, typically, in Section 1 of your division specification, the General Section, about halfway down. There will be submittal document requirements that will typically say how many submittals are required, what form they need to be in, what information they need to include, when they need to be submitted, and any project dependencies that rely on submittal approval This could include, for example, “You can't order material, or execute labor, or do your first billing until submittals are approved.”  

That's why oftentimes when I'm thinking of cash flow in my projects, and most of you know my philosophy, you know that we need to get our projects positively cash flowing as soon as possible. We do not want to be working off the capital of the business, but rather we want to run the project as its own profit and loss center. We want to profitably generate cash that is going to pay for our labor, pay for our subs, and pay for our material.  

The biggest barrier to that is going to be submittal approval. That is what's going to divide us from moving into project execution mode. Oftentimes, the construction documents on which our salespeople are bidding, because they're either bidding on CDs or on actual released-for-construction documents, are behind the eight ball when we are brought onto a project. That's why it's always jokingly said that, “Everyone's waiting on Controls”, because we have to interpret these documents, and then we have to provide our submittals, and then we have to wait for our submittals to either get rejected or approved, and then we can finally start executing work. 

I'm going to teach you some tips and tricks that hopefully will get your submittal approval rate significantly higher than what it is now. I'll also teach you some things that you could do to get your submittal rate higher, but that I don't necessarily think is in the best interest of your business. So, I'll kind of delineate between the two.  

So, what is required, like, what is required for submittals at the basic of the basic? We need to have a representation of how we are going to implement our controls, where we're going to implement our controls, and what our controls are going to do.  

Now, that can look very different depending on the engineer. I've seen stuff that you literally copy and paste the one-line diagrams and the sequence of operations off the MEP set, which I don't recommend doing. I've seen people do that, put them in their submittal decks and get submittals approved because they're literally copying and pasting. Sometimes, that can work. So, if you're doing equipment-based controls, and you're just mapping those in via BACnet, sometimes that works just fine, especially if it's a low-risk sequence that can easily be executed via factory-mounted or embedded controls on pieces of equipment. 

When you get into complex sequences, though, and you're relying on embedded controls, you need to be careful. That's when you want to do your due diligence, and that's one of the areas I said where you can just copy and paste and get approval from a lot of engineers, but at the same time, that can really backfire. If those sequences aren't fully vetted and you haven't done any RFCs and RFIs, request for clarifications/ requests for information, to verify why this sequence is goofy, it can just cause for a lot of nightmare scenarios. 

By goofy I mean, I have seen some things where I'm thinking, there's no way this can work. I'm looking at the points list for this piece of equipment, and you want me to control it and do stuff, but it doesn't have controllable points, or it doesn't even have those points, and we would have to add them. Then we'd have a sequence, on top of a sequence, which is the worst thing you can do. You don’t want to have a controller that is embedded in the piece of equipment that's controlling the equipment and then have a separate BAS controller, external to that, controlling other parts of the equipment, and the two aren't communicating.  

So, how do you find out what's required? Well, for our submittal requirements, you're going to go into Section One, General Category, of your specification, at least if you're here in the United States. Now for your sequence, for your one lines, for your equipment list, etc, you're going to turn to several different things. You're going to have your scope of work and your proposal document from your sales team, that should be guiding you. You're going to have your MEP set, and the equipment schedule in the MEP set, and hopefully some one-lines in the MEP set, as well.  

In the specification, you're going to have Section Two, which is going to be Materials or Products, depending on what they call it, and that is going to clarify exactly what material and what products you are allowed to use for your Bill of Material.  

Now, Bill of Material is a term we use quite often in controls, and I find some folks don't know what it means. Bill of Materials, quite simply, is a list of materials. If you think of Bill of Goods, or if you think of just your itemized bill from a restaurant, right? It lists out everything you bought, your drinks, your food, etc. Well, Bill of Materials is nothing more than a list of materials, and that is something that is going to be shaped by Section Two of the specification.  

Section Three of the specification, Execution, that sometimes will detail out your sequence of operations. It will also sometimes detail out your point to point and functional test sheets which may be required by Section One. So, you can start to see the interrelationships between Section One, Section Two, and Section Three of the specification, the MEP setting, its equipment schedules, and its notes, etc.  

So, how do we go about executing our submittals and what do we need to execute? Well, the first thing we need to do is the main page. The main page should have the following information: 

1. The project name and address (kind of important)  
2. A unique project number that you can refer back to, that is in your database 
3. A list of the architect, GC, engineer, and MEP 
4. Your revision 

That way, at a glance, you get all the contact info you need. So, if your subs are sitting out there or one of your Techs is out there, they can look at this main page on the document, and they will know everyone's phone number, where/who they are, who they need to contact, etc and then later on, when your customers are trying to do a retrofit or something, they'll know everyone who was working on this project.  

So, from there, we moved to the Legend, I don't always include legends on my submittals as a separate page. I'll normally include a legend if necessary, on the individual pages. So, this is, you know, developer preference. If it's required in the specification, then definitely do it.  

If your specification says to have a separate legend page, put it on a separate page so your submittal doesn’t get rejected for a silly reason. I see that happen too often, where people are so stuck in their processes and ways of creating submittals for their organization that it's just kind of mindless work. So, we can get stuck in the routine and just kind of moving along, and we can mess up things like legend or maybe functional test sheets or whatever.  

So, next up is the item called the Riser. Now the riser, and I honestly don't know where the term riser comes from, but a riser is both your IP network and your serial network layout, and here's what I like to have on it. I like to have the serial network laid out.  

I like to have what controllers, where's that controller located, what is its address, and I like to have them addressed sequentially, especially if you're using MSTP. That does speed up the communication just a little bit.  

I like to have that detailed out. That way, I can understand what controller I'm dealing with, where it's going to be, and how it's going to be. Then I like to have my IP addresses, I like to have my subnets, masks, everything laid out, and any hardware devices that I'm going to have, any host devices like servers, computers, etc. I like to have all of that laid out on my riser and I also like to have a master Bill of Materials for my second, third, and fourth-tier. So, those are my servers, supervisory devices and field controllers.  

I have that listed out on my Bill of Materials so that I have an idea of what is contained in this product. Sometimes, you will have multiple risers. You may have a riser by floor, you may have a riser by building, it just depends on how you want to approach that and what is in, yes, the specification documents.  

Then we move to the System Diagram, also known as the One-line Diagram. This is a one-line of ductwork, piping, etc, and it has the associated controls devices on the one-line. So, fan status fan command, mixed air temp sensor, discharge air temperature, pressure sensor, etc, and create a system diagram for each individual unique system.  

So, if you have 15 Air Handlers that are typical of one, basically that system diagram, you'd only draw it once. You wouldn't do 15 of them. Now with that system diagram, what I like to do is, I like to put the one line, the bill of material, and the sequence of operations all on a single page, if possible. The reason I like to do that, is that when I'm out in the field, and I'm doing functional tests, even though I will have have my functional test sheets and my point to point sheets, I could still be reading the sequence and looking at the system, all at the same time. That just makes life a lot easier. 

For some of you, that system diagram is going to be a very big drawing, and you'll put the sequence on a separate page. Sometimes also, the sequence is required on a separate page, and there are some benefits to having the sequence on the separate page. If you have to redline the sequence, you are just editing that one drawing, and you're not having to potentially mess with everything else and resize things.  

For instance, maybe you add a paragraph to the sequence and suddenly that makes your page bigger. Now you're trying to figure out how to adjust the one-line so that it can fit in here still, and it just becomes a nightmare. So, you avoid that by having a separate sequence page, and some people prefer that.  

Next up is the controller or panel layout. So, typically what will happen is most of our controllers will not be in panels. They'll be equipment mounted, or mounted in an equipment panel, which we don't really have any control over. So, I will often do controllers on their own diagram with the bill of materials. Then, instead of showing the wires going to the devices, I'll have wires going to electrical detail numbers, and these numbers will correspond to my Master Electrical Detail page.  

This electrical detail page will detail out the electrical details of my controller installations. By having this, I don't have to draw 50 relay terminations for single-pole double-throw relay. I can just do it once as an electrical detail and reference that. If you do that, it becomes really nice because you build up this master list of electrical details, and it gets very clean. Then on every project, you just reference that electrical detail list and you add new electrical details as needed. You train your electricians on the electrical details, and you'll get a much better installation, you'll get better installation, you'll get easier to understand the installation, etc.  

So, on that controller panel layout, you'll do that, and I also like to have a bill of materials. But on this bill of materials, I like to have the individual field devices, So the IO, the inputs and outputs, I like to list all of this out.  

So, submittals, the initial submittal design is going to be: 

1. Main Page
2. Legend
3. Riser
4. System Diagram
5. Sequence Controller/Panel Layout
6. Bill of Materials
7. Electrical Details 

Now that's where a lot of folks stop, submit stuff, and then they get it rejected because they didn't include things like catalog sheets, which describe the individual pieces of equipment, individual IO devices, and everything like that which is often required as part of your submittal package. Additionally, any specific installation documents that are required, software documents that may be required, or point to point checkout sheets.  

So, if you're building your bill of materials, kind of like how we teach in our BAS Advanced Design course, where you're using a master excel sheet, you build your bill of materials, and then you basically embed that master excel sheet into the Visio diagram, then you can actually build your point to point checkout sheets at the same time as building your bill of materials. It's additional columns to the right that you hide on the submittal documents. You just print out the actual excel sheet documents for your point-to-point checkout sheets. That's how I like to kill two birds with one stone.  

Finally, we have functional test sheets. These are the most difficult because functional test is something, in my opinion, you should do on every major piece of equipment, whether it's required in the project or not. So, we're talking air handlers, chillers, boilers, etc. You don't need to do it necessarily for terminal units, you could just spot check those, but if you have a commissioning agent, then you do have to do functional test sheets. Oftentimes, they will build out their functional test in accordance with a commissioning plan, and this is where things can get messy.  

So up to this point, we've had a pretty clean submittal process. We've just followed the steps, we followed the specification, we followed the MEP set, and we're good to go. Then along comes this commissioning agent, with their commissioning test plan, and they've rewritten the sequences to what they think they should be. This doesn't always happen, but this sometimes happens.  

You need to be cognizant of this because your submittal documents can get approved because they follow the plan, then your commissioning can get rejected because you followed the submittal documents and not the functional test and sequences that the commissioning agents drafted up. If you do have commissioning, owner rep, or GC rep, partial or full commissioning, you want to be involved early on with them in drafting the functional test sheets and the functional tests themselves. So that: 

1. Make sure your sequence can actually execute those functional tests;  
2. That they're not doing something that is just not realistic;
3. So that you don't have to go last minute, try to produce all this documentation that you simply can't produce quickly, because functional tests take time to write, especially if you're doing them right. This means that there's a success state, a failure state, an initiating state, and you have to test all these different things. If there's multiple failure states, then you have to test those as well, and those are difficult to write well. So, be aware of that. 

So, with functional tests that I'm talking about, where there's not a commissioning agent, we are simply breaking the sequence of operations out into chunks. I like to have my occupancy initiation, fan initiation, and then I like to have my different modes: cooling mode, heating mode, etc. Then I like to have my failure states. That's kind of how I write out my functional tests, and that seems to work well for me.  

So, to recap, how do we create submittals and project documents?  

• First, we need to know what is required. How do we find that? It's in the specifications and the MEP set, as well as our scope of work.  
• Once we find this information out, the submittals, which are generally in specification, Section One General, then we want to understand what is required for submittal documents:  

• What form do they need to be in?  

• What size paper?  
• Electronic versus physical 
• How many copies 
• Who do they need to go to? 
• What order do the documents need to be in? 

Follow the specification to the letter, but yet at the same time, be cognizant of things, especially when it comes to the sequence, that don't make sense, and you need to address those on a case by case basis.  

• Once you have this middle set built out, then you also want to build out any auxiliary documentation like catalog sheets, installation docs, point to point checkout sheets, or test and balance sheets, if you're required to help support that, or if you self-execute test and balance and functional test sheets and any integration tests.  

Alright, if you have any questions about how to create submittals and project documents, I'd love to answer them for you. Please comment below and I’ll be sure to respond!  

In our next post, we will actually start talking about how to line out your subcontractors. How do you get your subcontractors lined out so that they can execute your electrical work? How do you go and solicit subcontractors? How do you find the right one? What can you do from a training and development perspective from your subcontractors? What should you not do? And also some tips and tricks if you are self-executing instead of using electrical subs.  

Thanks a ton, and take care!