Architects, Builders, and the Failed Promise of Deep Collaboration

Featured in:

52: Instruments of Service

Roundtable

Despite remarkable advancements in technology, the construction documents that architects produce for their clients to communicate a building design and its intent—what are called CD sets—have not substantially changed since the mid-1970s. This is true even as building information modeling (BIM) software has saturated the market, a shift toward digital 3D modeling that has vastly expanded architects’ ability to incorporate greater and greater sums of information directly into their designs.¹ Even with the coming era of machine learning and AI, the traditional 2D format of CD sets will likely remain the industry standard for the foreseeable future.

Why? After all, contractors and sometimes clients want and need 3D models of buildings that can directly inform how buildings should be constructed. But providing them carries a high level of risk for architects, and as a result their attorneys and professional liability insurers often caution against it, despite the potential overall benefits for the project and all parties involved. If, for example, an architect provides specific instructions for how a building should be constructed—in the form of a 3D model—responsibility for mistakes in the construction of the building suddenly becomes much more difficult to assign.

To probe this conundrum, Gregg Garmisa, principal and general counsel at Studio Gang, spoke with Phil Bernstein, deputy dean at the Yale School of Architecture and former vice president at Autodesk; John Cerone, principal and director of virtual design and construction at SHoP Architects; and Alexis McGuffin, national director of digital delivery at Suffolk Construction.

Gregg Garmisa

For hundreds of years, architects conveyed their design intent on paper. With the increased popularity of computer-aided design (CAD) starting in the mid-1970s, architects took a first great leap forward digitally, but the output—the instruments of service—remained the same. In the mid-2000s, 3D modeling was introduced but our output remains 2D. So Phil, since you were literally at the forefront of this innovation—leading the team at Autodesk that bought Revit—and since you’ve written and lectured on this topic exhaustively, can you summarize for us what actually happened, and why the disconnect remains?

Phil Bernstein

The original thesis was that BIM would create an opportunity for deep collaboration between the primary constituents of the delivery process. But at the same time, we developed a proposal about structural changes in the delivery system itself since there was no value proposition for designers to provide higher quality information to builders, given the constraints of risk and return. The whole theory of IPD [Integrated Project Delivery] or alternative collaboration was evolving in parallel with the theory of BIM.²

John Cerone

I think that way of working is achievable and I think we’ve identified that technology isn’t necessarily a barrier. But I am curious, Phil, have we revised the theory?

Phil

I don’t think we’ve revised the theory. And let me also say for the historical record, there was an ex parte phenomenon that occurred at the same time this discussion was starting to emerge. The Construction Users Roundtable convened a group of architects, contractors, and owners led by the General Services Administration to answer the following question: “Why are architecture and engineering working drawings so bad?”

But they lost control of the dialogue because as the discussion progressed, it became apparent that the problem was not the quality of documents per se;that was just a symptom of a larger problem, which was lack of deep collaboration between the players in the process. The result was a white paper about collaboration in the building industry that declared that owners have to take responsibility for changing the nature of the use of technology and the collaborative infrastructure.

But Integrated Project Delivery, the proposed solution, didn’t work because the building industry is highly resistant to change and people don’t trust each other. And in order to get to these collaborative models and new methods of exchanging judgment, which is the true purpose of an instrument of service, you need trust and a willingness to innovate—two things that are in very low supply in our industry.

Gregg

Well, not all architects are afraid to innovate; I can think of a few who are willing to challenge conventions. But as long as architects are going to be at risk for some of the potential outputs of the deep collaboration over which they have no control—and when they’re already dealing with razor-thin margins—why would they accept that risk? We need to address liability-related issues, and that goes beyond trust, right?

Phil

I agree, but I think you could either solve that with some new risk construct or money. It’s pretty straightforward as a risk-return calculation. As an architect, I have zero financial incentive to do anything more than the standard of care establishes, because there’s no money in it. I’ll take on more risk and give my stuff to Alexis, but I want to get paid for it.

Gregg

Alexis, say the architect has built this elaborate model, and yet when you ask them for a copy of it, they basically say, “No, thank you.” Or they say something like, “We’ll give you our CD set, but if you want the model, you’ve got to sign every conceivable waiver known to humankind.” What does the contractor do in that situation?

Alexis McGuffin

Most builders agree we must leverage building information models to plan and manage the building construction process to increase predictability, efficiency, and quality on projects. The buildings of today are too complex, and the schedules too compressed, to coordinate an entire construction project without an accurate virtual model. The bigger question is who should create, own, and manage the models shared across multiple project stakeholders to add the most value?

