Architecture, Engineering and Construction Design Team Documentation
Is this what you really needed?
Every Architecture, Engineering and Construction project produces documentation.
Not just drawings, but a wide range of material that can include Project Execution Plans, design responsibility matrices, risk registers, deliverables lists, resource and capability plans and drawing issue registers.
At their best, these documents are meant to answer some very simple questions:
The approach that is taken to deliver the project.
Who is responsible for what and when?
What risks exist to both the programme and to the design and how will those be managed?
What information will be produced, by whom and at what point?
Do we have the skills, experience and maturity to deliver it?
None of this is controversial.
And yet, on many projects, design teams are presented with an ever growing set of documents that appear to say similar things, often in slightly different ways. It is therefore no surprise that engagement with these parallel BIM documents drops off.
You end up with more templates, more documents and more process but not always better clarity, better delivery, or better outcomes.
More documentation does not automatically lead to better projects.
Is the documentation genuinely helping?
Are documents such as BIM Execution Plans, detailed responsibility matrices, information risk registers, and task information delivery plans genuinely helping design teams deliver better projects?
Or has the way modern standards have been implemented unintentionally made something that was never meant to feel complex unnecessarily difficult to some?
This question does not come from opposition to structure or standards, it's quite the opposite actually, It comes from my own experience. I have worked on successful projects where these requirements were implemented and followed but here's the truth, those projects from a governance and compliance standpoint were only successful because they had dedicated individuals that were explicitly tasked with overseeing compliance.
The documents themselves did not succeed in isolation. They succeeded because capability, knowledge and accountability were present and that was cascaded to the design teams in an advisory and hands on capacity.
Documentation does not succeed on its own. It succeeds when responsibility is actively owned.
Without that stewardship, many of these approaches would have failed. I have the evidence to support this claim.
This is not about excusing design teams, we must transform if we want to deliver better - but perhaps it is about recognising that duplicated and parallel documentation can unintentionally create division rather than shared ownership and understanding.
What do we mean by “parallel documents”?
When I refer to “parallel documents”, I mean situations where design teams are asked to maintain two sets of documents that are trying to answer the same questions, but in different formats, written in different language and often owned by different people.
For example, it is common to see:
A Project Execution Plan describing how the project will be delivered, alongside a BIM Execution Plandescribing how information will be produced, reviewed and shared.
A design responsibility matrix clarifying scope and accountability, alongside separate information responsibility matrices that repeat or reframe the same roles.
A project risk register, alongside an information risk register that captures some risks but not others.
A deliverables list / drawing schedule, alongside a master or task information delivery plan that describes the same intended outputs through a different lens.
Individually, many of these documents have a valid purpose. The issue arises when they overlap, drift apart, or compete for precedence. Design teams are left asking which one is “the truth”, which one is contractual and which one they are expected to work to day to day.
That is where disengagement often starts - not through resistance, but through confusion.
The moment documentation becomes parallel rather than integrated, ownership begins to erode.
A quick clarification on “new” documents
It is also important to be clear: this is not an argument that all documents associated with ISO 19650 or modern information management are unnecessary. Some are absolutely essential and in many sectors they are non-negotiable.
A security management plan is a good example. There are legitimate risks associated with sensitive information and those risks need defined controls, clear ownership and auditable governnce. In those cases, a dedicated document can be entirely appropriate.
The point is not “no new documents”.
The point is: where a new document is introduced, it should do one of two things:
Address a genuinely distinct requirement that is not already covered elsewhere, or
Be integrated into existing project controls so it strengthens delivery rather than fragmenting it.
Design teams are not short of documents
Most design teams already operate within a familiar and established framework of project controls as mentioned above.
These documents are contractual, embedded in delivery and widely understood. With effective project leadership, reinforcing their use is relatively straightforward because they do not feel foreign or optional.
More importantly, these documents already deal with information. They always have and design and engineering has always been about the production, coordination, management and exchange of information.
Information management is not new to design - only the way it is enabled has changed.
What has changed is how that information is structured, reviewed, checked and shared - not the existence of it.
When documentation works against delivery
Problems tend to arise when additional documentation is introduced alongside existing controls rather than integrated into them.
Early in my career, a senior architect once asked me what is now a straightforward question:
“We already have a Project Execution Plan - why do we need a BIM Execution Plan?”
That question left me silent whilst I processed what was asked, it was a valid question and not one that I had been asked or had a meaningful response to and it exposed a deeper issue: why were we running parallel documents describing the same intent, aimed at different audiences, using different language when the intentions were to make things easier for those delivering the projects.
By creating standalone “BIM documentation”, we unintentionally framed BIM as a separate discipline. That framing alone is enough to create distance.
Design teams then infer, often reasonably, that BIM is owned elsewhere.
They experience overlapping documents, duplicated responsibilities and competing messages.
The moment documentation becomes parallel rather than integrated, ownership begins to erode.
When ownership erodes, accountability fades and then quality suffers.
BIM is not the problem
The issue is the divide and the persistent perception that BIM is something done by a BIM team, rather than a set of requirements that sit firmly within design delivery.
That perception did not arise because designers are resistant to change. It arose because BIM has often been positioned through language, structure and documentation as something separate.
In reality, most BIM and information management requirements are not fundamentally new. They are evolved expectations, born from the fact that technology now allows us to do far more with the information and data we already produce.
BIM did not create new responsibilities - it clarified existing ones in a digital environment.
Design teams have always produced, coordinated, reviewed and issued information. What has changed is not responsibility, but opportunity.
Where responsibility must sit
If design teams believe that BIM and information management sit with a separate BIM team, then no amount of additional documentation will resolve that misunderstanding.
Standalone BIM documents can actually reinforce the problem by signalling unintentionally that responsibility lays elsewhere.
If accountability is to be clear, modern information requirements cannot sit outside the documents design teams already use to define scope, programme and responsibility.
They must sit within them.
If the requirements live in the same documents as design accountability, ownership cannot be delegated away.
This is not about hiding BIM. It is about making responsibility explicit.
Language and normalisation
Language plays a critical role in engagement.
Highly technical terminology and specialist labels create distance. They make documentation feel as though it is written about design teams rather than for them.
Clear, plain non technical language does the opposite.
Normalisation matters more than terminology.
When requirements feel familiar, they are adopted. When they feel specialised, they are tolerated at best.
Refinement, not reinvention
This is not a call to abandon ISO 19650, or to step away from structure and governance. It is a call to think differently, reflect critically and ask a simple question: are we helping delivery, or are we hindering it? If we are hindering it, we need to be honest about it - because the responsibility sits with us to change how those requirements are presented.
As information management practitioners, we possess the knowledge and expertise to advise and guide clients and organisations. The challenge is not knowing what “good” looks like - it is conveying that knowledge in a way design teams can relate to, understand and readily apply it. If the requirements cannot be digested, they will not be owned.
Design teams have always managed information and they always will. The focus should therefore be on refining the documentation they already use - expressing modern requirements through familiar language and established structures so that it genuinely supports delivery, reduces duplication and reinforces clear accountability. If, after this, meaningful progress is still not achieved, then the issue is no longer the documentation but a people issue rooted in capability.
Better information does not come from more documents - it comes from better alignment.
Perhaps the real question is not: How do we get design teams to adopt BIM?
But instead:
How do we refine the documentation they are already familiar with and view as their responsibility, so modern information requirements are clearly understood as part of delivering design?
That shift in thinking may be the most important change of all.