Back in the 2000s, moving from 2D drafting to 3D modeling felt like a genuine superpower. Back then, the value proposition was simple. A 3D model helped people understand a design better. It reduced drawing errors. It made coordination easier. It was visual, practical, and immediately useful. It solved real, immediate problems on the drawing board. We used it because it actually helped us design and build better.
Then things started to change
As BIM became more established, the industry developed a growing collection of frameworks, standards, classifications, and terminologies. We got BIM dimensions. We got Levels of Development (LOD). We got BIM maturity levels. We got execution plans, information delivery specifications, and countless acronyms. Instead of clarifying things, these sophisticated terminologies introduced a massive wave of confusion.
None of these concepts are inherently bad. Most of them were created with good intentions. The goal was often to improve consistency, clarify expectations, and help organizations scale BIM adoption.
But somewhere along the way, something interesting happened. The conversation slowly shifted. Instead of asking “how can we use this tool to solve a design issue?” and more about a existential crisis: “What exactly are we supposed to deliver to satisfy this specific acronym?”. Instead of focusing on outcomes, many discussions became focused on definitions. The focus quietly drifted from the practical value of the model to checking off boxes on a compliance spreadsheet. For many practitioners, BIM has become something they need to satisfy rather than something that helps them work.
Then came BIM mandates.
Governments, owners, and organizations around the world started requiring BIM on projects. Again, the intention was understandable. Better collaboration, better information management, and better project outcomes are difficult goals to argue against.
But mandates introduced a new challenge. Many teams were asked to implement BIM before they fully understood what BIM meant in practice. As a result, projects often found themselves in a strange situation. Teams were required to “do BIM,” yet there was no universal agreement on what success actually looked like. And because BIM became strongly associated with 3D modeling software, a common perception emerged: If it’s not 3D, it’s not BIM. That perception still exists today. Yet many project activities that support information management, collaboration, coordination, and decision-making do not necessarily require a detailed 3D model.
In some projects, the model creates tremendous value. In others, the model becomes an expensive obligation. There are projects where teams build highly detailed models because the contract requires it, even though very few stakeholders actually use the information. There are also projects where simple workflows, spreadsheets, drawings, and meetings solve problems more effectively than an increasingly sophisticated model.
This raises an uncomfortable question: Are we using BIM because it helps, or because we are expected to?
To be clear, I’m not arguing against BIM. Many of the industry’s most significant improvements have been made possible through BIM-related technologies and workflows. The question is whether the industry confuses the tools, standards, and deliverables with the original purpose.
What do you think?
- Has BIM become more useful over time, or more complicated?
- Do frameworks such as LOD, BIM dimensions, and maturity levels create clarity, or do they create confusion?
- Can a project be considered successful in BIM terms even if it relies very little on 3D modeling?
- And most importantly, when we talk about BIM today, are we still talking about helping people work better—or are we talking about something else entirely?
The discussion remains open.
