Mention the word “engineer” to any architect, and you’ll hear “linear,” “pragmatic,” and “coordination problems.” Ask any engineer about architects, and they’ll reply “endless design changes.” After decades of working in close juxtaposition on building projects, architects and engineers still face fundamental issues of teamwork in integrating their efforts into a seamless design.
Why is this problem so stubborn? I spoke with several architects and engineers, and a builder. One of the chief values architects bring to their clients is their role as conceptualizer: analyzing the problem, often redefining it, exploring numerous alternative solutions, some perhaps never tested before. Engineers, on the other hand, take their cues from the architect’s solutions and leadership, working within an overall concept already established. Engineering innovation, when it occurs, is constrained within a framework of parameters ordained by the architect’s design. This relationship often results in engineers getting to work only after the architect’s design has been set. “This,” says Jamie Wright of Toronto’s Young + Wright Architects, “[leads] to changes when building systems are designed after the architectural design is set.” John Patkau of Vancouver-based Patkau Architects calls this a cultural difference: “architects look for the best solution; engineers often look for the most straightforward one.”
This “cultural difference” seems to lie at the heart of the discord that often plagues relationships between the disciplines. Engineers complain that architects design in circles, re-examining ideas thought to be resolved, leaving everything negotiable late into the design process. Architects assert that engineers don’t explore alternatives to create insightful solutions, eager to rush into detailed design. Not surprisingly, coordination errors stem largely from decisions being made by the two “camps” that are out of sync with one another. This is exacerbated when clients hire engineers directly–often to cut fees–and compete with architects for control over the consultant’s work.
This fundamental difference in approaches spawns other issues. As prime consultant, the architect negotiates detailed client contracts, but these contracts often lack specifics on engineering duties. Consequently, architect-engineer contracts miss details found in the prime agreement. Important specifics of scope and expectations are missing, and engineers end up performing services they had not budgeted for. Their fees can’t support the level of exploration architects are paid for, and their budgets dry up before their work is done. “Underneath it all, conflicts are usually fee-based,” says Mike Heeney of Bing Thom Architects of Vancouver, BC. Christopher Dean of Wood Banani Bouthillette Parizeau adds, “During the design process the engineer does not negotiate the technical requirements to ensure that adequate service spaces are provided.” Allen Williams, President of the American Council of Engineering Companies (ACEC) adds that another unrelated problem is inadequate communication between the disciplines.
Most such problems can be–and often are–easily addressed. For example, it’s not difficult to draft contracts that address scope issues, improve communications between the disciplines, or specifiy agreements to meet regularly. These, however, are not the main problem. Architects, engineers and contractors agree that underlying it all is the matter of process. The architect’s process is reiterative, and the nature and form of the end result are often not determined until the process is nearing completion; even the goal itself evolves as the design evolves. The engineer’s process is a pragmatic one of linear progression. This is evident even in fully integrated A/E firms such as Toronto’s NORR Limited. Says Mike Summers at NORR: “Architects find it easier to conceptualize ideas, whereas engineers need detail to build on.” With this basic difference in process, it’s obvious that architects and engineers need to commit to thoroughly understanding one another’s process and working mindset.
As inextricably interdependent as they are, the disciplines need to shed the distrust–the kind of uneasiness we feel toward people from another culture. Engineers must learn to embrace and contribute to the architect’s exploratory process. And architects must learn to appreciate that engineers can’t develop their systems in a progressive, efficient fashion when the reiterative design process presents a moving target. Both must learn that an integrated building solution results only when each understands the other’s decision-making process. Perhaps we could learn from countries that include a heavy engineering curriculum in the architectural training syllabus, teaching architects to think in an “integrated” fashion. Says Mike Murphy, formerly of Bird Construction in Edmonton, “The best of the best ideas always are the result of [the disciplines] coming together in free and open collective thinking and discussion.”
An excellent precedent for an integrated approach to design is the Edmonton Space Sciences Centre by architect Douglas Cardinal. The contractor, Bird Construction, offered a guaranteed price right at the conceptual stage, based on only six drawings, calling for close involvement in the development of the design. The project was then carried from concept design to occupancy through weekly meetings in which everyone participated: client, architect, engineers, contractor, subcontractors and suppliers. Each discipline helped solve another’s problems. Architect played engineer, engineer played contractor. The project went from concept design to substantial completion in a record 13 months. There were no change orders, except for one small credit. The owner even received free extra space and every consultant and contractor made a profit: symbiosis at its best.
While every project might not be suited to such a framework, such a collegiate approach calls for certain simple, yet critical steps to be taken. The architect must create a detailed, realistic work plan that is jointly created with the client and the engineers. Every issue of process and coordination should be addressed at the outset, so that each discipline is aware of the process needs of the others. “Engineers look to architects for leadership and coordination,” says Tunca Iskir of the US firm of Torti Gallas and Partners, “and architects should be prepared to challenge systems proposed by engineers.” Schedules should be closely intertwined, and give each party a realistic amount of time for their work. Sequencing of tasks should eliminate redundancies in effort, and decisions must be charted in a logical sequence driven by process. The architect should prepare a Consultant Management Plan (see sidebar) that addresses key issues of scope, timing, and process. Architects complain of the time demanded by a detailed work plan, but this time represents a profitable investment.
Are architects from Mars and engineers from Venus? Sometimes it would seem so, and this demands a creative approach to reaching a meeting of minds. But then, architects are trained to be creative, are they not?
Satish Rao was a project manager with Douglas Cardinal for 30 years. He is currently Senior Associate with Torti Gallas and Partners, a housing/urban design firm in the Washington, DC area.
What is process?
A clear “process” answers these questions:
What is the goal?
What is the process for reaching the goal?
What is the sequence of decision-making?
What tasks need to be accomplished, and when?
What information needs to be shared at each milestone?
What information is needed for proceeding to the next step?
Who has responsibility for making each decision?
How are unexpected events handled?
Consultant Management Plan
To create a sound Consultant Management Plan:
1.Set clear goals–measurable, consistent with architect’s and client’s g
oals.
2.List scope–detailed, especially for design phases.
3.Identify deliverables–specify quality, quantities, level of detail desired.
4.Describe the process–written and graphic descriptions of process and schedule.
5.Check the contract–consistent with Owner Agreement, with detailed descriptions of program and engineering scope.
6.Check the fees–adequate for the services expected?
7.Develop a strategy for information exchange–set milestones for exchanging information, decisions. Develop a communications system.
8.Create a work plan–include client’s and consultants’ tasks in detail, and a strategy for addressing challenges.
9.Develop a monitoring mechanism–prepare a plan for anticipating, identifying, and correcting deviations from work plan (no less than biweekly).
10.Make consultants team members–include them in your team meetings; share information freely.