BIM Belongs in Project Management. AI Does Too.

Separating BIM management from project management was the biggest mistake holding back digitalisation in architecture, engineering, and construction.

We treated BIM as a specialist subject. The BIM team wrote the BIM manual, maintained the use-case list, and discussed model requirements. The project management team managed goals, scope, costs, deadlines, and decisions. Both groups worked on the same project, but often from different sources of truth.

The result was predictable. BIM requirements became technically detailed but weakly connected to the reason the project existed. Project briefs described what the client wanted, while BIM documents described a separate digital process. Teams then spent time coordinating the documents instead of improving the project.

That is why we should stop talking about BIM projects. We need projects with BIM.

AI could repeat the same mistake

Now AI is entering the industry, and the same pattern is appearing again. Organisations appoint AI leads, create AI strategies, and launch AI pilots beside their normal project processes. If we are not careful, AI management will become another silo with its own vocabulary, workshops, and documents.

A project does not need a parallel AI reality. It needs clear definitions that people, software, and AI can use. AI should help interpret requirements, generate proposals, compare alternatives, and find deviations. It should not replace the work of deciding what the project must achieve.

The important question is therefore not, "Where can we use AI?" It is, "What must this project deliver, under which conditions, and how will we know that it has been fulfilled?"

Start with goals and boundary conditions

This is the path we are taking with pragmaticBIM. What already exists starts before model requirements. The project team selects project goals and records boundary conditions. These choices determine the relevant use cases, and the use cases determine the data requirements.

The chain is simple:

Project goals and boundary conditions → use cases → information requirements → checks

This reverses the usual process. Instead of copying a BIM manual from the last project and deleting what looks unnecessary, the team begins with the purpose of the current project. Every requirement needs a reason. If no goal or use case justifies a requirement, it should not be imposed on the delivery team.

Connect the room programme to the same source

Our next step is to bring project definition closer to actual use. The team defines usage scenarios: who uses a place, for what activity, with which capacity, equipment, environmental conditions, access rules, and relationships to other spaces.

Those scenarios configure the room programme. A room is no longer just a name and an area in a spreadsheet. It becomes a structured set of requirements derived from how the building is expected to work.

The same source then produces the project brief. That brief is not a polished document detached from the underlying requirements. It is a view of structured, versioned data that can also feed models, schedules, IDS files, and other project tools.

This is what it means to treat requirements like code. Requirements are structured so software can read them, versioned so every change remains traceable, and checkable so fulfilment can be tested. They are not frozen in a PDF. They evolve through controlled changes while preserving one reliable source of truth.

Creation will become cheap. Definition and checking will not.

AI will make the creation of text, drawings, images, schedules, and model content faster. Creation will be less of a limiting factor. The scarce capability will be defining the right outcome and checking whether a delivery fulfils it.

AI will make an existing problem worse: the false correlation between the quality of content and the quality of its presentation. AI can turn weak requirements into a polished, convincing report in seconds. The presentation improves, but the underlying definition does not. At the same time, a plain data file can contain an excellent, precise specification.

When requirements are structured, presentation becomes one output among many. The same source can generate a clear web page for a decision-maker, a room programme for a planner, and machine-readable checks for software. Each view can look different without changing the contractual meaning.

Open definitions, paid tools

The best part is that the raw data does not need to be locked into a vendor platform. The underlying Elementplan data standard is open source and freely available.

You do not pay for access to the definition of your project. You pay for tools that make the data easy to configure, review, version, publish, and check. That distinction matters. Open data protects the project; useful tools earn their place by saving work.

Digitalisation in AEC will not advance through another isolated discipline. BIM and AI belong inside project management, connected to the decisions that define success. One project, one chain of requirements, many ways to use and verify the data.

See how pragmaticBIM connects project briefing and BIM requirements