BIM, Information Management and the Illusion of Change

I was recently reflecting on my career and realised I have now spent over 16 years working across estimating, CAD, architectural design and technology, BIM and Information Management.

During that time, I’ve held roles including Estimator, CAD Technician, BIM Modeller, Architectural Technologist, BIM Manager, Consultant, and various senior and lead positions within some of the largest consultancies in the world including Arup, AtkinsRealis and more recently Amentum. I’ve worked across Residential, Education, Healthcare, Commercial, Defence, and Nuclear projects, occupying both hands-on delivery roles and strategic, advisory positions.

What links all of this experience is a consistent focus: helping organisations strengthen their BIM and Information Management readiness - not through theory, but through practical change in how projects are actually delivered.

I entered the industry just before the point of genuine transition. Some will say it was already happening...

My early career was rooted in architectural technology, defining modelling strategies, CAD standards and library content. Then BS 1192 and PAS 1192 entered the mainstream and suddenly organisations were mobilising at pace - moving from largely manual, document-centric ways of working towards more structured digital methods.

For many practices, this was not a gentle evolution. It was a shock to the system but only for those rooted in the projects.

Digital transformation does not start with software

My first formal BIM Manager role made this painfully clear. The brief was simple on paper: digitally transform the practice. The reality was far more complex.

In some cases, team members were still using drawing boards. Others were producing CAD outputs and tracing over the top of them to create visually appeasing conceptual feasibility drawings with little consistency, structure, or governance. Jumping straight to Revit was neither realistic nor sensible but that didn't always prevent it from happening.

The starting point had to be a digital strategy.

That meant:

• Understanding current ways of working - warts and all

• Defining a realistic and achievable target state

• Setting out how we would get there, by when and with whom

• Mapping roles against skills, not job titles

• Identifying capability gaps

• Developing role-based training, upskilling pathways and assessments to validate competence

Only then did the technology make sense.

Digital transformation is not a software rollout. It is a capability journey.

BIM was never about “pretty models”

I arrived at a time when organisations were no longer buying authoring tools simply to produce better drawings or impressive 3D visuals. They were starting to ask more grown-up questions:

• How do we leverage this technology for efficiency and coordination?

• How do we reduce risk?

• How do we improve quality and consistency?

• How do we extract greater value from our information?

This is where most of my experience has been focused: establishing Information Management landscapes and frameworks, writing standards, methods and procedures, developing workflows, guidance and training and embedding those approaches on live projects.

Some of those projects - including award-winning schemes such as Haverfordwest High School - were recognised not because of flashy technology, but because of better collaboration, better information, stronger client engagement, innovation and my personal favourite of them all, involving stakeholders directly in the design decision-making at each stage of the project.

The documentation problem no one wants to talk about

Over time, one recurring barrier to BIM and Information Management adoption has become impossible to ignore: the duplication and often contradiction of project documentation.

Examples are everywhere:

• BIM Execution Plan vs Project Execution Plan

• Responsibility Matrix vs Design Responsibility Matrix

• Risk Register vs Information Risk Register

On paper, these documents appear distinct. In practice, they often cover the same ground, ask similar questions and are produced in isolation from one another and frequently by different people, at different times and for different audiences without anyone stepping back and questioning if they need both or if they align.

This raises a more uncomfortable question:

Why do we persist in creating parallel “BIM documents” when design teams already manage mature, well-understood project controls?

In my experience, this duplication does more than confuse - it actively undermines delivery. I have lost count of the number of projects where the BEP and PEP contradict one another; where responsibilities are defined differently across documents.

When that happens, teams do not see BIM as supportive. They see it as noise and they want to detach themselves from it.

The underlying issue is not that BIM introduces new requirements. It is that those requirements are often lifted out of existing project controls, repackaged into standalone BIM documentation and then presented back to the team as something separate.

This is where I believe in part we have gone wrong.

