As I write this, I’m working on estimating a medium-sized plan/spec project. For the sake of putting forth some order of magnitude, I define a medium-sized project as something more than a typical tenant buildout/remodel, maybe a new stand-alone facility having no more than a few levels, and perhaps a dozen or so mechanical plans to accompany the HVAC design specifications. The particular project that I’m working on, as I multitask the generation of this column, fits those criteria.

In general, the project is a construction of a new fire station in a suburban area. The mechanical design consists of a myriad of equipment, including furnace systems, exhaust fans, unitary heating equipment, and some specialty equipment as well. The control systems are to be simple stand-alone controls, meaning that there will be no networking of individual controllers, and no Building Automation System.

The mechanical plans consist of eleven drawings, including the following: a cover sheet with general notes and abbreviations, floor plans and sections, two pages of mechanical details, two pages of mechanical equipment schedules, and a sheet of temperature control details. As far as the written specifications go, the only section relevant to the control of this project was section 290993: the Sequences of Operation.

To get to the point of this article, I’ve always been alert to inconsistencies between pages of the same set of mechanical plans, and also between the mechanical plans and the written specifications. I continue my case with a couple of examples, taken from this particular project.

First up, the unit heaters. On the drawing that has the temperature control details, there is a detail dedicated to the control of these suspended electric unit heaters. The sequence of control indicates that the “supply fan shall cycle and the electric heating coil shall energize to maintain space temperature.” Sounds like a space-mounted thermostat is being specified. On the very next drawing, in the equipment schedule for the unit heaters, a note indicates that the units shall be equipped with a return air thermostat. Okay, I suppose that’s not a contradiction to what the control detail calls for, as a return air thermostat will measure space temperature. However, now we turn to the specification, section 290993, and it states (and I quote)…”unit fans shall cycle according to the wall mounted thermostat. Bam! There it is. So which is correct?

Another example from the same project: the exhaust fans. There are thirteen fans on this project. I’ll just choose an arbitrary pair of fans from the temperature control detail sheet. It says that EF-3 and EF-4 “shall OPERATE CONTINUOUSLY”. I take that to mean “NO CONTROLS”. However on the equipment schedule for the exhaust fans, the note indicates that these two fans are supposed to be controlled by a “reverse-acting t-stat”, which is old pneumatic language for a thermostat that will make on a rise in temperature to activate the exhaust fan. Section 230993 of the specification doesn’t really support either statement, and just serves to complicate the design intentions.

So there you have it. Why, you say? Why such disparity, between the plans and specs, and even within the plans themselves? Why aren’t these documents consistent among themselves, and what are we to believe? How are we to interpret the consulting engineer’s design intentions, without having to go back and ask for clarification?

After experiencing this time and time again over my career, I’ve come to my own conclusions as to why it happens. Actually it’s not that difficult to imagine. In a typical consulting firm, there may be several different departments all working on the same project. A mechanical department, an electrical department, a temperature controls department, and so on. Each department is generating scope documents pertaining to their specific discipline. The mechanical engineers are generating mechanical plans and specs, the electrical engineers are generating electrical plans and specs, and the temperature control engineers are generating T/C plans and specs. There is overlap among and between the disciplines, to be sure, This is where the inconsistencies emerge from. The mechanical engineer will generate an equipment schedule, concurrent with, yet independent from what the temperature controls engineer is designing. The T/C guy is putting together a sequence of operation and control detail, that might be the design intent of the project, yet may very well be different from what the mechanical engineer is specifying in his notes on the equipment schedule.

So you can see how this comes to be. Yet what about inconsistencies between the control details and the sequences of operation included in the written specification? Shouldn’t those two pieces of the documentation be generated by the same individual, or at least within the same department of the engineering firm? You would think.

So nobody’s perfect, and I’m not writing this to bash anyone or rant about the issue. It’s just the way it is, and so we need to, first and foremost, know how to deal with it, up front, before a project is procured, and on the back end as well. But in the long run we also need to determine how, as an industry, we can work to eradicate these kinds of inconsistencies.

As far as dealing with them, in my role as estimator and sales engineer, I do my best to either cover the worst scenario without pricing myself out of the bid, or clarify which portion of the documentation that I’m following, and make it known to those of whom I’m bidding. I certainly use my own judgment as well, as to what makes the most sense in my opinion and from my experience, from both a design and an economical standpoint. I’ve developed a pretty good handle on what the engineers’ intentions are, in most cases, and that’s the way I’ll bid the job. I also know that, if there’s a large cost difference between going one way or the other, I’ll raise a flag and ask for clarification right there and then, if the circumstances allow for it.

[an error occurred while processing this directive] When a project is procured, and these things become a reality, then the decision takes on more significance. Generally, an RFI (request for information) is the best course of action, as it puts the decision right back in the hands of the consulting engineer. Unfortunately the road from generating an RFI, submitting it through the proper channels, and receiving a response, is not always the quickest route on a typical plans and specs project. We can always take a gamble, hedge our bets, and control that unit heater by a return air thermostat, and hope that the consulting engineer doesn’t come to us after the fact, demanding that we put that thermostat on the wall! I’ll leave that up to you to decide, stating that I’ve “been there, done that”. Sometimes it’ll work to your favor, and sometimes it’ll bring on a whole new set of consequences to deal with. So be careful…

As far as working as an industry to eliminate these types of inconsistencies contained within a project’s plans and specs, I’d have to say that I’m frankly at a loss. Obviously better supervision within the consulting engineer’s firm is a good start. But it just seems to me that there should be a system of checks and balances in place, to ensure that all documentation gets aligned, and inconsistencies are minimized. I think we’d all have a lot to gain from it, and as a whole things would move along a lot smoother. Maybe it’s software. Maybe it’s the development of a standard. Maybe it’s minimizing the overlap between engineering disciplines, with more clear-cut rules on who does what. For instance, a note in the equipment schedules that simply states “refer to temperature controls details for specified control of unit.

Tip of the Month: When in doubt, shout it out! On the front end, I will typically indicate in bold print in my proposal any discrepancies that I’ve found, along with an explanation of how I’ve dealt with it. This generally alerts the individuals on the receiving end that “we need to talk”, although I’ll typically take it upon myself to make the follow-up phone call. As always, it all comes down to good communication.

[an error occurred while processing this directive]
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]