Lesson 1,
Topic 1
In Progress
Information Requirements Overview
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.
• 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.
Detailed Information Requirements (AIR and EIR) specify how information should be produced and exchanged.
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.
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.
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.
PIM
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.
AIM
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.
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.
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.
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.
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.