Start With the End in Mind — Why Asset Information Requirements Must Be Defined Before Design Begins

The AECO industry now has tools and standards that were not available two decades ago. 3D BIM. 4D construction scheduling. 5D cost integration. ISO 19650 information management. The capability exists to deliver projects that are not just physically complete at handover, but informationally complete, ready for the client to operate from day one.

In practice, that rarely happens. Not because the tools are missing. Because the questions are asked in the wrong order.

Most projects start by asking: what does the design need to produce? The BIM requirements are written for the design team. The LOD levels are specified. The model parameters are defined. The 3D model is developed with care and technical rigour.

Then construction begins. Then handover approaches. And then, often late and sometimes never, someone asks: what does the client actually need to run this building?

The information that answers that question should have been defined before the first design decision was made. Not at handover. Not during construction. At planning stage, before the TOR was written.

What I have seen on complex projects

The pattern I have seen repeatedly on complex projects is consistent. A client invests in a thorough BIM requirement for the design phase. LOD levels are specified. Naming conventions are defined. Model parameters are set. The design team works to a clear standard.

But the requirement stops at design. When construction begins, a different question emerges: what happens to all that information during construction? Who is responsible for maintaining it? What additional information needs to be added as elements are fabricated, installed and commissioned?

And when handover approaches, a third question surfaces: does the information in the model actually serve the facilities management team? Is it structured for operational use, or only for coordination and clash detection?

These questions should have been answered at planning stage, before the design BIM requirement was written. Instead they arise at the moments when they are most disruptive and most expensive to address.

The second gap — design information versus operational information

There is a subtler problem inside the same issue. Even when BIM requirements are well written, they are usually written by people thinking about design delivery. The parameters specified for coordination and clash detection are not the same parameters the maintenance team needs to manage the asset.

A well-structured 3D model built for design coordination contains geometry, relationship data and coordination information. What the FM team needs is different: equipment specifications, maintenance schedules, access routes, warranty records, installation dates, operational parameters for every significant element in the building.

These are not the same things. And if nobody defines what the operational information requirements are before the model is built, the model will not contain them, regardless of how detailed and technically correct it is from a design perspective.

The Revit model is not the deliverable. The information in it is the deliverable. And that information needs to be planned with the end in mind.

The cost dimension — where decisions get made without information

There is a third gap that sits alongside the information management problem, and it is equally significant.

Every project has elements with major cost and lifecycle impact. Some of these are structural. Some are mechanical or electrical. Some are specialist equipment specific to the building's use. When these elements are not identified and costed at planning stage, design decisions get made without a clear understanding of their financial consequences.

The tools for this exist. 5D BIM connects cost and quantities directly to model elements. Cost estimating software used alongside the 3D model can show the financial impact of design decisions in real time. This is genuinely powerful when it is used as a decision-making tool during design, not just as a reporting exercise afterwards.

What I have seen consistently on complex projects is that the cost information exists, but it does not drive decisions. Design choices get made based on functional preference or end-user requirements, and the cost implications are calculated after the fact. By then, changing course is expensive and disruptive.

5D only works when it is connected to decision-making from the beginning. And decision-making only works when the right questions are asked at planning stage, before the design process creates momentum that is difficult to reverse.

The full building lifecycle, from planning to end of life. Information requirements for all stages must be defined at planning, not discovered at each transition.

What ISO 19650 actually says about this

ISO 19650 is clear on the sequencing. It does not treat design, construction and operations as three separate phases with three separate information requirements. It treats them as milestones in a single continuous asset lifecycle, governed by a single information management framework from inception to end of life.

The standard defines the Asset Information Requirements at the top of this hierarchy: what the client needs to operate and maintain the asset over its lifetime. From that, the Exchange Information Requirements are derived, defining what information the project must deliver, in what format, and at which stage. From that, the BIM Execution Plan defines how the project team will produce and manage that information.

The sequence matters. AIR first. EIR second. BEP third. Not the other way round.

In practice, most projects start with the BEP, or with a design BIM specification that functions as a BEP without the EIR behind it. The operational information requirements are never defined because nobody asked the question at the start. And the Exchange Information Requirements, which should define what moves between parties and when, get written to serve the design process rather than the full asset lifecycle.

What this means in practice — starting from the end

The principle is straightforward, even if the implementation requires discipline. Before the TOR is written, before a designer is appointed, before a 3D model is opened, ask what the building owner will need to manage this asset in 10, 20, 30 years.

That question produces a different TOR. One that covers not just design BIM requirements but construction information requirements and operational information requirements. One that specifies not just LOD levels but what parameters must be populated on high-cost, high-lifecycle-impact elements. One that treats 3D, 4D and 5D not as optional tools but as connected parts of a single information framework serving the asset from planning to end of life.

The technology to do this exists. The standard that defines it exists. What is often missing is the decision, made early enough, to start from the end rather than from the beginning.

When that decision is made at planning stage, when the AIR is defined before the TOR, when cost is tracked through 5D from design inception, when the model is built to serve operations and not just coordination, the result is a building that is genuinely ready from day one. Not physically complete and informationally empty. Complete in both dimensions.

That is what the available technology, properly applied from the right starting point, can deliver. It requires asking the right questions at the right time. The right time is before design begins.