This is the author’s second post in a five-part series covering Autodesk workshops that explored the relationship between emergent digital collaboration technologies and the challenges in project delivery. The six workshops were held worldwide over 18 months in 2018 and 2019.
Data-driven project delivery models could dramatically improve the design, construction, and operation of the built environment, but we haven't achieved that idealized state. In this article, I’ll examine the key issues and perceived inhibitors to change in the AECO (architecture, engineering, construction, and operations) sectors.
At each of the Autodesk project delivery workshops I described in my previous post, the following statement was the central provocation: Enhanced information exchange in AEC improves project delivery and therefore project outcomes.
Implicit in this declaration was the idea that information flowing across the various constituent boundaries was appropriate, useful, compatible, and current—in short, trustable. Participants across the supply chain agreed that the challenges here were a combination of impediments that fell into one of three categories: technical, procedural, and cultural.
Technical Challenges
The first general theme was related to the technical challenges of data exchange, the “Tower of Babel” problem. The wide array of software systems and platforms deployed by the various AEC players creates a sizable structural impediment to information flow. These systems may produce data from different operating systems (PC versus Mac), be based on different workflows and outputs (say, structural engineering analysis software versus fabrication software), or manage versions badly, failing to integrate the progress of the work in concert. The resulting cacophony of data generated by myriad software products for a single project can be, to put it mildly, deafening.
The most profound technical challenge lies in the space created by the tradition of AEC deliverables as 2D output (think drawings) and the potential of 3D information. Many firms work in 3D modeling platforms—and often in BIM—but few, if any, standards for exchange of that 3D information exist, particularly if firms work on disparate platforms. This complicated issue isn’t just technical, although the creation, transmission, and consumption of such data is first a technological compatibility/interoperability problem. And since the days of a single, teamwide authoring platform, such as AutoCAD, are long gone, data compatibility will need more than just a global theory of interoperability that governs every byte.
Procedural Challenges
The technical compatibility problems outlined above may, in fact, be a symptom of larger procedural challenges that face an increasingly digitized AEC supply chain. Different software platforms, algorithms, data types and formats, and workflows are as much a product of software engineering design as they are manifestations of different and incompatible disciplinary standards battling one another. The canonical example of this challenge is the standard trope that “the architect’s model isn’t suitable for construction.”
By tradition, contract, or legal standard, architects and engineers are not charged with creating “construction-ready” information but rather with what is called in legal parlance “design intent deliverables,” which describe the end-state of construction prior to the instantiation of the contractor’s knowledge. (Construction strategy, means and methods, material selections, and specific detailing often manifest in shop drawings.) It’s not the intent here to argue the efficacy of this particular structural process challenge, but rather to suggest that as digital tools are built—bespoke—for different players in the AEC supply chain, these tools will, absent larger theories of new interactions and standards, be, by definition, incompatible.
Our workshop participants saw procedural inhibitors to smooth information flow in many forms: getting the wrong data at the wrong time; communication lags as information is translated and transmitted; competing—or missing—data and exchange standards; and even confusion about the meaning and implementation of LOD (level of detail). But at the heart of these issues is a fundamental characteristic of most AEC delivery teams comprising owners, designers, and builders: incompatible business models. Each player in the chain is optimizing for a different objective and, when linked together, the incompatible morass of competing expectations and goals makes data challenges even worse.
A brief exploration of a traditional design-bid-build project illuminates this challenge. The client wants to get the maximum scope and quality of work while paying the lowest possible price. Designers, without any help from a builder who won’t appear on the project until after 80% of their work is complete, are trying to create a building that meets these client objectives while protecting their small, fixed fee. Builders consume technical documents produced without their input and then are asked to assume enormous risk, essentially promising that the resulting building can be built within owner’s and designer’s constraints—about which they had no insight nor input. It’s no wonder that everyone has their own standards, protocols, data requirements, and, worst of all, expectations for the work of others.
Cultural Challenges
Our workshop participants suggested that there was a third category of inhibitors to streamlined information exchange: culture. Within a project team, often formed for the one-off job, there are disparate levels of training, knowledge, and skills in the use of technology, exacerbated by the range of digital prowess across generations; baby boomers know how a building goes together, but are far less knowledgeable about the technology to produce the information necessary to build it. Their millennial staff are skilled with digital tools but have little idea about what exactly they’re modeling with that software.
At a higher level, it is difficult to find the critical leadership—at the firm, project, and industry levels—to attack these issues. When projects operate without even basic consensus about the goals of the players, varying business objectives stand in the way of progress. A gap in leadership only lessens the possibility of working out any of these technical, procedural, or cultural issues.
Having systematically detailed the inhibitors to progress, I’ll examine the underlying causes inhibiting the improvement of digital information flow in project delivery in my next article and begin to develop an argument for how to solve these daunting problems.
