Model, Process, People

It is easy to think BIM *is* the model — the thing you see on screen. But the model is only the artefact. Around it sit two things without which it delivers almost nothing.

The process is the way of working: the client states what information they need; the delivery team plans how they will produce it; everyone works in one shared, controlled place; the information is checked before it is trusted; and it is handed over in a usable form at the end. The people are the roles and relationships that make this happen — who is responsible for what, who checks whose work, who talks to whom, and the agreements that bind them. Software sits *inside* the process, as one of the tools people use. It is real and necessary — but it is the smallest of the three legs, and the one that matters least to whether BIM succeeds.

Information in BIM is not produced in a heap; it flows through a lifecycle, and the process is what gives that flow shape and repeatability. The client (or 'appointing party') states their information requirements — what they need, to what standard, by when. The delivery team writes a plan for meeting them (a BIM Execution Plan). Everyone produces their work in a single shared, access-controlled place — the Common Data Environment — where information moves through clear states (work-in-progress, shared, published). The information is checked and validated before anyone relies on it. And at the end it is handed over as a structured asset the owner can actually use.

This is what the international standard ISO 19650 codifies (Module 5 covers it properly). The point for now is simpler: BIM is a *managed flow of information*, and the management — not the modelling — is where most of the value and most of the risk live.

A perfect model built by one person in a silo still fails, because BIM's core value — coordination, reliable shared information, a clean handover — is inherently collaborative. It only works when many parties model, share and check *together*, to common rules.

So BIM is organised around roles. Formally, there is the appointing party (the client), the lead appointed party (who coordinates delivery), and the task teams (each discipline). Practically, teams also carry BIM-specific roles: a BIM manager who sets and governs the standards and the CDE, a BIM coordinator who runs clash detection and keeps the federated model honest, and modellers who build to the agreed rules. None of this is about software features; it is about people knowing their responsibilities and working to a shared method. Get the people and their agreements right and mediocre software still delivers BIM; get them wrong and the best software delivers expensive chaos.