3D models are not just for geometry – they are the foundation of your entire project control framework
The 3D model is not a design tool that happens to be useful for other things: it is the programme’s single source of truth, or it is a liability. There is no comfortable middle ground, argues Lawrence Chapman.

There is a persistent misunderstanding that I encounter repeatedly across major infrastructure programmes, which quietly costs projects hundreds of millions of pounds: the belief that a 3D model is a design tool. It is not – or rather, it is not only that.
A federated, well-governed information model is the most powerful project control instrument available to any programme. The moment you treat it as anything less, you have already compromised your ability to govern cost, schedule, risk and regulatory compliance, not because the model failed, but because you never asked it to do its job.
Let me be precise about what I mean. A 3D model, properly structured against a consistent asset ontology, is a spatial and semantic container for every object that will exist in your asset. Each object carries identity. That identity is the anchor point for everything else: cost codes, work packages, procurement schedules, inspection hold points, handover certificates and safety case references.
When you break that chain, when design objects are not linked to work breakdown structure (WBS) elements, or when model revisions are not governed by formal change control, the downstream consequence is not a BIM problem: it is a programme controls problem. Quantities become unreliable; earned value calculations drift from physical reality; and handover packages lose traceability. In a regulated environment, that is not an administrative inconvenience, but a licence condition risk.
Asset ontology is the backbone of every function
The reason this matters structurally is that a consistent asset breakdown – defined early, maintained rigorously and enforced through your information requirements – becomes the common reference frame across every function. Engineering uses it to organise design deliverables, procurement uses it to structure supply chain appointments, and construction to sequence work fronts. Commercial uses it to certify payment milestones, while safety and quality track hold points and inspection records.
Without that shared ontology, each function builds its own taxonomy, resulting in parallel hierarchies that cannot be reconciled. Integration becomes a manual exercise performed by people who are too expensive to be doing it, and too late to affect decisions that have already been made.
The asset breakdown, work breakdown and functional breakdown structures must be single‑owned, version‑controlled and mandated contractually.
Change control in a model‑centric paradigm
One of the most damaging legacy habits in major infrastructure is the treatment of change control as a document management process – a form to be filled, a register to be updated, a signature to be obtained. In a model-centric paradigm, change control is an information integrity process. Every design deviation must be reflected in the model before it is reflected in the programme baseline. The model is the truth; the document is the record of how we got there.
This distinction matters because it changes accountability. When a scope change is approved, the question is not “has the change notice been issued?” It is “has the affected model region been revised, quality-checked and its downstream dependencies re-baselined?” That is a different conversation, and a more honest one.
The handover and regulatory implications
This is where the consequences of poor model governance become most visible and most costly. As-built verification is not a close-out activity. It is the final proof that what was designed, approved and constructed matches what the asset owner will operate, maintain and, in a nuclear context, present to the regulator as the authoritative record of the physical installation.
When the model has been maintained with discipline throughout design and construction, when every field deviation has been captured, reviewed and incorporated through formal change control, as-built verification becomes a structured confirmation process. The model is interrogated against inspection records, inspection and test plans, and dimensional surveys. Discrepancies are identified, resolved and closed. The result is a verified as-built model that can be handed over with confidence.
When the model has not been maintained, when contractors have been working from outdated revisions, when field changes have been managed informally, and the document record and the physical asset have quietly diverged, as-built verification becomes a forensic exercise. You are no longer confirming what was built, but reconstructing it. That is a fundamentally different undertaking, and it happens at exactly the moment in a programme when every resource is already stretched.
The handover package itself, the information that transfers from the delivery programme to the asset owner and operator, is only as reliable as the model that underpins it. Operations and maintenance teams need accurate spatial data to plan interventions. Safety cases need traceable records of what was installed, where and to what specification. Regulatory submissions need evidence that the as-built condition matches the approved design, or that every deviation has been formally assessed and dispositioned.
The real-world cost of poor governance
On a recent major UK project, 18 months were lost reconciling as‑built geometry with test certificates due to a lack of model governance. This delay was not merely a scheduling inconvenience, it had significant downstream effects on programme delivery, regulatory submissions and asset handover. The root cause lay in the failure to maintain the model as the authoritative record throughout construction. Contractors were working from outdated revisions, and field changes were managed away from the model, resulting in discrepancies between the physical asset and the document record.
Consequently, as-built verification became a forensic exercise, requiring teams to painstakingly reconstruct what had actually been built, rather than simply confirming it.
The process demanded extensive cross-referencing of inspection records, certificates and dimensional surveys, all while resources were stretched thin. Ultimately, this lack of disciplined model governance undermined confidence in the handover package, delayed regulatory approvals and forced operations and maintenance teams to operate without reliable spatial and asset data – a costly lesson in the real-world consequences of poor information management.
A model that has been treated as a design visualisation tool cannot support any of this reliably. A model that has been governed as the programme’s single source of truth throughout its life can support all of it efficiently, with an auditable thread running from the original design intent to the final installed asset.
In my experience, the asset owner’s first question at handover is rarely about the geometry. It is about the data attached to it: the certificates, the inspection records, the material traceability, the maintenance schedules. The model is the structure that makes those answers findable, verifiable and defensible. Without it, handover becomes a document retrieval exercise measured in months, not a structured information transfer measured in weeks.
What this means for programme leadership
I have spent the better part of my career working at the intersection of information management and major programme delivery, across rail, nuclear and energy infrastructure. The consistent pattern I observe is that programmes that invest early in model governance, in establishing who owns the asset ontology, how model changes are controlled and how model data flows into programme controls systems, recover that investment many times over. Not through theoretical efficiency gains, but through avoided rework, faster regulatory submissions and earned value data that leadership can trust.
The programmes that treat their models as design visualisation tools discover, usually around detailed design gate or construction mobilisation, that they are sitting on an enormous amount of unstructured geometric data with no reliable link to cost, schedule or compliance. Recovering from that position is expensive, disruptive and largely avoidable.
Could your model support a safety case today?
As we move into the next cycle of major infrastructure delivery in the UK (SMR nuclear new build, rail modernisation, energy transition), I would encourage every programme director, technical authority and alliance partner to ask a simple question: “If we froze our model today, could we derive a reliable cost forecast, a credible schedule and a defensible safety case from it?”
If the answer is anything other than an unqualified yes, the model is not yet doing its job. That is not a BIM problem but a governance problem. And governance problems are always solvable if you are willing to name them clearly.
The 3D model is not a design tool that happens to be useful for other things. It is the programme’s single source of truth, or it is a liability. There is no comfortable middle ground.
The opinions expressed are the author’s own and do not necessarily reflect the views of his employer.
Keep up to date with DC+: sign up for the midweek newsletter.