BIM Coordination Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does coordination software get scoped as a clash list so often?

Because the clash report is the visible artefact. Navisworks runs overnight, produces 11,842 results, and the obvious brief is a better way to look at them. Every software firm can build that, and it will beat a spreadsheet. It will also miss the thing that governs whether the model matches the building.

Coordination runs on decisions, not on results. A resolved clash needs four facts recorded: what was agreed, who is doing it, by when, and against which model versions the agreement was made. Meeting minutes hold the first and sometimes the second. Generic issue trackers hold an assignee and a status. Neither ties the resolution to the date it actually has to be finished by, which is set by fabrication release, procurement or the concrete pour rather than by the coordination meeting cadence.

The model that works makes the coordination zone the primary object rather than the clash. Each zone carries a gate date pulled from the construction schedule, an owner at a named firm rather than a discipline, and a count of open issues. The view your coordination lead needs is not eleven thousand rows, it is nine zones with an owner and a days to gate number. That single reframing changes what gets worked on, because zones behind their gate rise to the top and clashes that do not threaten a date stop consuming meeting time.

What goes wrong when models update and clash identity resets?

This is where coordination platforms quietly fail, and it happens on the second model issue rather than the first. A skilled BIM manager groups clashes by hand: by element pair, by system, by zone, by level. That grouping is real work and it does not survive an update, because the next run generates new clash identities and every group has to be rebuilt or painstakingly matched. The same duct against the same beam appears as a new row with no history, and the backlog resets to zero every week.

The technical fix is to derive identity from the participating elements and their globally unique identifiers rather than from the position of a result in a clash test. Do that and last week's issue is this week's issue with its comments, its owner and its due date intact. Ask any prospective developer how they will keep clash identity stable across model versions before you talk about anything else, because a vague answer here means you are buying a to do list with a three dimensional picture attached.

The second data problem is maturity. Structure is at a level of development suitable for fabrication, mechanical is design intent with generic equipment, and the electrical subcontractor has not uploaded since the last milestone. Federating those as equals generates thousands of false conflicts and gives everyone permission to dismiss real ones as premature. The answer is a model register recording, per authoring firm and per discipline, the expected level of development by phase, the required update cadence and the last version received with its date. Every clash then carries the model versions it was found against, and issues raised against a superseded model are flagged for revalidation. Late uploads become a visible service failure rather than a rumour, which matters when a consultant later argues the coordination delay was not theirs.

Why do the authoring tool and viewer integrations break after launch?

Two integrations decide whether modellers use the system, and both fail in predictable ways.

The first is the round trip to the authoring tool. If a modeller has to leave Revit or Tekla, log into a portal and retype an issue, they will stop, and within a month coordination is back in email. The BIM Collaboration Format exists precisely for this and is supported by the major authoring tools, so issues should flow out to each firm's own environment and back with comments and status intact. The failure mode is a one way export: issues leave the platform, get resolved in the modeller's tool, and nothing returns, so the platform's status is permanently behind reality. Test the return leg with a real modeller in week six rather than at acceptance.

The second is viewer performance. A federated model on a real project is heavy, and there is a large gap between a demo of a single export and a viewer that stays usable on a site laptop with twelve disciplines loaded. Adoption dies where a subcontractor waits thirty seconds for a view to settle. Ask what a developer has shipped that renders large geometry in a browser, with the project and the model size, and test on your heaviest model over your worst connection.

What happens when sign off and joint venture access are not covered?

Sign off is the control that prevents the most expensive category of failure, which is not an unresolved clash but a resolved one that quietly got undone. Without it, a zone is coordinated because somebody said so in a meeting, and a later model revision can move a resolved element with nobody informed. With it, a zone is coordinated only when each responsible party has accepted it, and the system captures a snapshot of the exact model versions at that moment. If anyone then modifies a model inside a signed off zone, the zone reopens and everyone who signed is notified. That is a small feature with a disproportionate effect on what reaches site.

Access is the other gap, and it is contractual rather than technical. On a joint venture or a design and build with several tier one contractors, firms are cautious about native model exchange, because sharing a Revit file is sharing intellectual property and inviting edits. Teams that ignore this end up with coordination happening in a viewer nobody trusts, or with a shared folder somebody is quietly refusing to populate.

The fix is to standardise on open formats and permission by firm and by zone. Geometry exchanges as IFC, issues exchange as BCF, and the browser viewer renders derived geometry rather than native files, so a subcontractor sees the federated context around their scope without downloading anyone's model. Firms that get this right stop arguing about model sharing and start arguing about the actual conflicts, which is the argument worth having.

Should you build custom or configure what you already own?

If you are coordinating a single building with two or three consultants and a stable team, do not build. Navisworks for detection, Revizto or Newforma Konekt for issues, a clear BIM execution plan and a competent BIM manager will handle that scope well, and the licence cost is trivial next to a build. Solibri is worth adding if your problem is model quality rather than workflow, because rule based checking catches things pure geometry misses.

Where a custom build earns its place is repeatability. A firm that coordinates well because of two specific individuals has a hiring problem wearing a technology costume, and encoding your grouping rules, level of development expectations and sign off gates into a system is how that knowledge stops walking out of the door.

Build when two or more of these are true. You run several concurrent large projects and coordination quality depends on which BIM manager is assigned. Your firm has written standards and no tool enforces them. You work in joint ventures where native model exchange is contentious. You have had a resolved clash reappear in the field after a model changed. Or the owner wants coordination status reporting you currently assemble by hand every month.

How do hidden costs get into the quote?

The browser viewer is the largest and the least understood. Smooth navigation of a large federated model on a laptop is an engineering problem involving geometry conversion, level of detail handling and streaming, and it is routinely priced as though it were a component someone drops in. If you need it in release one, say so and expect it to dominate the number. If you can live with the detection tool's own viewer for a release, the first phase gets considerably cheaper.

Second, running your own clash detection rather than ingesting results from the tool your team already uses. Writing a geometric interference engine is substantial work with a mature alternative sitting on every BIM manager's machine, and it is rarely the right first move.

Third, a deep add in for a specific authoring environment, which is a separate development effort with its own release cycle. Fourth, point cloud overlay for renovation work. Fifth, the workshop time to capture your grouping rules, naming conventions and level of development expectations, which is not engineering but sits on the critical path.

What separates a build that works from one that fails here?

Pilot on a live project. A coordination platform designed in workshops without a real job pushing on it will be wrong in ways nobody can predict from a whiteboard, and the failure surfaces at rollout when the first BIM manager finds the zone model does not match how the building is actually being built. Pick the project with the most painful coordination and build against it.

Second, ingest rather than replace. Let Navisworks or Solibri do detection, and spend your budget on grouping with persistent identity, ownership, gates and sign off. That is what is missing, and it is where the money leaks.

Third, make the gate dates real. If they come from a schedule nobody updates, the days to gate number is fiction within a month. Tie them to fabrication release and procurement milestones the project actually manages.

Fourth, design for the modeller, not the manager. The person who has to change a duct is the one whose behaviour determines whether the building matches the model, and if the system pushes them out of their authoring tool they will route around it. BCF in both directions, tested with a real modeller early, is the difference between a system that is used and a dashboard the coordination lead maintains alone.

Finally, settle ownership before kickoff: the repository, the cloud accounts and the unrestricted right to bring in another firm. At Digital Heroes the client owns the code from the first commit. The point of the build is that it encodes your firm's coordination standards, and standards held inside somebody else's product are not an asset you control.