Five months ago, I stepped into a coordination environment that I do not think I fully understood at the time.

The scope covered 24 assets, some of them repeated across multiple zones and instances. Parts of the work had been inherited from a previous contractor, which meant I was not starting from a clean baseline. Models existed. Drawings existed. Issues existed. Decisions had already been made.

The problem was that the history connecting all of those things was not always easy to find.

At first, I approached the work mostly as a BIM coordinator still early in his career. I was looking at models, clashes, comments, drawings and outstanding issues individually. I wanted to understand what needed to be corrected and move things forward.

Over time, I realised the harder problem was rarely the individual clash.

It was understanding why the current condition existed at all.

A model might show one thing.

An approved drawing might show another.

The site might already have progressed differently.

A coordination decision could have been made months earlier but never clearly reflected in the latest information.

A comment could appear straightforward until I followed its history and discovered that resolving it depended on another contractor, a pending clarification, a site condition, or a decision that was never properly captured.

Eventually, coordination started feeling less like reviewing geometry and more like reconstructing a living system.

Becoming the Project’s Memory

Without consciously deciding to, I started holding more and more of the project’s context in my head.

• Which asset had which issue.
• Which comments were actually resolved and which were only administratively closed.
• Which decisions were based on approved information.
• Which ones were inherited assumptions.
• Which contractor owed the next response.
• Which problems were isolated to a room or asset and which were repeating across the entire scope.

I became surprisingly good at moving between these pieces of information quickly.

Someone could mention an issue from weeks earlier and I would often remember the asset, the discussion around it, and what information we were still waiting for.

At first I was proud of that. I still am.

But I also started recognising something uncomfortable:

The coordinator’s brain should not become the database of the project.

Remembering everything is useful. Depending on someone to remember everything is a weakness in the system.

That lesson has probably influenced me more than anything else during these five months.

The Model Is Not Always the Truth

One of the biggest changes in my thinking has been understanding that there can be several versions of “truth” inside the same project.

• There is the design intent.
• There is the approved documentation.
• There is the coordination model.
• There is the current site condition.
• There is the formal issue status.

And sometimes they disagree.

When construction progresses faster than the information-management process can absorb those decisions, BIM coordination becomes partially forensic.

You start asking:

• What happened here?
• Why was this moved?
• Who agreed to it?
• Was that agreement ever formally recorded?
• Is the model incorrect, or is it simply behind the site?
• Which piece of information should control the next decision?

That changed how I look at BIM. A model can be geometrically accurate and still lack the context required to understand it.

Clashes Became the Beginning, Not the End

Earlier in my career, a clash understandably looked like the coordination problem itself.

Now I see a clash more as an observation. It tells me that two things intersect according to a particular model revision, test rule and tolerance. It does not automatically tell me why.

Several clashes might belong to the same underlying coordination problem. One problem might continue through several meetings, contractor responses, model revisions and design clarifications. It might disappear from one model and return later. It might eventually become an accepted deviation rather than something physically corrected.

That entire history matters.

The durable thing is not necessarily the clash. It is the coordination thread surrounding it.

That distinction now seems obvious to me. Five months ago, I would not have been able to articulate it.

Repetition Teaches You What Is Actually Systemic

Working across 24 assets also taught me something that would have been difficult to learn from a single building. Patterns become visible.

An issue found in one asset might initially look local. Then it appears in another. And another.

Eventually you realise you are no longer looking at several independent mistakes. You may be looking at one unresolved coordination principle expressed repeatedly across the project.

At the same time, repeated assets are never perfectly identical. A villa type might occur more than ten times across different zones, yet individual instances can still inherit different site conditions, interfaces or local coordination histories.

That forces you to distinguish between:

• What should be solved once, and
• What must remain instance-specific.

That is a systems problem as much as it is a BIM problem.

I Understand My Role Differently Now

The biggest personal change is probably how I understand coordination itself.

I used to associate competence heavily with software proficiency. Revit skill still matters enormously, and I have a lot left to learn. But coordination requires another layer of capability.

You need to know:

• When the problem is modelling.
• When it is design.
• When it is missing information.
• When it is scope.
• When another party needs to act.
• When you have enough evidence to make a change.
• And perhaps most importantly, when you do not.

Sometimes the correct action is not moving an element. It is stopping and asking the right question.

That shift has given me more confidence, but also more respect for how much I still do not know.

The Strange Relationship Between Pressure and Growth

This environment has not been easy.

There has been poor governance in places, slow implementation of decisions, incomplete inherited history, and situations where site progress has moved ahead of the models.

I do not want to romanticise those problems. Poor systems are still poor systems.

But working inside them has forced me to develop judgement much faster than I expected.

• Every unclear condition became a question.
• Every missing piece of information forced me to understand another relationship.
• Every repeated issue taught me to look for the larger pattern.

Over time, something changed. The project stopped looking like thousands of disconnected problems. Connections started appearing.

I could see how one decision affected several assets. How one unresolved interface propagated downstream. How a small communication failure could become a modelling problem weeks later. How a decision that was not preserved could eventually become somebody else’s mystery.

The project began looking like a network.

Engineering systems are networks of relationships, and coordination is largely the work of understanding and preserving those relationships.

Discovering My Own Capacity

There has also been a more personal discovery.

I did not know how capable my own mind was at dealing with this kind of complexity. That is not something I say arrogantly. If anything, it surprised me.

For much of my life I do not think I consistently placed myself in environments that demanded sustained systems thinking from me. This project did.

It required me to remember, connect, question, prioritise, communicate and continuously rebuild my understanding as new information appeared. And apparently my brain enjoys that.

I am grateful for discovering that.

But I am also learning that capability does not mean I should permanently operate at maximum capacity.

There is a difference between developing yourself and consuming yourself.

I want to become more technically capable. I want to become better at Revit. I want to understand software and code more deeply. I want to understand project systems, governance and information management.

But I do not want my life to become one continuous performance review where every hour must prove that I am improving. Sustainable growth probably requires knowing when to push and when to stop.

I am still learning that balance.

Five Months Later

When I look back at the person who entered this environment five months ago, I can see a noticeable difference.

Not mastery. Not even close.

What changed is the way I look at problems:

• I ask different questions now.
• I look for provenance.
• I look for dependencies.
• I look for the decision behind the geometry.
• I look for recurring patterns instead of treating every issue as isolated.
• I think more about how information survives between people and between stages of a project.

And increasingly, I am interested not only in resolving coordination problems, but in understanding why the system allowed them to become difficult in the first place.

I am grateful for this project. Not because everything about it has been good. But because very early in my career I was given exposure to a genuinely complicated environment with enough scale, repetition and disorder to force me to grow.

There is still always something I do not know. Every asset seems capable of teaching me something new.

I hope that never completely disappears.

For now, five months in, I am simply grateful that I was given an environment difficult enough to reveal capabilities in myself that I did not know were there.