The Hidden Costs of Over-Modelling

From my experience, BIM does not always suffer from a lack of data. In many cases, it suffers from too much data with no clear purpose.

That may sound backwards, especially in an industry that talks so much about digital delivery, data-driven workflows, dashboards, digital twins, and AI. But in practice, I have seen project information become harder to use when too much of it is collected without a clear reason, owner, structure, or validation process.

I call this data gluttony.

Data gluttony happens when a model, spreadsheet, dashboard, or handover package becomes overloaded with information simply because the information can be captured. Parameters are added. Fields are exported. Attributes are requested. Schedules become larger. Data drops are produced. But the purpose behind the information is not always clearly defined.

As I see it, that is where BIM data can stop being helpful and start becoming clutter.

More Information Does Not Automatically Mean More Value

There is a common assumption in digital delivery that more data means better delivery. At first, that sounds reasonable. If we capture more information, we should have better insight. If we collect more attributes, the owner should receive more value. If the model contains more fields, the handover should be stronger.

From my perspective, that only works when the information is structured, governed, checked, and connected to a real use case.

Without that structure, more data can simply create more work. It increases review time. It creates confusion over responsibility. It adds noise to schedules and exports. It makes handover harder to check. It can also reduce trust in the information because teams are not sure which values matter and which ones are just there because someone asked for them.

In BIM, volume is not the same as quality.

The Data Glutton Problem

In my experience, data gluttony usually starts with good intentions.

An owner wants better handover information. A project team wants to be more data-driven. A consultant wants to support future operations. A contractor wants information for coordination or procurement. A digital team wants to prepare for dashboards, digital twins, or AI workflows.

None of that is wrong.

The problem begins when every possible data field becomes a requirement without asking whether it supports a real outcome.

For example:

What decision does this data support?

Is it needed for design, construction, handover, or operations?

Who is responsible for entering it?

Who is responsible for checking it?

When does it need to be complete?

Will anyone maintain it after handover?

Can it be validated?

Does it belong in the model, a schedule, a database, or another system?

When those questions are not answered, the model can become a container for unclear expectations.

That is how data gluttony enters the workflow.

BIM Teams Should Not Become Data Dumping Grounds

From what I have seen, designers, consultants, contractors, and BIM teams are often asked to carry more information than the project delivery process was designed to support.

This is important to say clearly.

It is easy to ask for more data. It is harder to define the business rule behind the data, the delivery milestone, the acceptance requirement, the validation method, and the responsibility for maintaining it.

As a practitioner, I see this as one of the most common gaps between digital ambition and project reality.

A request for “more data” can sound simple from the outside, but inside the authoring environment it can affect time, cost, coordination, QA/QC, templates, schedules, families, parameters, exports, and handover expectations.

A Revit parameter is not just a field. It can become part of a larger workflow.

If the information is important, it should be treated as an actual requirement, not an informal wish list.

Standards Help Control the Appetite

From my perspective, standards are one of the best ways to reduce data gluttony, but only when they are used properly.

A good standard does not ask for everything. A good standard defines what information is required, why it is required, when it is required, who is responsible for it, and how it should be checked.

That is the difference between a data request and an information requirement.

A data request says:

“Add these fields.”

An information requirement says:

“This information is needed for this purpose, at this stage, by this responsible party, in this format, and it will be accepted or rejected using this method.”

That level of clarity helps teams understand the value of the information. It also helps prevent unnecessary data from entering the workflow.

As I see it, a long list of fields is not automatically a good standard. A standard should support better delivery, not create more clutter.

The Bottleneck Should Be Engineered

Every project has bottlenecks. Data moves through people, models, spreadsheets, review cycles, coordination meetings, platforms, exports, and handover processes.

The problem is not that bottlenecks exist. The problem is when they are accidental.

An accidental bottleneck happens when information piles up because the workflow was not designed properly. Teams wait for clarification. Data is reworked. Parameters are inconsistent. Exports fail. Handover information is corrected too late. The owner receives information that is difficult to trust or reuse.

In my view, a better approach is to create an engineered bottleneck.

An engineered bottleneck is a controlled decision point. It is where information is filtered, validated, structured, and prepared before it moves downstream.

For BIM delivery, this could mean:

Checking required parameters before export.

Validating asset data before handover.

Reviewing naming and classification rules.

Confirming responsibility for data ownership.

Filtering out low-value attributes.

Aligning model information with operational needs.

Preparing clean data for automation or AI workflows.

This is where BIM data becomes useful.

The goal is not to remove every bottleneck. The goal is to make the critical bottlenecks intentional.

Data Gluttony Hurts AI Readiness

The conversation around AI in BIM is growing quickly. From my experience, this makes data discipline even more important.

AI does not solve poor information structure by itself.

If the source information is inconsistent, duplicated, incomplete, or overloaded with low-value attributes, AI may only move the mess faster.

AI needs context. It needs structure. It needs reliable information. It needs a clear use case.

If a model is filled with unclear parameters, inconsistent naming, duplicate values, and unvalidated handover data, then AI is not starting from intelligence. It is starting from confusion.

Before asking how AI can use BIM data, I believe organizations should first ask whether the BIM data is worth using.

This is why reducing data gluttony matters. Clean information is not just better for handover. It is better for automation, dashboards, reporting, digital twins, and AI-enabled workflows.

The Better Question

Instead of asking, “What data can we collect?” the better question is:

What information is worth managing?

That question changes the conversation.

It moves the focus away from volume and toward value. It helps teams separate useful information from clutter. It supports better standards, better workflows, and better handover. It also helps owners receive information that can actually support operations and decision-making.

From my perspective, not every attribute needs to survive the project. Not every field belongs in the model. Not every data point is worth maintaining.

The value is not in collecting everything.

The value is in knowing what matters.

A Practical Way Forward

In practice, reducing data gluttony does not mean ignoring data. It means becoming more disciplined about it.

A practical BIM data workflow should:

Define the purpose of the information.

Identify the required data by project phase.

Assign responsibility for creating and checking it.

Align parameters and naming rules to standards.

Validate information before it moves downstream.

Filter out information that does not support value.

Prepare structured information for handover, reporting, automation, or AI.

That is the difference between collecting data and managing information.

Closing Thought

As a practitioner, I do not see BIM data as something that should be collected just because the tools allow it.

I see BIM data as a managed information asset.

When BIM data is overloaded, unclear, and unvalidated, it becomes data gluttony. When it is structured, purposeful, and checked, it becomes useful digital value.

That is where BIMxcel focuses its work.

BIMxcel helps organizations reduce data clutter, define better information requirements, improve BIM workflows, and prepare structured data for practical use across project delivery, operations, automation, and AI integration.

Because better BIM is not about feeding the model more data.

It is about engineering the flow of the right information.

Steven Spry
BIM Specialist | Founder, BIMxcel Inc.

AI-assisted editing was used. The ideas, final content, and responsibility are my own.