AutomatedBuildings.com Article - Making Collaborative Design Work

A camel is an example of an animal designed by a committee, the saying goes. Unfortunately, many of today’s commercial building energy system designs are equally stark examples of such a committee process. This was made clear for me in a recent project. In this project, a new laboratory building, we were enlisted to help the project’s design engineer meet the owner’s expressed mandate of minimizing its energy use. Our part was to support the design effort with an ultra-efficient all-variable speed central chilled water plant and certain “relational” water and air side distribution control technologies. We proposed a simple chiller plant and distribution configuration for low cost, ease of operation and maintenance, and a significant improvement in system operating efficiency. This design concept and the underlying technologies were adopted by the engineer, who had successfully used them previously in other projects. The technologies were briefly presented to the client who accepted them for the project.

However, as the design progressed, the design process seemed to take on a life of its own and overshadow the engineer’s efforts and initial project goals. Cost and energy efficiency standards seemed to vanish. The owner, a large public educational facility, has a policy of conducting an inclusive collaborative design process. That seems like a good idea. But the team was not prepared for the process that actually transpired.

First, the plant operators stepped in to tell the team that the single chilled water circuit the engineer envisioned (commonly called a variable primary flow system), had not worked well for them at an adjacent facility. They called for the system to be changed to a conventional primary-secondary system. It was clear to the engineer that the real problem was not the system type, but the quality of the system design in that other facility. The engineer offered to help remedy the problems in that system, but was turned down and a change to primary-secondary on this project was mandated.

Next, one of the owner’s staff engineers did an analysis that showed (incorrectly, since the analysis was based on a different type of chiller) that the simple configuration with equally sized chillers should be reconfigured into different sized chillers, pumps, etc for greater efficiency. The design engineer tried to explain that with the design and operating methodology selected for this project such a change would unnecessarily complicate the operation of the system without any improvement in operating efficiency, but again, the “process” eventually accepted the staff engineer’s view against the recommendations of the engineer.

Finally, the commissioning agent determined that the low energy pumping system the engineer developed would not work because the methodology went against his concept of pumps as pressure devices. Furthermore, he believed operating pumping in accordance with actual demand for cooling from individual loads would put too much strain on the control network. While these objections were without any technical merit, they were generally accepted and design changes mandated as a result.

The result of what was intended to be a collaborative process became instead a system design that if it remains in place will look (and operate) like one that was designed by a committee - because it WAS designed by a committee, rather than through collaboration as intended. At the final design review meeting the engineer tried one last time to explain to the Owner and Architect that the system had become much more complex and less efficient than it should be as a result of this process but he was cut off by the project manager who noted it was all water under the bridge now. (Water around a camel’s hump would be more accurate.)

In response to this unfortunate outcome, I have thought about what went wrong and how we can organize to do better in future projects aimed at maximizing system performance and efficiency. This is a timely question because at a recent Earth Day conference I heard reported that some early analyses of the important green building movement show that it may not really be succeeding in developing commercial buildings that operate more efficiently than standard code designed buildings. One of the cornerstones of the green building design process is collaborative design, but like the process I had just witnessed, these processes frequently appear more like design by committee than effective collaboration.

It’s easy for the engineering community to simply ignore these potentially disturbing signals that collaborative design may not really be working. I have heard many engineers complain about them but also note that such process failures are not the engineer’s fault. After all, it is the owner and sometimes the architect – not the engineer - that largely set up these collaborative processes, pick the cast of characters, and ultimately make the decisions that approve the design such processes grind out. But we are seeing that owners may generally not be well served by these design processes and may be getting neither the simplicity nor the performance they are asking for these processes to achieve. If that is the case, then the engineering community needs to step up and speak out about how such collaborative processes can be improved.

The first step toward improvement is to recognize the difference between a committee effort and a truly collaborative process. As the camel example points out, committee work is often distinguished by conflict rather than a shared vision. In an earlier essay (Growing a Greener Engineering Profession), I relayed a conversation I had with a successful and high profile engineer who told me that he was very discouraged about what he called the “sniping” that engineers do to one another in peer review processes. What baffled me, as I was informed of the discouraging developments in the design of this laboratory facility, was the lack of any useful technical discussion to reach an understanding of the basis of the design. Neither the owner’s staff nor the commissioning agent seemed at all interested in such an understanding of the basis or elements of the design – to see why the engineer had chosen to do what was shown in the preliminary design documents. Rather each discussion appeared to start with rather sharp pronouncements, some of which certainly appeared from my more distant vantage point to lack attention to the actual design intent. As the discouraging story of this design de-evolution was related to me the term “conflict” seemed to fit much better than collaboration. That is much more typical of committee behavior, and not at all effective in developing the type of synergy among participants to which a collaborative process aspires.

In the manufacturing industry, a key element to improving the level of technology in any product is developing a manufacturing process that is suitable for the level of technology being implemented. The manufacturing industry has found that effective collaboration is of vital importance to success in the development of products that incorporate advanced technologies. It has also found that to be successful, such collaborative processes must start with a shared understanding of the product goals and at least some agreement on the path that will be employed to achieve them. An HVAC system is a product, and a large part of the reason the industry is locked into low performing technologies may be the processes we employ to make this product. In our industry, efforts toward a shared understanding are almost entirely absent when collaborative processes are initiated. There are occasions in which team building approaches are employed, but almost never do these exercises focus on the specific technical issues facing the team.

If this industry is to be successful in achieving the level of energy and environmental performance in buildings that newer technologies make possible, the processes we employ to achieve these advanced levels of performance quite simply must be dramatically changed. The current practices more often foster confusion and misdirection and need to be altered to ensure effective technical collaboration is achieved instead. The present rules owners and architects frequently use in supporting advanced design processes often tend to drive engineers away from the team process in their design work. It’s much easier and certainly more productive simply to develop a design in isolation and dump it on the owner’s lap. The problem is that such isolated design work cannot achieve the level of innovation or success that a truly collaborative effort can.

When a collaborative design process fails, it is rarely because anyone wants it to fail. Rather, it fails because the process lacks the necessary coordination and understanding among its participants, or has not been conceived to support the level of technology envisioned for the project. Too often the participants involved in the process bring their own rigid preconceived notions of what technology should be applied and how to best apply it. Then, their efforts during the design process are focused on pursuing those notions against others, rather than actually collaborating to support a design evolution that best fits the project goals and the ensuing implementation and operational environments necessary for it to succeed. For a collaborative process to work, we in the engineering profession need to be much more ready and willing to work together, and we need to develop a better understanding of the goals and vision of the project. That’s the part of the process that most needs to be changed to make collaborative design work. And while such change is surprisingly difficult, it offers substantial system performance rewards and the opportunity for professional growth for those of us willing to try!

Events	Want Ads
Our Sponsors	Resources