Sit through enough kick-off meetings and you will watch one phrase do three different jobs inside an hour. The design team is "on BIM". Document control is "covered". The common data environment has been "stood up". Everybody nods, the minutes record an information strategy, and eighteen months later the client's project director asks what he actually bought. The honest answer is usually a modelling team, a controller with a register, and a licence — three useful things that were never asked to add up to one.
Information management is the accountability for what information must exist, who is appointed to produce it, in which state it sits, who may rely on it, and how that record survives the companies that created it. Building information modelling is a method for producing structured design and construction data. Document control is the gate on issued files. Storage is a disk. A folder convention is a naming habit. Each of those is a real discipline, and none of them, on its own, carries the accountability.
Worth being pedantic about: a BIM manager and a document controller can argue past each other for a year, each assuming the other owns the missing piece.
What information management means
ISO 19650 treats information management as an organisational activity rather than a file type. The appointing party states what information is required — exchange information requirements for the project, asset information requirements for the life of the building. Appointed parties agree how they will produce it. Each information container then sits in a state: work in progress, shared, published or archive. And somebody is named as accountable when those states are breached, when a required container never turns up at all, and when the project information model is supposed to become an asset information model.
An information manager reading that for the first time usually notices the shape of the job before the vocabulary settles. It starts before anyone opens a model, it finishes after practical completion, and it crosses company boundaries, because the architect's issued drawing, the services subcontractor's coordinated model and the owner's acceptance of handover data are one record even though they live in three organisations.
The working test is a question rather than a licence. Without opening anyone's personal inbox, can you say what was required, what was produced, which revision went out and to which organisations, for what purpose, what superseded it, and who is entitled to rely on the current published set? A project that cannot answer that has plenty of activity and no management.
Information management therefore contains BIM and document control. The three are not interchangeable.
BIM is a method for structuring data
Building information modelling produces and uses structured data about the asset: geometry, relationships, properties, and the coordination that follows from them. A model is an information container. A federation is a way of seeing several containers at once. Clash detection, quantity take-off and four-dimensional sequencing are all uses of that structured data, and they are genuinely valuable.
"We are on BIM" usually means a design team authors in a modelling tool, a coordinator federates, and somebody can walk a three-dimensional view in a meeting. All of that can be true on a job that still cannot say which drawing was issued for construction last Tuesday, which comment is closed, or which handover rows the facilities team may trust. The model can be current in the authoring software and unofficial on site at the same moment. The federation can be impressive in week twenty and unqueryable in year two.
BIM answers a question about representation: what is the structured picture of the asset, and how do we coordinate it? Information management answers a question about obligation: what is each appointed party required to produce, in what state may it be relied on, and who is accountable when the representation and the issued record part company? Treat the federated model as the system of record and you will find out at handover that operations cannot use the thing design was proudest of.
Document control is the gate on issue
Document control gives a container a number, a revision, a suitability or status, a transmittal, and a supersede. It stops last week's drawing being plotted as this week's instruction. It keeps a register of what has arrived. Without it, site works to rumour, as anyone who has covered for an absent controller knows.
Necessary, though nowhere near sufficient.
A controller can run an immaculate issued set and the project can still have no information management, because nobody ever said what should exist. The register becomes a history of whatever landed rather than a delivery against requirements. Comments live in unmarked PDFs. Models sit outside the transmittal. Instructions keep moving by email. Handover is a crate of files, because the gate was built for construction issue and never for the asset record.
Document control asks whether this is the file we meant to issue and whether we can prove the issue. Information management asks whether this is the information we were required to produce, whether it is in the right state, and whether it will still be answerable when the issuing company has demobilised.
The two jobs share a desk. They are not one job, and collapsing them is how a team hires a controller, buys a repository, and calls the result a strategy.
The three distinctions held still
| BIM | Document control | Information management | |
|---|---|---|---|
| Object | Structured design and construction data, usually in models | Issued files and their revisions | Accountability for required information across parties and time |
| Typical owner | BIM manager, information author, coordinator | Document controller | Information manager — an appointing-party function, not a software role |
| Success | Coordinated model; fewer clashes; usable structured data | Clean issued set; no unofficial plots; provable transmittals | Required containers exist, have a state, can be queried, and survive handover |
| Characteristic failure | A federation nobody can use after practical completion | The right title, the wrong revision, on site | Storage, a model, or a naming habit offered as a management system |
Hold those rows still and most arguments about "our CDE" become specific. Either the model is uncoordinated, or the issue gate is leaking, or nobody owns the requirement and the state. Those are three different repairs, with different budgets and different people to go and see.
The substitutes that keep getting offered
Storage. A shared drive, a SharePoint library, a project file server or a common-data-environment licence is a place. Places do not decide what must be produced, who may rely on a container, or when a revision is superseded. Permissions on a folder are access control, not a state model, and software that cannot tell you which revision went out, to which firms, and in what condition is a filing cabinet with a password.
A model. An authoring file, an IFC federation, a coordination view, a digital-twin slide in a bid — each is a representation, and representations go stale. They need an issuing rule, a suitability and an owner. Where the only definition of "latest" is whoever saved most recently, you have modelling.
A folder convention. ISO 19650-style naming — project, originator, volume, level, type, role, number — is a retrieval aid, and a good one. It will not create a deliverable that nobody started, move a container from shared to published, or retire a superseded issue. A naming-protocol PDF in the execution plan, sitting above Work in Progress, Shared, Published and Archive folders that anyone can write to, is a convention resting on storage. Four folder names are not four states.
Three more substitutes fail the same way. A BIM execution plan nobody follows is a document. It is not a method. "We are doing ISO 19650" describes an intention, and no software stamp anywhere makes it true. Email and chat carry instructions perfectly well; they cannot serve as the contract record if the contemporaneous file cannot be retrieved. And buying a platform is a procurement event — the management starts when somebody becomes accountable for the required set, not when the invoice is paid.
A test you can run on Monday
You do not need a consultant to work out which of the three jobs you actually have. Ask the project in writing, and accept only a record as an answer.
- What information is required — not what has arrived? If the only list is a register of uploads, you have intake rather than requirements.
- Who is appointed to produce each container, and who accepts it? If the names are "the design team", there is no appointment.
- What is the current state of each container — work in progress, shared, published, archive — and who is allowed to change it?
- Which revision was last released, to which organisations, and for what purpose? If answering means searching mailboxes, document control is leaking and information management has not started.
- When two companies disagree about the latest instruction, which record settles it? If the answer is a person's name, you have a personality rather than a system of record.
- Who accepts the asset information at handover, and what becomes of the project information model once they say yes? If nobody is named, operations will build a third model of their own.
Six answers that point at containers, states and named roles describe information management. Six answers that point at a drive, a federation or a naming spreadsheet describe the substitutes.
Where the accountability has to land
ISO 19650, CDM, the Building Safety Act, NEC, FIDIC, JCT, COBie and the Gulf mandates all assume somebody is managing information across parties and across time. None of them appoints that somebody for you, and that is the gap most projects leave open.
Closing it belongs to the appointing party, and it costs money. Name an information management function in the appointment, with a fee against it and a person's name in the box, rather than adding it to a design manager's existing week. Write the exchange information requirements before the tender goes out, so that bidders price the record you want instead of the one they usually supply. Make the information protocol contractual, not an appendix to a BIM execution plan nobody opens after mobilisation. At tender, ask each bidder to demonstrate a state transition and a superseded revision on a job they finished two years ago, and watch which of the three disciplines they reach for.
If nobody can yet name who owns the requirement and who owns the state, that is Monday's work, with the six questions and a project director willing to sit through the answers.
Read next: The hidden cost of treating email as the contract record, The AECO information lifecycle in one diagram, The most expensive thing on your project is the document nobody can find.