An owner can receive a model at the end of a project and still have no practical way to use it. Geoff Hoffman and Kyle Hudson described that gap in a 2019 Constructrr conversation. BIM had often been used in separate design and construction workflows, while owner teams lacked the resources, requirements, or internal alignment needed to carry the information into operations.
The owner-side work begins before the handover. It starts by deciding who needs the information and what they will do with it.
Begin with the people who will use the information
Kyle Hudson used an airport to show why one model does not serve every stakeholder in the same way. Facilities, leasing, project delivery, and marketing teams may each need different information. Treating them as one audience can make standardization easier while leaving part of the organization behind.
Kyle's approach was to identify the stakeholders, learn what matters to each group, and understand how each would use the information. That discovery gives the owner a basis for deciding which requirements belong in the project.
Write the requirement while the data is being created
Geoff Hoffman described a useful BIM as a well-defined set of owner requirements covering graphical and non-graphical information. Geoff added, “let's collect the data as it's being created.”
The architect can use those requirements during design. The construction team can add equipment, testing, and turnover information as the work is installed. Waiting until the end turns the handover into a search for records that were never structured for the owner's use.
Geoff also emphasized buy-in across the organization. Executive support could authorize the change, while the people managing assets day to day still needed time and support to make the process work.
Ask for a manageable set of data tied to a real use
Kyle Hudson returned to the information in BIM as a major source of owner value. Geoff Hoffman and Kyle Hudson also discussed lighter requirements when a full data-standard request was too broad for an owner's actual goals.
The point was not to avoid standards. It was to connect the standard to a use. Space management, asset maintenance, leasing, and project delivery may require different fields. A smaller, clearly owned requirement is more useful than a large handover that no receiving team can explain.
Before procurement, the owner can turn a planned use into a short information brief: who needs the data, which fields support their work, and when those fields must be produced. The delivery team can then price, create, and check a requirement tied to an actual use.
By the time turnover arrives, the information should already have an owner, a purpose, and a place in the next decision.