One option is for clients to require architects and engineers to share their models with the rest of the team, including the general contractor. However, most clients do not have the capabilities to open the files, let alone review them. I often compare this scenario to a client who purchases a box with three gold bars inside, but doesn’t have the key to open the box and look inside. The client receives the “box” (or model) from the architect, and then hands the box to the builder who opens the box to look inside and says, “There were supposed to be three bars of gold in here, but there’s only one bar.” The client wants to look inside the box on their own but can’t, so they rely on what the builder is telling them. The client goes back to the architect and says, “The builder told me you only put one bar of gold in this box, not three bars like you promised.” Then the finger-pointing begins.

The reality is most clients don’t fully understand what they purchased with the model, and they do not understand the difference between levels of development and architectural models versus the construction models. Clients are put in a very difficult position as the middleman between the architects and builders who rely on these models to fulfill their responsibilities.

Today, most construction management firms sign BIM waivers, because the models are so important to our role on the project, and then we pass along the risk to the trades, who are contractually required to model and coordinate buildings in 3D and to leverage the design models.³ Unfortunately, you cannot always trust the design models because mistakes are often made, so we frequently hire large in-house virtual design and construction teams to manage this process and the models. We’ve created an entire department to help us manage this.

Phil

Alexis, I have a question about that: Somebody’s paying for the repeated representation translation, right?

Alexis

Right.

Phil

You can’t trust the model because you signed a piece of paper? Or you can’t trust the model because we told you that you can’t trust it: It’s not precise enough, or it doesn’t have enough embodied information, or it includes a lot of mistakes?

Alexis

All of the above.

Phil

I’m just trying to get to the underlying reasoning here because the model that an architect generates to resolve the design is a completely different thing than what you, as the builder, need to build the building.

Alexis

That’s correct. That is the typical process in our industry today, but at Suffolk we discard the design models altogether. We don’t use them at all. Our teams actually rebuild models from the more accurate 2D documents, which allows us to get closer to “virtual construction” versus 3D coordination. We know that building our models from the CD set in a 3D virtual environment can reduce our risk significantly, as opposed to simply using the design models as backgrounds. While this approach is not easy, we’re confident it is the most effective way for us to mitigate our risk. We simply could no longer accept the risk associated with building from the design models or architect drawings alone. We needed a better way.

John

Just out of curiosity, Phil, when you say the model that architects provide is very different than the thing that the contractor needs to build it, why is it so different, or why does it have to be so different?

Phil

Architects provide a drawing set organized by the team org chart: architecture, structure, mechanical, security, etc. Builders build buildings by trades. So there’s a fundamental mismatch in the information that we generate and the way we organize it and the way contractors need to consume it. That’s issue number one.

Issue number two is the level of precision of a construction model, which has to have all sorts of process stuff imbued in it which is not the architect’s responsibility. I don’t need to draw a column in complete detail. I draw a column from the underside of the roof deck to the footer, and if it’s a 20-story building, that’s all I need to draw and that’s all I get paid to draw. Alexis needs 20 columns and 20 connectors and 20 welds and 20 sets of bolts, and that’s not my job. Right? It’s not the structural engineer’s job, either.

John

I agree with that. I guess my question is how far removed does it need to be? Currently, drawings are the architect’s contractual instruments of service and they’re the deliverables we’re required to do, but is there a way to realign for what’s actually useful? I’m not suggesting that we, as architects, take on responsibility for detailing all this stuff explicitly in 3D, but our models—which describe the three-dimensional design composition and datums—can be useful as the driving wireframe of systems. In this case, some of our deliverables are even reduced.

The fact that 2D is required is a fundamental issue. We design in 3D. Alexis needs 3D. I understand the industry resistance, but if we’re just talking about pure efficiency and process, it’s a three-dimensional environment where all the stakeholders can look in and see the real-time status of the project. If I’d like input from someone who knows how to put this together, they can provide that input in context.

We don’t operate that way now, but there have been scopes of projects where we’ve seen it work . . . and we can’t “unknow” that. These scopes involve delivering a model rather than a traditional drawing set. I almost hesitate to bring up examples of the projects because they’ve been precedents that were set under extreme circumstances of time and budget. We traded models with structural engineers, overlaid our design models on theirs, and sent it to the detailer. They made what was in the model. We know it can work.

I think there’s a thesis of how this could work where you’ve got a wireframe model that dynamically hosts collections of subassemblies. It’s a persistent model environment that has lightweight geometry that describes where things should be and then can host those subset systems; if you collect enough of those subset systems, you have the building.

