BIM Project Handover: What Information Does the Operations Team Need After Construction?

Why does the model look complete while the operations team cannot use it?

The construction team needs information to build and coordinate the works, while the operations team needs information that helps after occupancy. A technician may see the location of an air handling unit in the model but still be unable to schedule its maintenance without its approved identifier, its manual or a link to its asset record. An element may still carry its design description even though the contractor installed an alternative the owner approved. The element’s location is then visible, but its data does not match operational reality.

ISO 19650-3:2020 places information management in the context of the operational phase of assets and the information exchanged during it. The UK guidance explains how information needs can be linked to events during operation, such as maintenance or a change to an asset. So the data required should be defined by the decisions it will support, and then tested in the system where it will be used. ^{[1, 2]}

How does the owner write asset information requirements?

Start with a task. For example, a maintenance supervisor needs to identify the unit serving a particular area before raising a work order. Ask what information they look for today, where they expect to find it, what data must be up to date, and who checks it. That description then becomes a requirement that can be delivered and tested. If the same fields are not needed for another asset category, scope them by category instead of repeating them on every element.

A requirement might read: “For every air handling unit included in the handover, provide a unique identifier, its approved location, the system it belongs to, the model of the unit installed, and a link to its operation and maintenance document.” This is a teaching example for a hypothetical project, not a set of fields the standard imposes on every project. The owner adds how each field will be checked, when it becomes mandatory, who provides it and who reviews it. ^[2]

Before contract documents are issued, discuss the requirements with representatives of operations and information systems. The maintenance system may need an identifier of a set length or a location code in a particular format. The maintenance team may want warranty documents but not want the same files copied into every record. Settling these details early lets the contractor create records correctly from the start.

What should be handed over with an asset?

Set the level of data according to the asset’s use and importance. For a mechanical unit, the package might include the approved identifier, the room, the system, the manufacturer, model and serial number where available, operating and warranty documents, and a reference to test and commissioning results as the contract requires. If the facility has an approved maintenance programme, the owner decides how the data links to it and who reviews the manufacturer’s recommendations before they become scheduled tasks.

It helps to separate information about the equipment type from information about each installed unit. Two units of the same model can share one manual, while each has its own location, identifier and serial number. This makes the manual easier to update and avoids confusion where units look alike. Agree a way to show missing information, such as a field marking it as awaiting verification, rather than filling fields with generic values that are hard to spot later.

The operations team also needs to know which version is approved. The handover states where documents are kept, their approval date and how they link to the asset. If a link only works on the contractor’s network or in an individual’s account, it may become unusable after handover. Test access from an account belonging to the owner, respecting permissions for assets or building data that need protection. ^[2]

Is an IFC file or a separate data file enough?

IFC allows data about built assets to be described and exchanged under an open specification. buildingSMART states that IFC 4.3 is published as ISO 16739-1:2024. But adopting the format is still a decision that requires specifying the exchange version, the required fields and how the receiving system will read them. A file that opens in a model viewer may need further processing before equipment identifiers or properties reach the maintenance management system. ^[3]

The owner may also ask for a structured spreadsheet, a native model or approved documents, depending on operational and contractual purposes. The answer starts with one question: how will the receiving party read and maintain the information after occupancy? If the target system imports a spreadsheet with a defined field dictionary, the link can be tested before the handover date. The contract states which file is the approved version and how differences between files are resolved. ^{[2, 3]}

How do you test the handover before receiving the final package?

Test a sample early, with the operations team involved. The owner picks assets that represent more than one system, then traces each one from its site label to its data record, the model and its documents. The sample is checked for duplicate identifiers, missing mandatory fields, links that do not open and model numbers that do not match the equipment. Some rules can be checked automatically, but checking reality needs a site sample in line with the project plan.

After reviewing the sample, try carrying out a complete operational task. Ask a technician to find a piece of equipment named in a fault report, confirm its location, open its manual and create a test work order in the target system. Record where the process stopped and what data they had to look for elsewhere. This test reveals the important difference between “the file opens” and “the information is usable”. The results can be included in the handover acceptance criteria agreed by the parties. ^[2]

What happens when equipment is replaced after handover?

Imagine an office building where a pump is replaced during operation. The team keeps the record of the previous asset in line with the owner’s policy, documents the new pump and links its data to the location, the system and the new documents. If some data lives in the model and some in the maintenance system, the team knows who updates each record and how consistency is checked. This is a hypothetical example of managing a change to asset information, not a single rule for naming every pump.

The owner and the operations team agree in advance which events trigger a data update, such as a replacement, a change to a system’s configuration or a reallocation of space. They also decide where the change is approved and who can see earlier versions. The update mechanism is applied at the level the service needs; not every file has to change with every maintenance task if the operational information is managed in its own dedicated record. ^{[1, 2]}

How does project scope differ in the Gulf?

The licensing authority in a city may publish requirements for submitting building models. Dubai Municipality, for example, publishes circulars on the use of BIM in its procedures. Check the version in force and the project scope with the relevant authority. The requirements for submitting a model for permits and the owner’s requirements for receiving and operating asset data are two documents that may differ in audience, fields and acceptance method. It is wrong to assume that a model approved for a permit is ready to import into the maintenance system. ^[4]

On projects with several contractors, it helps to agree location names and system coding before work starts on handover data. The project may need names that can be searched in both Arabic and English, depending on the operations team, while keeping the same identifier in every version. This is a project-specific decision that can be checked by testing search and import, not just by adding a second column to the file.