Putting BIM in perspective
Building Information Modelling, or BIM, is often portrayed as the saviour of the Architecture, Engineering and Construction (AEC) industry. On the whole, BIM can be seen as a positive direction for the industry, attempting to address the inefficiencies and waste in the industry. Yet at the same time, numerous fractions of the BIM movement are threatening to hinder its cause.
Go into any architectural office in the world today and you’ll find someone ‘doing BIM’. Typically with a technical background, they are known as evangelists, preaching the word of BIM. Listen to them closely and you’ll discover common threads in their arguments – All projects should use BIM; People in my office don’t understand BIM; BIM should be mandated by governments; and, Software X is better than software Y. While I have no doubt that many of these people’s hearts are in the right place, I can’t help but think we are approaching the problem of BIM adoption all wrong. Let’s dissect each issue first, before discussing a different way to look at things.
Issue 1: All projects should use BIM
BIM is touted as being more effective at coordination, communication and collaboration. Chances are, it probably is. However, this doesn’t mean BIM should be imposed onto every project from day dot. Its implementation into the project needs to be carefully timed and curated.
Despite what software vendors may claim, BIM is slow compared to CAD. This shouldn’t come as a surprise. Technology was supposed to save us time and make our lives easier. We can confidently say neither of these things have happened. Many technological innovations, from email to instant messengers to productivity apps, promise to make our lives faster, easier and more efficient. Yet we are as busy as ever.
Sure, if you are designing conventional buildings with repeatable elements, BIM will mostly likely save you time. But most architects design custom buildings that a one-offs. Even if an architect specialises in a single typology, say housing, chances are each house will be substantially different from the next. And herein lies the problem. Since no two projects are ever the same, it is not possible to simply ‘arrive’ at an architectural outcome. Each brief will be different, each site different and each budget different. An architect is obliged to go through the schematic design process or they would be doing a disservice to their client. Keeping in mind that the design process is an iterative process of ideation, testing, and refining.
Traditional linear thinking vs Feedback Loop, Randy Deutch 2017 1
During the design exploration process, BIM can actually be a hindrance rather than a benefit. There are other design methodologies which are more fluid, agile and informative, and therefore better equipped to undertake the design exploration process. Many of these process which we’ll discuss later, do not fall into the traditional definition of BIM and are therefore often considered second-class citizens in the eyes of BIM evangelists. This prejudice is mainly premised on the argument of interoperability – If the project is going to move into BIM anyway, why not just start the project in BIM from the beginning? At face value this seems like a logical argument but it couldn’t be further from the truth.
The AEC industry needs to learn from the software industry. Rather than embarking of months and months of development using ‘text book’ methodologies, software developers create quick proof-of-concepts to test viability. Known as ‘sprints’, they are focused developments of the project which tries something, gets fast feedback, and then rapidly inspects and adapts.2
Sprint Cycle, Nate Miller, Proving Ground 3
Yet in architecture, there are many BIM managers who want to mandate BIM from day dot. Staff are given Revit templates with countless filters, view templates and office standards to follow. The logic behind this is that of doing it once and doing it right. But this is misguided. Designs are going to change. And not in an incremental, progressive way. They are going to change radically. Why? Because buildings are complex and the problem solving needs to be broken down into manageable chunks, starting with the macro and working to the micro. BIM, which relies on progressive refinement, is therefore at odds with this design methodology.
Like it or not, many architectural commissions are derived from architectural competitions. Whether prescribed by fair competition laws, governmental requirements, or clients simply seeking ideas, architects are required to produce resolved designs in a relatively short period of time. Design competitions as a method of ideation is a contentious issue and its appropriateness is beyond the scope of this article. However, what is certain, is that the probability of winning a competition is low. Even the most successful practices only have a success rate of say one in four. Given the volatility of the design process and the low probability of gaining the commission, should BIM be adopted at the beginning of a design competition? Personally, I don’t have a problem with this except for one caveat – Don’t be surprised if the quality of the BIM model is not what you expect. If you win, fantastic. But due to the tight timeframe and the continuous design changes, the BIM model is probably so poorly constructed that most BIM managers will insist on rebuilding it from scratch.
Tool vs Toolbox, Chris Mackey 4
Wouldn’t it be better to use the best tool for the job, settle on a design trajectory and then embark on your BIM journey? Rather than resenting this as an inefficient design process, BIM managers must embrace a BIM ecosystem. If all you have is a hammer, everything is going to look like a nail.5 But actually what we really need is a screwdriver, or better yet, a whole toolbox. Trying to control the design exploration process is futile. As Randy Deutch points out, “Architecture is a complex undertaking requiring the input of many individuals with varying interests, backgrounds, and expertise. This has not changed – and will not change. What is changing is the way these individuals are working, communicating, and collaborating.”6 Architects and BIM Managers must be flexible in BIM deployment and adopt interoperability as a process in order to ensure continuity of design intelligence. The principle here is simple – Don’t force BIM on a project until it is ready.
Issue 2: People in my office don’t understand BIM
One only needs to look at the high staff turnover in the design technology field to see that the industry has a problem when it comes to understanding BIM. Time and time again, I see talented and motivated staff become demotivated and disillusioned with the way design technology is being adopted in their office. With the shared belief in technology as an enabler of good design, they come across barrier after barrier to digital nirvana. It might be that there is no BIM deliverable in the contract. Or it might be that senior staff members only see them as a BIM monkey, someone who simply models what they have designed. Or it might be that they were hired as a BIM manager when actually they are doing a Model Managers role. Or it might be that is doesn’t matter how hard they beat the BIM drum, people simply don’t want to change from their old ways of working. Whatever the barrier, the end result is the same – high turnover of design technology staff, which is turn fuels the demand for design technology staff.
“If you want to gather honey, don’t kick over the beehive”
Over time, the continual repetition of this process leads to a breakdown in trust between management and design technology leaders. Both parties feel they are not being listened to, which furthers resentment and marginalises the design technology professions into the problem child of architectural design. Design technology staff need to be clever if they are to have any hope in changing this dynamic and winning people to their way of thinking. After all, as Dale Carnegie eloquently sums up, “If you want to gather honey, don’t kick over the beehive.”7 must understand that whether you are a BIM Manager, Computational Designer, Chief Digital Officer, or any other digital design professional, the AEC industry is still coming to terms with this disruptive technology. Organisations have been slow or resistant to seeing these digital design roles in a position of leadership. Becoming frustrated only furthers this perception and undermines the value that these professionals bring to the company.
Super User, Randy Deutch8
BIM evangelists like to stand on their soapbox and preach the benefits of BIM. The argument is generally that BIM is faster, more efficient and cheaper, which may be true. However, this line of argument is not necessarily the best way to educate architects on the benefits of BIM and champion its adoption. Quite simply, architects are not efficient beings. Much to the frustration of other AEC professions, architects continually change their mind and often refuse to commit to a design decision until the last possible moment. At least for the time being, I can’t see this working model changing. Ideas take time to emerge and one cannot predict when that will happen. One only needs to witness the design process during a design competition to understand this. Rightly or wrongly, architects are focused on the design outcome above anything else. BIM therefore needs to be presented in these terms in order to convince the other party of its value.
Rather than promoting BIM efficiency, it is far better to promote design quality. By demonstrating that BIM will deliver a better building, you will be more likely to influence change. Most presentations and articles on the benefit of BIM fails to acknowledge this. Again rightly or wrongly, due to the adversarial nature of the construction industry, most architects are not interested in making the contractor’s role easier by providing a fully detailed LOD 500 BIM model. If however, you can demonstrate that the quality of space is significantly improved due to improved sunlight access or minimised overshadowing, than you are beginning to speak in their language. Rather than emphasising differences in methodology, find common ground in your shared aim to create better buildings. There are many faces to BIM and we must understand our audience if we are to convince them.
Another common barrier which causes much frustration is the level of detail in the BIM model. Many architects use BIM simply for design authoring even if they have no intention of using the model for any higher purpose such as Facility Management (FM). Again, time and time again, I see over-zealous BIM managers embedding enormous amounts of detail into the BIM model. This seems more like an exercise of doing it because it can be done, rather than what the project requires. This takes us back to an earlier point on the role of technology in the profession. BIM is not necessarily saving us time, but it is making us more productive. But here is the catch – that additional productivity is only beneficial in a commercial sense if you are being paid for it.
A BIM manager will typically only get involved in a project long after the Client-Architect Agreement has been executed. This means that many of the project deliverables are already defined before the BIM model is even commenced. While it might be satisfying to build a fully parametric, fabrication level Revit family, BIM managers need to show restraint and business acumen. The rational seems to be that by demonstrating what BIM can do, one will be more likely to influence the scope of work for the next project. However, being over-zealous and covertly taking things into your own hands only further divides design technology professions from project directors and managers. Seek to understand the commercial realities of projects and see things from the other person’s point of view.
Architects are interested in buildings. They are not necessarily interested in BIM models. For many, BIM is a means to an end in getting the building built. How often do you hear architectural journals talking about the quality of the BIM model for an award winning design? Never. It is the final built work, the resolution of many competing interests, that ultimately counts. This must be keep in the back of the mind at all times.
If a client or manager can’t be convinced of the benefits of producing a fully resolved BIM model, change tact and demonstrate how you can harness the power of the BIM model. Extract the data that you do have, this could be elementary information like room distribution, areas and functions. Synthesise this data longitudinally across multiple projects to unearth patterns in how your company designs buildings. For example: Are residential buildings orientated in a certain way to achieve solar access compliance?; What were the significant changes in the model and can these be visualised in a decision tree to understand how we design? These sorts of questions are selfishly internally focused but they begin to open up the discussion of the value of data without imposing it onto a project. Demonstrate usefulness without exceeding your scope of work and blowing your budget. And above all, see things from the other person’s point of view.
Issue 3: BIM should be mandated
Report after report10 has demonstrated the wastefulness within the AEC industry. Moreover, the AEC industry is notoriously slow at adopting new technologies. By mandating BIM, many seek common ground on which to collaborate and share BIM information. While this is an admirable endeavour, it opens up a whole can of worms which in my opinion is not positive for the BIM movement.
Before BIM, there was CAD. In fact, CAD is still around today. For decades, CAD managers debated and argued over standards including layer naming and line weight conventions. The aim was to achieve uniformity and consistency across the profession so that if someone shared a *dwg file, you could easily XREF it in, understand the layer system, and turn on/off layers as required to minimise re-work. Yet for all the discussion that took place, every architectural office seemed to adopt their own standard. It was a complete and utter failure. Not only could we not decide on graphic standards, we couldn’t decide on methodology. Some people preferred to have each floor plan of a building in a separate file. China and Europe seemed to prefer all floor plans in one file and use blocks for repetitive elements. Some annotated in ‘model’ space, others in ‘paper’ space. While we had standards, we were far from having standardisation.
The discussions around mandating BIM appear to be heading down the same familiar path, focusing on industry standards and protocols. For example, we have BS-1192 which aims to provide:
…a “best-practice” method for the development, organization and management of production information for the construction industry, using a disciplined process for collaboration and a specified naming policy. It provides the template for common naming conventions and approaches to collaborative working for use in architecture, engineering and construction. It also facilitates efficient data use in facilities management.12
Together with PAS 1192-2, which specifies the requirements for achieving BIM Level 2, we are inundated with endless workflow diagrams and definitions. On top of this we have Industry Foundation Class (IFC) and Construction Operations Building information exchange (COBie) as our common data platforms. Clearly these initiatives are a response to software not seamlessly and harmoniously working together within the BIM ecosystem. But is this really the best way forward?
The Harvard Business Review has written extensively about how tight controls strangles innovation.13 The inherent uncertainty of the innovation process makes side-tracks or unexpected turns inevitable. Even if standards are guidelines, over time, they often become enshrined through secondary legislation. NSW’s SEPP65 solar access requirements are a prime example of this. Let’s not resort to the lowest common dominator by adhering to strict protocols and instead focus on where we want to end up – the creation of better buildings, communities and the environment through architecture. For example, rather than trying to get consensus on the naming system of elements, why not create software which automates the process. With the release of Revit, there is now no longer a debate over layer naming conventions. If an element is a wall, it is categories as a wall. There is no need for a debate over what the layer should be called – ‘A-Wall’ or ‘A-WALL’. The software removed this from the equation. Why can’t this be done for file naming or element naming? Focusing on naming conventions is archaic and pointless. Newforma for examples offers advanced searching and indexing capabilities. It no longer matters if someone didn’t save the email attachment separately onto the office server or didn’t name the word document as per office standards. Yes it might look messy if you use Windows Explorer, but that is old technology and not the way of the future. Indeed, Autodesk’s Project Quantum, which is slated to be cloud-based and platform agnostic, will surely address these issues.
While loosening formal controls, BIM managers should tighten interpersonal connections between innovation efforts and the rest of the business. Undervaluing and underinvesting in the human side of innovation is a common mistake. Emphasising tasks over relationships creates missed opportunities to enhance the team chemistry necessary to turn undeveloped concepts into useful innovations. Next time, rather that set out all the standards and protocols that must be followed, throw down a challenge and ask the team, what is the best way we can design and procure this building? Not only will this motive the team but you may actually end up with a better building and a more cohesive team.
Issue 4: Software X is better than software Y
Both Revit and ArchiCAD are BIM authoring softwares. Yet rather than seeing this as a positive from self-proclaimed software evangelists, there are frequent quips that Revit is better than ArchiCAD (or vice versa). Similarly, there are often degrading comments made about the inferiority of Rhino as it isn’t considered proper BIM software. These types of statements are prolific, detrimental to the AEC industry and must stop. We must acknowledge that no software can do everything and that each has their limitations. Practices such as FRONT Inc, DesignToProduction, Proving Ground and AR-MA, have produce fabrication level models of incredibly complex designs using ‘non-BIM’ software. Does this undermine the outcome? Absolutely not, and in fact, such an outcome probably wasn’t even possible with conventional BIM authoring software.
A lot can be learnt from the soda industry and the so called soda wars. Coca-Cola and Pepsi have been long-time rivals. However more recently they have discovered that their biggest rival is not each other but tap water. Indeed, in 2010, Coca-Cola drew enormous public criticism for their ‘Cap the Tap’ program. In sum, it instructed restaurant employees on how to discourage patrons from drinking water, and then steer them toward revenue-generating beverages.14
Software evangelists need to stop seeing their competitor as rivals. To follow the same analogy, Autodesk’s biggest rival is not Bentley nor Nemetschek, but AEC professionals that don’t embrace technology at all. Despite this and to a huge social media backlash15, Autodesk recently decided to ban certain ‘competitor’ software from exhibiting at Autodesk University. One cannot help but see this as a disingenuous and hypocritical move, further siloing Autodesk from the greater BIM community. In stark contrast, the RTC conference, which is historically Revit centric, partnered with Archicon, an ArchiCAD event.16 The conference organisers recognised that the problems the industry are facing are bigger than just a single software platform. In even further recognition of this community attitude, this year they changed their name to ‘BILT’ to reflect the broader scope of topics and software.
We live in a BIM ecosystem – Criticising and complaining about other software only undermines our industry and does more harm than good. Rather than critiquing an approach based on the software used, we should be critiquing the output based on the methodology and the embedded design intelligence. It is far better to work towards a common goal than taking cheap shots at a competitor’s software preference. We must learn to stop prejudicing software – After all, it may have something to offer which yours can’t.
Bill Allen of EvolveLab recently gave a presentation at Autodesk University titled, ‘The future of BIM will not be BIM: And it is coming faster than you think’.18 In the presentation, Allen predicts that rather than BIM, we are going to see Building Information Optimisation. Not only will we see ubiquitous computational design, we will also see machine learning and artificial intelligence infiltrating architectural design. To many this may seem a distant reality. But technology is changing the profession at a much faster pace than people think.
Humans tend to think in terms they can relate to and we base our expectations on our experience. We live in linear time and space, yet technology is fundamentally different, growing exponentially.19 As Diamandis explains:
…if I were to take 30 linear steps, it would be one, two, three, four, five. After 30 linear steps I’d end up 30 paces or 30 meters away and all of us could pretty much point to where 30 paces away would be. But if I said to you take 30 exponential steps, one, two, four, eight, sixteen, thirty-two and said where would you end up? Very few people would say a billion meters away, which is twenty-six times around the planet. 20
While BIM may be the topic du jour, technology is changing fast – faster than we can comprehend. It is important that we put BIM in perspective and not lost sight of the big picture – how do we create better buildings, communities and the environment through architecture. After all, isn’t this why we got into the industry?
1 Deutsch, R. (2017). Convergence: The Redesign of Design. John Wiley & Sons Ltd, Chichester, p.28.
2 Miller, N. (2015). What Building Teams Can Learn from Scrum.
3 Miller, N. (2017). 4 Tips for Getting Value out of Software Customization.
4 Mackey, C. (2015). Open Geo Data and Performance Workshop. ACADIA, Cincinnati.
5 Maslow, A. (1966). The Psychology of Science. Harper & Row, New York.
6 Deutsch, R. (2017). Convergence: The Redesign of Design. John Wiley & Sons Ltd, Chichester, p.10.
7 Carnegie, D. (1936). ‘If You Want to Gather Honey, Don’t Kick Over the Beehive’. In How to Win Friends and Influence People. Sydney: Harper Collins, pp.31-46.
8 Deutsch, R. (2017). Convergence: The Redesign of Design. John Wiley & Sons Ltd, Chichester, p.104.
9 Deutsch, R. (2017). Convergence: The Redesign of Design. John Wiley & Sons Ltd, Chichester, p.156.
10 Latham, M. (1994). Constructing the Team. HMSO.
11 Penwill, R. CAD standards.
12 BIMe Initiative. BS 1192. BIM Dictionary.
13 Kanter, R. (2013). ‘Innovation: The Classic Traps’. In HBR’s 10 Must Reads on Innovation. Harvard Business Review Press, Boston, pp.101-124.
14 Indermill, L. (2014). Drink Marketers’ Great Challenge: Competing Against Water, Without Badmouthing It.
15 Young, B. (2017). Bluebeam vs. Autodesk: Why Can’t We Get Along?
16 Langella, S. (2016). ARCHICON and RTCAUS 2016.
17 Introducing BILT.
18 Allen, B. (2016). The Future of BIM will not be BIM: And it is coming faster than you think.
19 Huffpost. (2016). Exponential Thinking and why it will Change the World.
20 Diamandis, P. The Difference Between Linear and Exponential Thinking.