In the infrastructure industry, it is very common to hear that “IFC does not work”. This statement appears in conversations between designers, contractors, and clients. At first glance, it may seem that the problem really lies in the standard itself. In practice, however, the situation is usually different.
From my experience, in most cases IFC works exactly as it was designed to work. The problem appears only when someone tries to actually use the model further in the process. That is when it becomes clear that the issue is not the file itself, but what was put into it.
The Problem Is Not IFC
IFC is a data exchange standard. Its main purpose is to transfer information between different systems and tools. It is not a tool that controls model quality, nor is it a system that “fixes” mistakes along the way.
If the model contains inconsistent data, missing properties, or a chaotic structure, IFC will do nothing more than faithfully transfer that state into the next environment. This often leads to the wrong conclusion that IFC is the problem, while in reality it is only a mirror reflecting the quality of the input data.
Models Are Created Without a Clearly Defined Purpose
One of the most common reasons why IFC “does not work” is the lack of a clearly defined purpose for the model. In many projects, the model is created as something that “has to be done”, rather than as a tool for a specific use case.
Only after the model is created do expectations appear that it should support quantity takeoff, coordination, construction use, or integration with GIS systems. At that point, it becomes clear that the model was not prepared for any of these purposes.
This is not caused by IFC limitations, but by the lack of an early decision about what the model should be used for and what information it should contain.
IFC Infrastructure Masterclass
Want to truly understand IFC in infrastructure?
If you want to go deeper into IFC 4.3, openBIM, infrastructure models, and practical data workflows, explore the IFC Infrastructure Masterclass. It is designed for people who do not just want to export models, but want to understand how to make information actually work in real projects.
Explore the masterclassGeometry Is Not Enough
Another very common problem is focusing on geometry at the expense of data. A model can look very good visually, be detailed and well-developed, and still be unsuitable for further use.
This happens when elements do not have consistent naming, classifications are random, and properties are not defined in a way that allows further processing. In such cases, even simple operations such as filtering elements or preparing reports become difficult or almost impossible.
This shows one key thing: the value of a model does not come from how it looks, but from the quality of the data it contains.
One Model for Everything Does Not Work
In many projects, there is an assumption that one model should cover all project needs. In practice, this approach rarely works.
A model prepared for visualization has different requirements than a model used for cost estimation or construction. Each of these use cases requires a different level of detail, a different data structure, and a different modeling approach.
In infrastructure, this is especially visible because projects include many stages and many different teams. An existing conditions model, a design model, and an as-built model serve completely different purposes and should not be treated as one universal product.
Data Gets Lost Between Project Stages
One of the biggest challenges in infrastructure projects is maintaining data consistency throughout the entire lifecycle. Information is created during planning, developed during design, used during construction, and should later be transferred into asset management systems.
In practice, part of the data or its meaning is often lost. Each stage introduces its own tools and formats, and the data is transformed, simplified, or interpreted again. As a result, instead of continuity, we end up with fragmented information that is difficult to reuse.
IFC can support this process, but only when models are prepared with the full lifecycle in mind, not just a single project stage.
Lack of a Consistent Approach to Data
Another important issue is the lack of a common approach to data within a project. Different teams often use their own naming conventions, classifications, and modeling rules.
For humans, these differences may still be understandable, but for digital systems they create serious limitations. Lack of consistency makes filtering, analysis, and automation much harder.
IFC works best when data is predictable and structured. Without that, even the best-prepared model quickly loses its value.
IFC 4.3 Is a Step Forward, but Not a Complete Solution
The introduction of IFC 4.3 is an important step toward better support for infrastructure. The new version considers linear assets such as roads and railways and improves integration between BIM and spatial data.
However, this does not mean that all problems will be solved automatically. The standard provides more possibilities, but it still requires a conscious approach to modeling and data management.
Without that, even the most advanced standard will not deliver the expected results.
What Actually Makes IFC Work
Projects where IFC works well have one thing in common. The purpose of the model is clearly defined from the beginning.
Before modeling starts, the requirements for data, structure, and future use are defined. As a result, the model becomes a tool that supports specific processes, rather than a by-product of the project.
This approach helps avoid many problems and turns IFC into real support, rather than a source of frustration.
Conclusion
IFC does not fail in most projects because it is a bad standard. It fails because it is used without understanding what a model actually is.
A model is not just geometry. It is an information carrier that should be prepared for a specific purpose.
Until this mindset changes, no format will solve the problem. But once it does, IFC starts to work exactly as intended.
