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

Someone on our MEP team created a new fan coil family instead of pulling the existing one from our shared library. Not maliciously, not even carelessly really, he just didn't know it existed, and typed the specs in from a cut sheet PDF he'd been sent. Same manufacturer, same model number even, but he'd fat-fingered one dimension while transcribing it. Small thing. Six millimeters off on a mounting bracket depth.

Nobody caught it for three weeks because both families looked identical in every view that mattered during coordination, plan, section, even the 3D isometric we usually screenshot for client reviews. It only showed up when the MEP contractor tried to physically mount the unit inside the shaft and the bracket didn't line up with the sleeve we'd already cast into the concrete. By then we were two weeks from a scheduled inspection.

That was the moment our BIM manager finally forced through something he'd been asking for since the project started, one single shared family library, locked, with write access limited to two people.

Before that, every discipline kept their own local copy of families pulled from wherever, manufacturer websites, old projects, sometimes just recreated from memory because searching the shared drive felt slower than modeling it fresh. We had, and I actually counted this once out of morbid curiosity, eleven separate versions of what was supposed to be the same standard cable tray family floating around different team folders. Eleven. Same nominal size, different parameter names, different level of detail, a couple of them missing the load rating parameter entirely.

Getting Everyone Onto One Library

The fix itself wasn't technically hard. It's the getting-everyone-to-actually-use-it part that takes real effort.

We built a central library file on the shared network drive, split into folders by discipline and then by category, structural, mechanical, electrical, each with a naming convention that encodes manufacturer, size, and revision date right in the family name. Boring stuff. But boring is exactly the point. When a family is named something like COOLING_FCU_Daikin_450CMH_Rev03, nobody has an excuse to not know what it is or whether it's current.

Two people got write access to that folder. Everyone else gets read-only. If you need a family that doesn't exist yet, you request it, someone builds it against a checklist, and it goes in with a revision number. It sounds bureaucratic writing it out like this, and it is, a little, but eleven versions of a cable tray family is a worse kind of bureaucracy, it's just invisible until something breaks.

What Actually Goes Wrong Without This

The cable tray thing never caused a real problem, as far as I know. Just wasted modeling time, people building families that already existed three folders over. The fan coil bracket did cause a real problem, because dimensional mismatches inside a family don't show up in a clash detection report the way you'd hope. Clash detection catches geometry colliding with other geometry. It does not catch a bracket depth that's wrong by six millimeters if nothing else in the model happens to occupy that exact space. The model looked completely clean. Clash report came back green. The problem was sitting quietly inside a single parameter value, invisible until someone tried to bolt real metal to real concrete.

That two-week delay meant re-ordering the correct bracket hardware, re-scheduling the inspection, and one distinctly uncomfortable call where I had to explain to the client's rep why a component that had cleared every coordination review still didn't physically fit. He was fine about it, actually, more understanding than I expected. It was the drive back to the office after that call where I did most of my complaining, mostly to myself.

Shared Parameters Matter More Than People Think

The other habit that came out of this, less dramatic but probably saves more time day to day, is enforcing shared parameters across every family in the library instead of letting each modeler define their own instance parameters. If your load rating field is called "Load_Rating" in one family and "MaxLoad" in another, any schedule or tag pulling that data silently breaks or shows blank cells, and you won't notice until someone's reading a schedule during a submission review and asks why half the rows are empty.

We keep one shared parameter file now, referenced by every family that goes into the library, checked in during the same review that assigns the revision number. It's not exciting work. Renaming parameters and updating a shared file is the kind of task that never makes anyone's highlight reel. But I'd rather spend an afternoon on a boring parameter audit than another two weeks explaining a bracket that doesn't fit to someone standing in a half-finished ventilation shaft.

For anyone dealing with the messier side of BIM coordination on infrastructure work, this connects pretty directly to the resubmission grind I wrote about in Getting Through LTA's BIM Submission Process Without Losing Your Mind, and the coordinate mismatch story in The Coordinate Mistake That Sent Our Tunnel Two Kilometers Off Course. Different failure mode each time, same underlying lesson, the model can look perfectly clean and still be wrong in a way that only shows up once real people are trying to build real things from it.

Related reading:

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

The Coordinate Mistake That Sent Our Tunnel Two Kilometers Off Course

Why Cutting a Hole in a Concrete Wall in Revit Is Never as Simple as It Sounds