Achieving Success in a Dysfunctional Building-Controls Environment

Is today's building controls environment totally dysfunctional? The short answer may well be yes. But whether it is actually broken or simply suffering because of other industry problems doesn’t change the fact that many projects that are being started today will, without special attention, be turned over with controls that underperform.

The real issue is how to make building controls more successful now. In earlier columns I have stressed the need for design engineers to become more involved in implementation of the control systems they specify. But in today’s fragmented building construction process, it is still almost always left up to the controls contractor to make it all work, regardless of the array of points and sequences that have been specified.

If you are a controls contractor, here are five steps you can and should consider to improve the performance of your building control system projects despite the potential problems and hurdles you will likely encounter throughout the implementation process.

Step 1: Assess the controls design. How to most efficiently prosecute a controls project has a lot to do with the quality of the design provided in the contract documents. The place to start looking for design quality is the sequence of operations, to see how clearly the operation of the various systems is described. To a controls expert, the various ambiguities and pitfalls in the sequences will become quickly evident, and as they grow in number you should mark down the quality. Then, look to see if the points listed match what is needed to perform the various sequence requirements. This step should be started when the system is being priced. Once a contract is in place, it should be revisited and further analyzed to determine what level of added or re-design will be required for it to succeed. Such effort at this stage is usually pretty simple and not costly; it can involve just making notes or rewriting the sequence or, in some cases, adding several points to be certain the necessary instrumentation and sequences will be in place to ensure the various systems operate properly from the get-go.

Step 2: Assess the design engineer. Regardless of the quality of the design, some engineers can and should be more involved in the controls implementation than others. Trying to work with an uninterested (or unknowledgeable) engineer, or not working with one who wants to be involved, can be problematic. Fundamentally, what you must determine is whether the engineer will be a resource and participant in resolving issues in the process of controls implementation, or whether you should in effect take the design and “run with it.” If you find a “run with it” verdict developing, be sure your whole team knows it and is ready to assume the higher level of internal responsibility required.

Step 3: Communication – Issue clear, concise and comprehensive RFIs. Regardless of the decisions made in the previous steps, maintaining communication with the engineer is essential. Every controls design I have seen has faults and ambiguities requiring resolution and these should be communicated so that they don’t come back to bite you. The request-for-information (RFI) process is a very effective means to be certain everyone stays on the same page. Each RFI a control contractor issues should be as clear and concise about the concern(s) and always include a recommended solution to each issue raised. When writing RFIs, keep in mind that your job is to keep the engineer from being defensive about the design. If your narrative makes it clear your recommended solution will resolve the issue, then the engineer is far more likely to see it your way. This process also helps you assess how involved the engineer wants to be. Always try to minimize the number of RFIs by combining issues (and your recommendations) that relate to specific elements or systems. If the engineer wants another resolution, think carefully about what the motivation may be. It’s well worth some effort to get aligned in thinking with the engineer if you can find common ground.

Step 4: Program using standard software modules wherever possible. Your company should develop or acquire standardized software modules for the many HVAC systems typically operated by the building controls. And it should work to ensure standardized software modules are applied whenever possible. Simple (at least simple in concept) and frequently used features such as lead/lag or setpoint reset regimens are still too often developed from scratch for each project and also too often become part of the problem in getting a system to operate properly.

Step 5: During commissioning and startup, resolve problems rather than point fingers. It is very frustrating to have followed a sequence that you know won’t work and then to be blamed when it doesn’t. However, simply proceeding down such a path will likely be costly to you both financially and in goodwill. Be sure you head such situations off as early as possible with proactive response. Keep a well-organized list of conflicts or issues and try to resolve as many as possible with the RFI process. Work closely with the commissioning agent and/or the building operator and ensure your entire team is committed not to point fingers, but to resolve issues quickly before they become big.

I find getting a good handle on how well thought-out and supported the control design is (steps 1 & 2), then communicating effectively with your ideas to resolve issues and problems (step 3), and finally ensuring you implementation minimizes added issues and is effective in resolving all others as quickly and effectively as possible (steps 4 & 5) is the best path for control contractors to succeed in the current environment, wherein few understand modern controls technologies. It is never easy, but if you work to manage the flow of the technologies you are applying as well as the project flow, you can and will succeed!

I invite your thoughts, comments, and good ideas about this article. Please contact me at [email protected]