What I've Learned as a BIM Manager: Why Good Data Matters More Than Beautiful 3D Models

Whenever I show a BIM model to friends or family for the first time, I get pretty much the same reaction. Wow, that looks amazing. I get why, modern models are ridiculously detailed, you can walk through an entire building before a single wall's actually been built. But after years managing BIM on infrastructure projects, the thing that actually keeps me up before a handover isn't how the model looks. It's whether the data sitting behind every object is actually right.

I learned that the expensive way, not through some abstract lesson but through a phone call about eighteen months after one of our stations went live.

The Call From Facilities Management

Someone from the operations team called asking for the maintenance schedule and part specifications for a set of ventilation dampers, information that should have been sitting right there in the model, attached to each object the way it's supposed to be. It wasn't. Somewhere during a late design change, a subcontractor had swapped out a damper model for a cheaper equivalent, updated the geometry so it looked right in every view, and never touched the associated data fields. The 3D shape was correct. The manufacturer, part number, and maintenance interval attached to it were for the old equipment entirely.

Facilities had been scheduling maintenance based on wrong data for over a year, not catastrophically wrong, but wrong enough that they were servicing on the incorrect interval and had ordered replacement parts that didn't actually fit when a technician showed up with the wrong bracket in hand. Nobody had caught it because nobody was checking data accuracy the way we check geometry clashes. The model looked flawless in every screenshot anyone had ever taken of it, every walkthrough render, every client presentation. That was exactly the problem, the parts everyone actually looked at were fine.

We spent about three weeks going back through the model with facilities, cross-checking every mechanical object against actual procurement records line by line, and found four more instances of the same issue, smaller ones, but the same root cause every time. A late swap that updated appearance without updating the information behind it. I remember sitting with a printed schedule and a laptop open to the model, manually clicking through maybe two hundred mechanical objects over two afternoons, which is not how anyone wants to spend a Thursday, but by that point trust in the automated checks had taken a real hit and nobody wanted to skip verifying by hand.

The Hardest Clash Isn't Between Pipes

Clash detection itself is one of the easier parts of the job, honestly. Software flags physical conflicts between structural, mechanical, and electrical systems in minutes, genuinely useful, but rarely the hard part. The hard part starts once the clash report lands and three different engineers each want a different fix.

On one coordination review, a mechanical duct run clashed with a structural beam in eleven separate locations along one corridor. The mechanical engineer wanted the beam depth reduced. Structural said no, not without a redesign that would take two weeks and involve resubmission to the reviewing authority, which nobody wanted to trigger this late in the schedule. I sat in a room for closer to two hours while both sides explained why the other's solution was unworkable, voices getting a little louder than strictly necessary at one point. The actual fix that got agreed on, rerouting the duct up and over rather than through, took maybe ten minutes once everyone stopped defending their original position and started just looking at the drawing together instead of at each other.

That's most of what a BIM manager's day actually looks like. Not running software. Getting people to stop defending positions long enough to look at the same problem from the same angle.

Why the Data Problem Is Getting Bigger, Not Smaller

Everyone's talking about digital twins now, and a digital twin is only as good as the data feeding it. If bad information gets baked into a model during design and construction, it doesn't just disappear once the building's finished, it becomes someone else's headache for the entire operational life of that facility, the way that damper data became operations' problem eighteen months after we'd all moved on to other projects and mostly forgotten the station existed.

Since that call, we added a specific check to our internal review process, a data audit that runs separately from the clash detection pass, flagging any object where geometry was modified more recently than its associated data fields were last touched. It's caught two similar issues since, both minor, both fixed before handover instead of eighteen months after some technician shows up with the wrong part.

A few weekends after that whole facilities situation wrapped up, we took the kids to Gardens by the Bay, walking through the Cloud Forest dome while my younger daughter kept asking why the mist machines turned on and off at what seemed to her like random times. I found myself explaining, badly, that it's probably all sensor-driven, humidity thresholds triggering the system automatically, and thinking about how much invisible data logic sits behind something that just looks like weather inside a building. Keeping data accurate isn't the exciting part of the job. Nobody's ever impressed by a spreadsheet the way they are by a walkthrough render or a dome full of artificial mist. But that phone call from facilities taught me it might be the part that actually matters most, long after everyone's forgotten what the model even looked like on screen.

Related reading:

The Duplicate Family That Cost Us Two Weeks on a Tunnel Ventilation Shaft

Getting Through LTA's BIM Submission Process Without Losing Your Mind