Have you ever wondered why, despite the exponential growth of digital data in construction project information management, stakeholders’ understanding of that data seems to continuously diminish?
The root cause: information silos that fragment information management in construction projects at every stage.
Table of Contents
The Data Paradox: Growth vs. Understanding
Throughout the lifecycle of construction projects, information management faces a paradoxical challenge:
- Digital data production increases exponentially
- Meaningful interpretation of information dramatically decreases
- Project stakeholders struggle to maintain comprehensive information management in construction projects
This phenomenon is aptly illustrated in a research visualization that shows a stark decline in information understanding with a transition to each project phase.
Why Information Gets Lost and why is it a problem?
Not all data loss is detrimental. Some information naturally becomes archival as a project evolves. However, the scale of knowledge erosion is often far more significant than necessary.
Why do information management in construction projects efforts consistently fail? Several critical factors emerge:
- Changing Team Compositions
- Different teams handle various project phases
- While some roles (like architects) remain consistent, many teams exit during the project
- New team members join later, bringing different perspectives
- Software Discontinuity
- Design stages rely heavily on BIM Authoring tools
- Construction phases shift to viewers and field solutions
- Other phases rely on other tools or spreadsheets
- This transition creates barriers to accessing embedded information
- Shifting Focus Areas – Each project stage has distinct objectives:
- Planning: Function
- Design: Shape and Form
- Construction: Details and Materials
- Facility Management: Maintenance and Operations
A Practical Example: Medical Equipment Installation
Stage 1: Medical Planning
Stage 2: Design
Stage 3: Construction
Stage 4: Procurement
Stage 5: Assembly and Testing
Stage 6: Facility Management
Proposed Solutions
To mitigate information loss and enhance information management in construction projects, I recommend:
- Enhanced Digitalization
- Move beyond merely having digital data
- Ensure data is accessible to relevant stakeholders
- Silo Connection
- Create smoother transitions between project stages
- Minimize data fragmentation
- Comprehensive Data History
- Maintain an activity log of decisions, notes, and changes
- Provide context for new team members
How can we do that?
The best would be to achieve that without the necessity to make too many changes to our current processes.
Use similar workflows.
Use the same software.
Is that even possible?
It might be.
We have to take a look at this continuity from a data perspective.
Let’s circulate back to the example of an equipment and break down its information path:
- First, it is created in a database (or an Excel) with some information about requirements
- Then, the designer models an object in BIM Authoring software
- Onthe construction site, it exists in an IFC model, the drawing and technical specification available tothe responsible team as a scope of work
- For procurement, it exists in another spreadsheet or procurement software
- Mounting and testing – another checklist to verify if the equipment has been delivered and if it works properly
- Handover still works as a folder with pdfs, graphs and schemas describing that equipment type.
Do you see the thread here?
The same or similar data travel from one software to another. We can connect it with a thread.
Unique object tag.
Something like I’ve described previously on this blog.
Why would this help?
Because we could treat this value as a Primary Key and lookup required information from other data sources.
Just like it works in relational databases.
Relation database and cardinalities
What we want to achieve is the possibility for seamless import or lookup data from one source to another and correctly associate the same objects from different sources. To perform that, we have to use the data sets we have in a way that would make it possible to create relations between them.
I’ve already given some introductions to databases and explained some simple terms. You can find it here.
The next topic in the database world is relations and their cardinalities.
Cardinality in relational databases refers to the numerical relationship between entities in different tables. It defines how many instances of one entity can be related to instances of another entity.
The key types of cardinalities are:
- One-to-One (1:1): Each record in Table A relates to exactly one record in Table B, and vice versa. For example, each building has exactly one building permit number, and each building permit number belongs to only one building.
- One-to-Many / Many-to-One (1:*/ *:1): A single record in Table A can relate to multiple records in Table B, but each record in B relates to only one record in A. For example, many rooms are located on one floor of a building.
- Many-to-Many (*:*): Multiple records in Table A can relate to multiple records in Table B. This relationship requires an intermediary junction table. For example, multiple contractors can work on multiple projects. A contractor can be assigned to several construction projects, and each project can employ multiple contractors.
For a comprehensive explanation of both cardinalities and keys, you can visit Database.Guide’s article on database relationships.
Primary key properties in BIM
Focusing though on our example of the path for objects’ data throughout the project phases. To be able to retain the information, we have to establish a possibility to exchange objects’ data between different software. In every project, there are loads of different software used.
How It Works
- Establish a consistent identifier in initial planning
- Carry this identifier through design, construction, procurement, and facility management
- Enable seamless data lookup and association
Where to search for cardinalities and identifiers?
In objects’ properties.
Yet different use cases and software rest on distinct properties that we can use as a Primary Key. We’ll get to that in detail in my next article.
Let us now take a look at how a potential workflow might look like:
- Create an object in a planning database with a unique key
- Carry key through design software
- Export to IFC for construction site – key value is inside IFC properties.
- For procurement systems, use the same key to gather data both from planning software and models
- Include key in delivery and testing checklists
- If the handover is in folders, give it the primary key name. If in software, use the key established in the model and other databases.
As you see here, we have full data and knowledge available throughout the entire construction process for any object that follows this path.
Summary
By treating project data as a continuous, interconnected ecosystem, we can dramatically enhance information management in construction projects. The goal is not just data preservation but creating a seamless knowledge transfer mechanism across all project stages.
Stay tuned for the next article, which will provide concrete examples of implementing unique object keys across different software platforms.
