Why Good Systems Fail When Good People Don't Trust Each Other

So folks, I want to talk about something I get asked about more and more. Usually by architects or engineers, occasionally by homeowners who have been reading about it online.

Artificial intelligence. BIM. The future of construction.

And I want to be honest with you about where I stand, because I think there is a lot of noise in this space and not much signal.

I am not a sceptic. I use AI tools in my practice every day, in ways that make me faster and more accurate. And I have a BIM qualification from Bolton Street — I know what the technology can actually do, at a level of detail that most people who write about it do not.

But the longer I work with these systems, the more I've come to believe that the technology was never really the hard part.

What is visible

On paper, BIM is a solved problem. The software exists. The standards exist. The training exists. You can buy a BIM licence this afternoon and be modelling by tomorrow morning.

Same with Lean construction. The principles are documented, taught, certified. Same with integrated project delivery — the contractual frameworks exist to bind everyone to the same collaborative process.

And yet. Projects that have all of this in place still produce clashes that should have been caught. Still produce information that sits in the model but never reaches the person who needed it. Still produce teams where the architect and the structural engineer are technically "collaborating" in the same environment and functionally not speaking to each other.

The visible problem is always framed as a technology problem — wrong software, bad training, insufficient investment. Buy the better tool, run more training, and the problem is meant to resolve itself.

It usually doesn't.

What is happening beneath the surface

Here is what I have come to believe, after years of watching this play out on real projects.

BIM provides information. Lean improves process. Integrated delivery requires collaboration. None of those three things is optional if you want a project to run well.

But none of them work unless the people using them trust each other enough to actually use them properly.

A structural engineer who doesn't feel safe flagging a clash in a shared model — because the last time he did, it turned into a territorial argument about who was "wrong" — will quietly stop flagging things early. He'll wait until it's undeniable, which is also the point at which it's most expensive to fix.

A site foreman who has been handed a beautifully coordinated model but was never actually consulted on it will treat it the way people treat anything imposed on them without buy-in — with quiet, functional non-compliance. He'll build what he thinks makes sense, not what the model says, because nobody made him part of building the model in the first place.

An architect and an engineer who have a good professional relationship will resolve a design clash in a five-minute phone call. The same two people, without that relationship, will resolve it through a paper trail of formal correspondence that takes three weeks and leaves both of them feeling defensive.

None of this is a BIM problem. It is a psychological safety problem, a trust problem, a hierarchy problem, a communication problem — wearing a BIM-shaped costume.

What is the commercial consequence

This is not a soft observation. It has a hard cost.

Clashes caught late instead of early mean rework — and rework is one of the most expensive and most preventable categories of cost on any construction project. Information that exists in a model but doesn't reach the right person at the right time causes delay. Delay causes claims. Claims cause disputes. Disputes cause the kind of final account nobody recognises — which, as I've written about elsewhere, is very often where the real damage on a project actually happens.

Poor team dynamics don't just make a project unpleasant. They make it slower, more expensive, and more likely to end in conflict. I would go further — in my experience, the technical

competence of a design team predicts less about project outcomes than the quality of the relationships between the people on it.

What people should actually do

I don't think the answer is to abandon BIM or Lean or integrated delivery. I think the answer is to stop treating them as purely technical implementations and start treating the human side of them as seriously as the technical side.

That means building in psychological safety deliberately — creating an environment where raising a problem early is rewarded, not punished. It means involving the people who will actually use a system in building it, not just training them on it after the fact. It means understanding the professional and hierarchical boundaries in a room — who defers to whom, who is afraid to speak up in front of whom — and actively working against the ones that are getting in the way of the project.

It means treating collaborative planning sessions and difficult project meetings as skills to be facilitated well, not just calendar events to be scheduled.

And it means applying what I think of as the White Van Test to every system you introduce: if the people who actually have to deliver the work — on-site, in the model, in the meeting room — don't understand it, believe in it, or buy into it, the system will not work. However good it looks in the tender document.

This applies to BIM. It applies to Lean. It applies to procurement, to project management, to construction generally.

Where this leaves me

I am increasingly interested in this space — not as someone who wants to build BIM models or run 5D cost models as a standalone service, but as someone with a QS and construction background who sees, project after project, that the technically good systems succeed or fail based on whether the humans using them actually work well together.

BIM gives you information. Lean gives you process. Integrated delivery gives you a contractual framework for collaboration. But leadership, trust, and team dynamics are what determine whether any of that actually gets used the way it was designed to be used.

That is the piece I think is currently under-discussed in Irish construction. And it's the piece I find myself paying more and more attention to.

If your project team has the systems in place but something still isn't clicking — the model isn't being used the way it should, the meetings aren't productive, people aren't speaking up — that's

usually not a technology problem. Let's talk about what's actually happening. → [contact form / new page, TBD]

If I can help in any way, let me know