Lesson 1, Topic 1
In Progress

Information Requirements Overview

In this section, we will be looking at information requirements; what they are, the different types, how they all relate to each other and how they should be developed.
To begin with, let’s refresh ourselves on what information requirements actually are. The clue is actually in the name – this is simply information that is required for some reason or another by the appointing party.

This could be anything from the gross internal floor area values of the building to the project programme to energy consumption rates for a proposed system. This is information that will be required at some point or another to address a functional need; information that can be provided by the delivery team during the delivery phase of the project.
ISO 19650 – the international standard for BIM delivery – defines four different kinds of information requirements. These are:

• Organisational Information Requirements, or OIR
• Project Information Requirements, or PIR
• Asset Information Requirements, or AIR and
• Exchange Information Requirements, or EIR

Whilst the similar sounding names and acronyms may at first seem a little confusing, it is important to remember that these are all just slightly different facets of one client’s (or appointing party’s) overall information need, categorised by their scale / level and the different details they provide on this need. In this presentation, we will be looking at each of these, how they differ and how they are developed as part of a single management strategy.
High-level Information Requirements (OIR and PIR) establish the overall purpose of the works and define why information is needed.

Detailed Information Requirements (AIR and EIR) specify how information should be produced and exchanged.
Organisational Information Requirements (OIR)

High-level requirements that define the information needed to meet the appointing party’s strategic business objectives and the needs of its asset management system.

OIR ensure the correct information feeds back into an organisation to support wider business decisions. For example, the information needed by a rail operator is very different to that of a manufacturing facility. OIR are the starting point after which all other information requirements are defined.

Project Information Requirements (PIR)

High-level project-specific requirements that define the information needed at key decision points during the delivery of an asset. Key decision points are when the appointing party makes a decision upon information provided by the delivery team and defines the information delivery milestones.

Asset Information Requirements (AIR)

Detailed requirements that outline the information needed to operate and maintain the asset throughout its lifecycle. AIR are formed from OIR and define what information is required and how it should be delivered for the asset information model (AIM).

The goal of AIR is to ensure the right people have access to the right information to effectively maintain and operate the asset.
Exchange Information Requirements (EIR)

Detailed appointment-specific requirements that precisely specify what information is needed at each information milestone, to enable parties to complete necessary activities during the delivery and operation phases of an asset. EIR are collectively defined from the OIR, PIR and AIR, and are developed per appointment.

The appointing party sets EIR for their appointment with the lead appointed party, and the lead appointed party sets their own EIR for each appointment with their appointed parties.
What about the deliverables:


Project Information Model (PIM) is the ‘…information model developed during the design and construction phase of a project.’ The requirements for the Project Information Model are set out in Exchange Information Requirements (EIR), it is likely to consist of a federated building information model, non graphical data and associated documentation.

The project information model is developed progressively, first as a design intent model then a virtual construction model.


An Asset Information Model (AIM) is a model that compiles the data and information necessary to support asset management, that is, it provides all the data and information related to, or required for the operation of an asset.

An AIM can provide graphical and non-graphical data and information as well as documents and metadata. It can relate to a single asset or to a portfolio of assets. An AIM can be created from existing asset information systems, from new information, or from information in a Project Information Model (PIM) that was created for the construction of a new asset.

Firstly, let’s look at how we currently approach these as part of the delivery team on projects.

Through project experience, we will already be roughly familiar with EIR and AIR and the role that these play in the project.

The typical understanding amongst design professionals is that the project’s EIR inform development of the project’s BIM execution plan and the technical requirements therein, whilst the AIR sets out the required content of the project’s structured data (e.g. the project’s maintainable assets and required COBie fields for these assets), whilst the role of PIR and OIR aren’t as well understood. Therefore, the current approach towards information requirements on most projects is to focus exclusively on its EIR and AIR for with the intent to progress with the project, whilst the project’s OIR and PIR are developed separately and in isolation, if they are considered at all!

This approach is not particularly effective. Whilst the project’s EIR and AIR are arguably the two most important sets of requirements for the project’s digital delivery as they contain the requirements which are of direct interest to the delivery team and drive the production of the project’s BIM execution plan, these only tell part of the story.

It is important to remember that OIR, PIR, AIR and EIR are all intrinsically related to each other. As previously mentioned, these are simply different facets of the appointing party’s information need and, ideally, they should be treated as such, as respect for the hierarchy and the interrelations between these is essential for delivering information that will genuinely add value for the appointing party.
So, with that in mind, rather than jumping straight to developing a project-specific set of EIR and AIR and moving on from there, a set of PIR and AIR should be derived from the organisation’s (ideally pre-defined) organisation information requirements as a means of ensuring that only information which is genuinely needed by the organisation for its operations / activities will be produced.

These can then inform development of the project’s EIR for both the project’s delivery and operational phases, and these EIR can then address other factors that relate to the project’s how and when, i.e. the project’s Information Delivery Milestones, Information Standard, Information Production Methods and Procedures as well as any Reference Information and Shared Resources.

This approach, although admittedly depending on the appointing party having enough competence and experience in BIM to have defined a set of robust OIR, will result in the best outcome as it ensures that all of the project’s requirements are derived from what the ORGANISATION needs to operate successfully, rather than just what the project needs in order for the building or system to be handed over successfully.

Although the complex relationship between buildings, BIM and business is often not at the top of the designer’s priorities when it comes to embarking on a new project, this approach will go a long way in developing a better understanding (and therefore relationship) with the appointing party, not to mention delivering more useful information at the end of the project.

Therefore, this approach could be considered to be far more likely to result in achieving that status as a ‘trusted advisor’ and the repeat work that comes with this status.
Once we have the required information defined, we can then present this to the project’s lead appointed party (contractor etc.) who will develop a BIM execution plan in response, in a process vaguely analogous to exchanging the contents of your Amazon basket for an order confirmation email.

As we know, the BIM execution plan is the single source of truth for defining how BIM will be exploited on the project to deliver these requirements, and thus the four main components of the BEP should be developed as genuine responses to these requirements, incorporating any specific additions from the lead appointing party.
In other words, the project’s information requirements set out WHAT is required to be produced, whilst the BIM Execution Plan (BEP) sets out HOW, WHEN and WHERE. Ensuring that the project’s information requirements are well defined, and the BEP well written in response is critical in ensuring that the appointing party gets everything they are paying for, not just the building itself.
Once the information requirements have been defined and the BEP produced in response to these, the project can then commence. As time passes, more and more information will be produced (forming what is known as the Project Information Model during the delivery phase of the project), gradually increasing in geometric and non-geometric information along the way. When the building is handed over, this then becomes the Asset Information Model, which can then be managed and periodically updated over time to incorporate new information that is produced over the course of the operational phase of the asset (e.g. maintenance activities etc.).

So, along the whole journey, what we have is an information model that is tailor-made – that is, specified by the BEP which is specified from the appointing party’s information requirements. It is an information model that is scalable – it goes from existing only in theory in the earliest days of the project, to gradually incorporating more design and construction information over the delivery phase, to a complete as-constructed model accurately representing the built asset which then goes on to accumulate operational information during the many decades that the asset will be in operation.