Rather than creating new BIM-specific documents, we should be looking to enhance and extend existing project documentation. Project Execution Plans, Risk Registers, Responsibility Matrices and Design Management Plans already exist for a reason. They are familiar, contractual and embedded in how projects are actually run.

So the obvious question becomes:

Why are we not expanding these documents through structured addendums or integrated sections to draw out the Information Management requirements that ISO 19650 is asking for?

Doing so would:

• Reduce duplication and contradiction

• Anchor Information Management within established governance

• Make responsibilities clearer and more credible

• Remove the perception that BIM is “extra” or optional

Most importantly, it would stop asking design teams to learn an entirely new documentation ecosystem and instead show them that Information Management has always been part of good project control, even if we did not always label it as such.

A simple example: PEP with an Information Management addendum

Instead of producing a standalone BEP alongside an existing PEP, the structure could look something like this:

Project Execution Plan (PEP)

• Project objectives and success criteria

• Programme and delivery milestones

• Roles, responsibilities and decision-making authority

• Design management approach

• Risk management strategy

• Change control and approvals

PEP – Information Management Addendum

• Information delivery strategy aligned to project stages

• Information responsibilities mapped to existing roles

• Common Data Environment principles and workflows

• Information exchanges and deliverables

• Information risk considerations (integrated with project risk)

• Compliance requirements aligned to ISO 19650

Same document. Same governance. Clearer accountability.

No duplication. No contradiction. No “BIM paperwork” running in parallel.

BIM as a bolt-on, not a foundation

This perception has consequences.

Many designers do not have a particular interest in BIM or Information Management and, in part, that is the industry’s fault. We fixated on standards heavy, compliance-led approaches that felt constraining, fragmented and burdensome.

As a result, BIM became seen as a bolt-on owned by specialists, rather than a set of principles that underpin good project delivery.

There are cases where Information Management Services legitimately require dedicated teams - particularly where these are value-add, advisory services provided alongside design. But the objective of any BIM implementation role should be to upskill teams to a point where that role becomes obsolete, allowing it to evolve into something else that supports the wider business.

The problem is exacerbated by:

• Multiple standards in play simultaneously

• Organisationally invented interpretations of BIM

• Misunderstanding (or misapplication) of standards by BIM specialists themselves

• Regions and sectors defaulting to dedicated BIM roles

Personally, I do not believe we need dedicated BIM teams in most cases.

BIM and Information Management were never intended to layer design teams with additional roles. They were about clarifying responsibilities and assigning them to existing roles.

What actually happened is more subtle and more problematic.

Some existing roles felt they did not have the required capability. Others decided those responsibilities were “not part of their job”. Those responsibilities were then parked with a dedicated BIM team, unintentionally reinforcing the idea that “they do BIM” and “we do design”.

The question no one asks

What I find most intriguing is this:

How did those dedicated BIM and Information Management professionals acquire their knowledge in the first place?

They upskilled. They learned. They adapted.

Exactly as the wider industry is being asked to do.

Yet somewhere along the way, we accepted the narrative that BIM is a specialist activity, rather than a professional capability that can and should be developed within existing roles.

Rethinking the problem

If we want BIM, Information Management and ISO 19650 to succeed at scale, we need to change the conversation.

This is not about asking design teams to become something different. It is about helping them modernise how they work, using more efficient, structured and informed ways of delivering the same core professional outputs.

The objective was never to change the core of what designers and engineers do. It was always about improving how they do it.

That means:

• Integrating BIM and Information Management into familiar project controls, rather than duplicating them in parallel “BIM” documentation

• Removing unnecessary layers of process that add administration but little value

• Focusing on capability and behaviours, not job titles or specialist labels

• Treating Information Management as a core part of professional practice, not a bolt-on service

When implemented well, BIM and Information Management should feel almost invisible simply a better way of planning, coordinating, communicating and managing information.

The real challenge is not changing the destination of design teams, but modernising the route they take to get there.

Half the battle is perception. The other half is implementation.

And it is precisely at that intersection that digital transformation either succeeds or quietly fails in my experience of course.