When you coordinate models from multiple disciplines, you see it all. Some models are clean and organized. Others? Complete chaos.
I'll never forget federating all models for the New Stavanger University Hospital for the first time. My stomach dropped. Hundreds of different property sets. Properties with identical names that weren't actually the same. Total mess.
Who created this disaster? We all did. But slowly, steadily, we progressed all models into cohesive shape.
What gave us direction? IFC properties requirements set out at the very beginning of the project.
The Problem: Data Chaos
Your BIM models need to be more than 3D geometry. They need data to be useful throughout the project lifecycle.
But here's what happens without standards:
- Different software creates properties in different ways
- Different companies create properties in their own ways
- Architects prefix custom properties with "ABC_"
- Structural engineers use "AAI_" for property sets, no prefix for properties
- MEP consultants export MagiCAD defaults with "MC_" prefix
Designers model, calculate and export whatever they think is right. They follow no defined level or structure of information.
Result? Triple properties. Confusion. Nobody outside each discipline knows what anything means.
Data structure is crucial to allow for effective use of IFC models. If one party wants to use another party's model for their work, properties must be correctly specified.
So here's the fix: Define a standard set of properties that everyone follows. Same names, same structure, same format. Everyone knows what each property means and can actually use it.
But this needs to happen before anyone models anything.
The Solution: IFC Properties Requirements
Two things make IFC requirements work:
- The client demands it (contractually)
- Parties get paid for following it
Bear in mind - the best approach includes these property sets in contractual documents signed by every party. This document is called the Exchange Information Requirements (EIR).
In practice I would split this into two formats:
- The contractual attachment (human-readable table)
- Machine-readable format for validation (IDS - coming in my next article)
Building Your IFC Properties Requirements Table
Here's the structure that worked for us:
| Column | Purpose | Example |
|---|---|---|
| Property Set Name | Groups related properties together | DoorCommon, NOSHN_Process |
| Property Name | Specific property identifier | IsExternal, Name |
| Object Type | Which IFC entities this refers to | IfcWall, IfcDuct |
| Description | What this property means | Floor number, Minimum airflow rate |
| Requirement | MUST have or CAN have | MUST, CAN |
| Data Format | How to format the value | Boolean (TRUE/FALSE), Integer [NN] |
| Example | Sample value | 01, True, 100 |
| Project Stage | When it's needed | Early Design, Detailed Design, Construction, Operation |
Creating Your Requirements: A Practical Process
Here's the methodical approach we used on that New Stavanger University Hospital. I won't claim it's perfect, but it worked through all those years:
Before setting out to create a requirement table, you have to first define what to require. To better understand different scope of data in the model, I encourage you to visit this entry: BIM model data
Step 1: Define Your Data Scope
Define to what extent you are going to use data within the model. Pick your tier:
Tier 1: Design Only
- Models only for design and coordination
- Construction gets drawings
- Minimal properties needed
Tier 2: Design & Construction
- Models used actively in both phases
- More properties needed for construction (rebar dimensions, responsibilities)
- Different data required for different phases
Tier 3: Full Lifecycle
- Include operation phase
- Need unique identifiers connecting graphical representation with maintenance databases (link)
- Links to maintenance databases
Step 2: Build Your Property List
Don't try to drill through all 2500 IFC properties alone. IFC Properties Reference Instead:
- Workshop with your designers and contractors
- Review what worked on previous projects
- Get expert input (yes, we help with this)
Step 3: Add Custom Properties
IFC schema won't cover everything you need. Create custom property sets for project-specific requirements.
What I miss most are project management properties:
- Control Area
- Level of Development
- Responsibility
Group them under custom property sets for better organization.
Step 4: Fill Your Requirements Table
With all properties identified, complete your table so every stakeholder understands requirements identically.
Here's a filled example:
| Property name | Object Type | Description | Requirement | Data format | Example | Project stage | |||
|---|---|---|---|---|---|---|---|---|---|
| Early Design | Detailed Design | Construction | Operation | ||||||
| Name | IfcBuilding | Building code | Must | [NN] | 81 | X | X | X | X |
| Name | IfcBuildingStorey | Floor number | Must | [NN] | 01 | X | X | X | X |
| IsExternal | All walls, columns, slabs | Defines if the object is external or internal | Must | True/False | True | X | X | X | X |
| Drop | Ducts, pipes | Defines drop of the element | Can | N.N | 0.2 | X | X | ||
| AirflowMin | Air Terminals, ducts, flow dampers | Minimal value for designed airflow rate | Must | [NN] l/s | 100 l/s | X | X | X | |
Summary
A BIM model is only as good as its data. By planning your IFC properties requirements and backing them with contracts, you transform chaotic 3D geometry into powerful, intelligent tools.
It’s the difference between a pretty picture and a living asset that serves your project through its entire lifecycle.
As a matter of fact, without clear property requirements, you’re not doing BIM – you’re just making expensive CAD drawings.
Let me know in the comments if you’ve faced similar property chaos on your projects. I’ll help!