You have to be able to trust who’s watching, because there will be intermittent failures. Everyone can see where things are clashing and where they aren’t. That’s just not our usual operating model, at scale, but I think it can be.

Clients aren’t trained in three-dimensional modeling, CAD, design, or construction. I don’t think they understand the relationship of the process that we use to design and to execute—the nuances of what drives what—so it is opaque, and it’s hard to trust something when it’s opaque. Are designers being difficult because they’re not making decisions? Are contractors being too pushy because they say this can’t be done? I think it’s a good thing for clients to be involved—to have a view or a window into the project as a three-dimensional construct and to watch the progression. There’s no precedent for that right now. . . . Clients get plans, they get renderings.

Gregg

Let’s turn our attention to possible frameworks out of the current predicament that we collectively confront. What directions might the architecture profession take? We’re all well aware that the increased use of 3D modeling and even the use of AI threaten to undermine and erode the relevance of architects. So how do we stave off—or fight back against—that looming cloud over the profession? And at the same time, what proactive and positive moves can we make? How do we develop new modes of practice that benefit all the players: the design profession, the contractors, clients, society, and the planet?

Alexis

I can tell you how Suffolk has responded. We are builders at heart: construction management services are our core business. Having said that, we realized we could offer additional value throughout the entire building life cycle, including during the design phase. So we hired our own architectural expertise. Suffolk Design allows us to do the things that we think architects don’t want to do, including constructability reviews, completing the CD set, and design management. This allows the architects to focus on creating great design and providing us the information we need to build the building in an efficient manner. The goal of Suffolk Design is to help fill the gaps in the documents that are typically provided by architects so we can build the building safer, faster, and cheaper. Like I mentioned earlier, we needed a solution to this industry challenge, so we created one ourselves. We like to think of Suffolk Design as the intersection of design and construction data that leverages the power of AI, data, and technologies.

Gregg

To a certain extent, that’s taking a big chunk out of the architect’s current professional responsibilities and fees. But I hear where you’re coming from. John, any thoughts from your perspective in terms of how you’re approaching this or how you think the profession should approach it?

John

My point of view is that it is both optimistic and cynical. I think that both the architecture/engineering/construction industry and the built environment are becoming more industrialized: there’s less patience for creative exploration. Timelines are tighter, and there’s more demand for accountability of results, not only in the design of the built environment, but just in general. The world is increasingly impatient as things become more automated . . . people want results quickly. Industrialized construction seems to be inevitable. The UK, for example, is putting a lot of attention on off-site prefabrication of panelized systems and modular construction.

I think the pessimistic view is that applying industrial process to design results in a higher level of standardization and a decrease in variation and choice. We’re going to make things at A, B, and C length, and you can make whatever you want—as long as it’s the configuration of those parts. People are increasingly talking about “design kits of parts.” That’s a sad future where we’ll make decontextualized widgets, and you’ll get what you get by fitting them together because that’s just the way that we can process industrialized things.

A foundational thesis of SHoP is that you start with design and convert design into industrialized processes. Design can be informed by means of production, and we manufacture bespoke “capital-A” architecture.

I think the optimistic side of this concept is that we will have better performing systems. These can be overlaid on an agile design framework. The idea is we’re going to design the best thing, we’re going to work with contractors, and we’re going to all be in a room together. All the knives will be down and all the constraints we typically have to worry about—that aren’t about design, execution, and operation—will loosen. I think we can define a way of designing and executing that would set a standard, and it’s a prototype that could not be ignored. But that opportunity is . . . well, I’ve not seen that happen.

Gregg

I love the idea, John. I think it may give some professional liability insurers a bit of indigestion, but that’s okay. They don’t need to be the ones who drive the business decisions. Phil?

Phil

The pessimistic view is that contractors—failing to get what they needed from architects—just started building the capabilities themselves.

Optimistically, there’s an opportunity to create a new kind of process where a construction model and a design model are developed in parallel. That would mean the designers have to tolerate a number of questions from their builder collaborators about what they need to get their model happening, and the contractor has to tolerate a certain amount of ambiguity while the designers are working on a problem. At the end of the construction documents and procurement process, you’d actually have two models: the output of the design model would be permit drawings and the contractor would move forward with a resolved construction model that’s been developed in concert. But it still requires the proper modulation of risk and competition. . .

Gregg

Right. We have to solve that problem and a fistful of others, along with a couple of issues left in the academy. But, by and large, I think we’ve solved everything else here! [Laughter]