Hey folks, Phil Zito here and welcome back. In this post, we're going to be continuing on from our previous post where we started to dive into the topic of standards for building automation companies, and we discussed processes. Now we're going to be looking at how we go about actually creating the processes that support the standard.
First things first, we have to build a process for our standard, this is our template that we use internally when we’re building out processes, but I suggest that you build your own template.
Jut to remind you of where we left off, you create a standard and then you line out the subtasks with each standard. As part of any consulting arrangement we do around processes with customers, we first figure out what are their standards, if they have any, what processes and tasks they do, and then we help them build out the processes.
So right here, we have a standard, and then we have a process, using kind of a fishbone chart. We have Submittal Creation Start, Document Review, Submittal Creation, Submittal Submission, and Submittal Creation End.
So, we could create a process for the document review. What we would do is we would just call this process “Submittal Document Review Process”. I’m going to skip a couple of things that won’t go quite as expansive as normal, but just realize that I'm only doing that because I'm not going to go through each individual thing and bore you to death. 
Now, the introduction, what is the purpose of this? So, the whole purpose of this introduction section right here is for several things. One is to list out the purpose of this process so that it's crystal clear why we're doing this process. The scope, like what is the scope of this process? Well, the submittal document review, that's pretty clear as to its scope. It's to review submittal documents like mechanical plans, specifications, scope of work documents, etc.
In scope, if you're going to be reviewing multiple documents, and it's going to be variable, then maybe you don't get as specific on which documents in particular. You would just say “documents that support the submittal document process”.
For Purpose, we would say “This process details out the review process for documents during the creation of submittals”. Then you say something to the effect, “It will be supported by the engineering staff and sales staff prior to creation and submission of project submittals”. Pretty straightforward.
The Scope is “project documents and scope documents”. Document Management, so what documents, where are they stored, things like that. In our case, “Documents shall be stored on SBA SharePoint site”.
Roles and Responsibilities, this is where you would kind of dictate out, “Engineering Lead”. Responsibility would be, “Oversight and support on the execution and maintenance of this process”. So that means this person is going to responsible for supporting this process, making sure people actually execute the process, and also maintaining the process. So, anything that needs to be updated.
The next Role could be “System Designer 1,” and we'd say their responsibility is “execution of the process and completion of document review checklist”. Then maybe we have like “Sales Engineer” who would “Support SD1 on review of documentation”.
Okay, what Materials do we need, if any? In this case, we don't really have any materials we need, but if this was something to the effect of like an actual installation task, then you may have installation materials. Some folks in the material category do like to consider software, checklists, things like that, as supporting materials. So, they'll fill out supporting material to the effect of a document review checklist.
So, Process Step 1, “Post RTO (release to operations) SD1 shall collect RTO report and validate project documents are gathered”. Step 2, “Using document review checklist SD1 shall review project documents”. Then Step 3 we'll say, “Using take off checklist, SD1 shall perform submittal takeoff process”. So, we're basically just getting super high level here. Step 4, “Within company standards, SD1 shall review process results with engineering lead, if project size exceeds process requirements.” Basically, if it's a large job, we're going to do a review.
Okay, so now what Inputs do we have? We have our “Project Documents; we have our “Release to Operations Post Checklist”. What are the Boundaries? Obviously, the boundaries are “Specific to single project,” and “Specific to submittal pre review”.
Then Tasks, and this is where we get very specific on our tasks. This is where we may want to get as specific as, “SD1 shall collect from Sales Engineer the following documents: CDs, SPEC, Scope of Work, Addendums” etc. Then, “Utilizing Document Review Checklist SD1 shall perform takeoff, build bill of materials, etc,” I'm not going to fill out all the tasks, but you get the idea.
What is the Output going to be? “Complete Bill of Materials, Complete Document Review Checklist etc.” Next is Exceptions to Routine Process Flow. So, what would be the exceptions to this flow? Some exceptions might be something like if you have a design build, and it needs to be iterative. This would be something where if this is an iterative process, you're going to do your interpretation, you're going to iterate that interpretation, submit that back, get the return etc.
Points of Control basically are quality checks. So, where is the engineering lead going to be able to check quality of this and where can the SD1 check quality? Well, our points of control are, “Checklist Completion, Spot Check of Equipment Schedule to BoM”. Things like that. These are various points of control.
Measurement Conventions, I typically skip over this for most of what we're doing. The reality is, in our process, it's if you use the points of control and you use the verification properly, you should be solid. But I mean, if you wanted to, you could add measurements around efficiency, things like that. Hours estimated versus hours executed, you could add those measurements in there.
Verification, “Verify BoM Against Equipment Schedule; Verify BoM Against Scope of Work.” So, you have variety of things. References, this is where we're actually going to reference our checklists and stuff. So, Material Type would be “Checklist”, and its Name would be “Document Review Checklist. Maybe we have a “Cheat Sheet” and it’s a “Take off Cheat Sheet”. The difference between a cheat sheet and a checklist is that a checklist is “thou shalt” and it's these specific things. A cheat sheet is more of, “Don't forget to check the notes. Don't forget to look for exclusions. Don't forget to check this, don't forget to check that.”
Location/Link, for us, this would be “SBA SharePoint”. I recommend keeping all things on some sort of cloud accessible site that allows for version management. It'll make things a lot easier for you. Then Change History, as the process owner makes changes you would enter those into change history.
Alright, so we have a process. Not too difficult, I hope, doesn't feel too overbearing. You create these by looking at job performance, you look at sales performance, and you identify the most common areas where you are losing efficiency, or you're losing deals, or things are going sideways. Then you create a process to mitigate the most reoccurring failure. Once you create this process, then we create our supporting documents.
So, I would open a Cheat Sheet Template and what you would do with these cheat sheet templates, the Inputs would be my “MEP Set, my Spec Set, and my SoW”. What is the purpose of this cheat sheet? “To assist in the execution of a project takeoff during a submittal document review”. Then we would call this Submittal/Takeoff Cheat Sheet.
Sub Action 1: “Read the Equipment List.”
Tasks: “Look at the equipment schedule, add up the pieces of equipment, and then spot check on the SoW and the floor plans.”
Deliverables: “Equipment List
So, that would be just a cheat sheet. That's something a lot of folks mess up. They look at the equipment list, but they don't compare it to the scope of work and then they don't compare it to the floor plans. Then they wonder why they're so off on pieces of equipment.
Sub Action 2: “Verify Notes on Drawings”.
Tasks: “Read through the notes and identify Div 23 responsibility and exclusions.”
So, just another tip here, the purpose of a cheat sheet is common issues, and you can build this cheat sheet. That's why you keep it on a shared drive, because as time goes on, you discover more common issues. You basically can build out, you know, a list of common issues and say, these are the things we should be doing.
Now, what if you want to build a checklist? Checklist is exactly the same layout, but now you're going to have Step 1 Review MEP Set. Now you want to get tactical on what to do. So, what is the first thing you want them to do on the MEP set? Probably check the currency of the documents. Making sure that you're working with the latest documents, making sure you have any addendums, anything like that. There's no point in doing a submittal takeoff if the stuff is a year old and it's DDs, and the project’s 100% CDs, but you're working off of DDs, it’s going to be completely different and so there's no point.
Now, Tasks. We want to “Count Equipent on Equipment Schedule and Add County to Equipment List”. Then we would want to “Review and document SOP, sequence of operations.”
This is typically towards the end of the mechanical set, and we're basically going to want to pull out this because that's going to be important later when we get to the spec and we get to the scope of work. We're going to have a triad. We’re going to have the sequence that is in the MEP set, we're going to have the sequence that is in the spec, and we're going to have the sequence of which the scope of work was based.
We need to make sure that there's no conflicts between the three, because once again, as part of the submittal takeoff, if you have a multi-air single path air handler on the MEP set, but you have a 100% outdoor air unit on the spec, and then on the scope of work you have a packaged rooftop, one of those is correct. Or maybe none of them are correct, but you will not know that if you just simply say okay, we're going to take the first sequence we see and we're going to run with that.
Then we'll have “Review Notes for Inclusions and Exclusions”. These are things like, “Div 23 shall provide but not install, will furnish shall not install, or shall not furnish but shall install, or shall monitor only.” All these things that we need to pay attention to. Additionally, at this point, we would want to circle back to our equipment details and be focused on, maybe this model has no BACnet card, but the scope of work says we should have a BACnet card.
Alright, so Deliverables is very general. We would come out with an “Equipment List and a Documented SoP”.
Then, we would have Step 2 Review Spec. Now, there's a very specific reason why I do this. I do “Review MEP Set” first because that's going to build out my Excel sheet. It's going to build out my equipment of which I'm going to build my Bill of Materials on with that equipment, and with the points that may be in some one-lines of the MEP set. Then I can say, let me look at the spec and figure out what product I should actually use. Because Section 2, if you're using a CSI master format spec, typically Section 2 is going to be material and that is going to give you the specifics on controllers, transformers, actuators, valves, sensors, etc. So that way, you can then say, we know we need these kinds of sensors based on the one line, or we need these sensors based on the one line of the MEP set. These are the specific sensor types.
So, our Tasks will be to “Validate Intent, related sections, and system type”. That'll be in Section 1 of the spec. Part 2 now, we're going to “Further Define Material Requirements in alignment with Section 2 of Div 23 Spec. So this is where we're saying, you've got the sensor, you need to be 4 to 20 mA, 1k platinum, or 1 k nickel, whatever. Then we would “Review and Document SOP”. This is in Section 3, Execution of the Spec. So typically, towards the middle, you'll start off with like installation requirements. That's important to know as well, especially if on your submittal documents, you need to specify like this wire type, where this needs to be running conduit, or anything like that.
Our Deliverables would be “Bill of Materials” and Document SPO Spec”. We would just simply copy and paste.
Now, we move to Step 3 Review SoW. Our Tasks would be to “Read through the SoW define in and out of scope items; Contrast SoW scope to defined Equipment list and BoM; Define and Document SoP”. This would give us our Deliverables of “Equipment and Bill of Materials”. We would edit that as well. We’d also have a “Documented SoP”.
Finally, Step 4 Review all document results and resolve issues. So, our Tasks would be to “Review and identify any document issues”. Then any of these issues, we'd “Utilize RFI/RFC process to address,” if appropriate. Then our Deliverable would be “Final Equipment List and BoM”; and “RFI/RFC Submissions”.
So, there you have it. We built out a checklist, we built out a cheat sheet, we built out a process. You put this all together, and literally spend 35-40 minutes on 3 to 4 solid processes that are impacting your business. Then, based on that, you then actually work the processes. You do that for a good quarter or two, and you see the process’ impact on the business. Then you come back and you say, what do I need to adjust? What do I need to train folks on? Each one of these tasks bullets that I wrote out can all be training sessions that you create, during your weekly or monthly training, right.
If you record those training sessions, then you can actually create like a hyperlink and store that recording on your SharePoint site. Then, when someone says, “Read through the notes and identify Div23, responsibilities and exclusions, I don't really understand what that means.” They click on the link, it's a video of a person going through a spec saying, “See, this is what I'm doing. I'm using the highlighter, I'm doing this, I'm doing that.” Through that process, they're going to kind of list out all these things that the person should know, and then when you bring on a new designer, or you bring a designer from another company that had a different process, you simply have them watch these videos the first one or two times that they're going through this multi-step checklist. That is how you create an effective process that supports a standard.
So, my hope is that this made a lot of sense to you. You took some value out of it. It was something that you're finding impactful, definitely let us know. We're going to continue to try to bring you these more practical walk-through processes and things that we're doing with our customers so that you can implement them in your business and hopefully see some pretty good results from it.
So, thanks so much for being here and take care.
