Lesson 1, Topic 1
In Progress

Information Requirements Copy

OIR
Organisational Information Requirements describe the information required by an organisation for asset management systems and other organisational functions. That is, they are organisational-level information requirements rather than asset-level or project-level information requirements.

PIR
PIR focuses on information that the client requires at key decision points during a design and construction project delivery. While creating PIR, the client should take into consideration the project plan of work and tie its key decision points with the schedule.
AIR
Asset Information Requirements (AIR) are part of the Building Information Modelling (BIM) process, defining the graphical and non-graphical data, information and documentation needed for the lifetime operation and management of a built asset. ISO 19650 defines AIR as ‘information requirements in relation to the operation of an asset’; an information requirement is defined as ‘specification for what, when, how and for whom information is to be produced’.

EIR
The exchange information requirements (EIR) define the information that will be required by the employer from both their own internal team and from suppliers for the development of the project and for the operation of the completed built asset. Relevant extracts from the exchange information requirements are included in procurement documents for the appointment of each supplier appointed directly by the employer, which may include; advisors, consultants, contractors and so on.
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 than 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.
Before undertaking the project delivery phase consideration must be given to specifying the information as well as the physical asset (for example, a brick, a boiler or even an entire building).

Information management is about making sure that the right information is delivered to the right destination at the right time to meet a specific purpose. Information requirements consider both structured and unstructured information.
Information management is about making sure that the right information is delivered to the right destination at the right time to meet a specific purpose. Information requirements consider both structured and unstructured information.
According to the ISO 19650 series, information should be created for a specific purpose – for someone to make use of it. Information requirements specify the precise information someone needs so that when it is received they can action that purpose successfully.

Working collaboratively means that we should always create information with its use in mind.
Information provider – individual/team/ organization who generates and/or produces the information.
 
Information receiver (specifier) – individual/ team/ organization who will receive the information (for its own use or on behalf of others).

During an asset’s lifecycle, most people within the appointing and appointed parties will be both.

For example, information could be needed to update a spreadsheet, to be used as reference information when conducting a risk assessment, adding asset information, or to create a model.

From an information management perspective, and to define information requirements we have to turn this workflow around.

The starting point is that the information receiver (specifier) stipulates their requirements. To do this they first have to understand the purposes for which they require information.

The information required can then be defined and communicated to the information provider, so they then understand the scope of what they need to produce. ISO 19650 Parts 2 emphasizes this by each starting with the assessment and need activity.

You should not provide someone with information unless they have told you what they require.
Given that delivery and/or operational projects are rarely planned holistically, the way information is generated tends to be ad-hoc and reactive. This also means that software applications are rarely used to their full potential.

These issues create risk before any related activity even starts. Furthermore, indiscriminate use of technology can exacerbate this by generating more information than can be handled or by masking the lack of a plan.
Without understanding what information is needed, it is very difficult and inefficient to plan how any such information is going to be delivered, the timescales required, and the resources needed.

Good quality information requirements are vital to resolving this situation.
Once defined they inform:

• the tendering and appointment process
• information delivery planning
• information generation and delivery
• the authorization and acceptance process by comparing deliverables against requirements
• the appropriate use of the information.
Describing information generally is subjective. However, information in accordance with the ISO 19650 series can be described across four main facets:

1. Purpose (the need that the information will fulfil). For example, to convey fire performance of elements.
2. Content, this is split into:

• Content summary (the overall content of the information). For example fire strategy information or elemental cost information.
• Content breakdown (geometrical and alphanumerical information across an object hierarchy). For example, a wall with the property ‘fire rating’ or for the project, a property called ‘cost limit’

3. Form (how it is presented). For example, a schedule or a drawing.
4. Format (how it is encoded). For example, PDF or IFC(-SPF).
Level of information need is a framework for defining the quality, quantity and granularity of information.

Historically in the UK, level of definition was the term used to refer to the aggregate of level of detail and level of information. In practice, it has been found that understanding the concepts and principles for defining information requires a clearer framework. This was the motivation for introducing the level of information need framework in the ISO 19650 series.
The level of information need is a framework to define the quality, quantity and granularity of information requirements.

To find out more about the level of information need please refer to BS EN 17412-1:2020 Building Information Modelling: Level of Information Need. Concepts and principles.
The level of information need is used to communicate clearly the degree of information required according to its purpose; no more and no less.

The level of information need framework helps to define the minimum information requirements with respect to each purpose. Any additional information is considered waste and should not be defined by the appointing party, nor provided by any appointed party.

The “over definition” or “under the definition” of information requirements are both considered risky, as they do not support the efficient generation and use of information.

It is the level of information need framework that allows first the information receiver (specifier) (appointing party or lead appointed party) to define the different “shapes” and “sizes” of the information deliverables in a standardized way. Using the level of information need, the information receiver (specifier) can define the quality (green or purple circles, blue or pink triangles), quantity (two triangles and three circles) and granularity (small or big circles) of information.
At each stage of the process, the model and data progression growth as the project matures and develops.  An increase in the graphic model definition and structured data also increases.

LOD 1 -Brief Information (Mass, layout intent and space definition) (SYMBOLIC)
LOD 2 – Concept Information (Overall definitions)  (CONCEPTUAL)
LOD 3 – Developed Generic Detailed Information (Layered details) (GENERIC)
LOD 4 – Specified Detailed Coordination Information (Defined element details) (SPECIFIC)
LOD 5 – Specified Manufacture/Fabrication Information (FOR CONSTRUCTION/RENDERING)
LOD 6 – As Constructed Information (AS BUILT)
LOD 7 – In-use
Plant Room- LOD 3 – Developed Generic Detailed Information (Layered details)  (GENERIC)
Plant Room – LOD 4 – Specified Detailed Coordination Information (Defined element details)  (SPECIFIC)
Information should be defined across the following three sub-divisions, for the Project Information Model (PIM) and the Asset Information Model (AIM): 

Geometrical information
Alphanumerical information
Documentation.
OIR are the starting point for all information management activities. OIR detail the high-level information required by an organization across its whole asset portfolio and its different departments (such as human resources, information technology, finance, facilities management and operations/ production).

• The information requirements from all the assets and departments should be rationalized and joined up to help streamline the business.

OIR enable understanding of the high-level information needed about assets throughout their lifecycle. This helps the appointing party run their business in an informed and effective manner and to understand the information needs of their clients and stakeholders.
What they are for:

OIR ensure the correct information feeds back into an organization’s wider business function to support strategic business decisions. OIR are therefore an important resource to support the organization.

When they are defined:

As part of the organization’s business activities.

Who creates them?

The appointing party, for example, the project client, the asset owner or their representative.
Identify the high-level activities for which information is required.

To begin this process, it is worth considering the high-level activities that require information within an organization. This will help to create a structure. Examples include:

• Health and safety compliance and management
• Environmental management
• Capital investment and lifecycle costing
• Risk assessment and management
• Maintenance and repairs
• Asset operations
• Space utilization
• Asset modifications.
Identify the purposes for which information is required As well as defining the activities for which information is required, it is also important to define the reasons why information is needed. These are the organization-based purposes and could be to satisfy (for example):

• Objectives/outcomes
• Stakeholders (including staff, end-users, shareholders)
• Regulators (including building control, planning, auditors, inspectors)
• Policies (including quality management)
• Business operation tasks (including corporate reporting, applications, auditing, procuring maintenance contractors, analyzing space utilization).

These can be used to generate a matrix of information needs against information activities where each associated information requirement is defined.
Once completed the OIR set the scene for the next two requirements, the:

1. Asset information requirements (AIR)
2.   Project information requirements (PIR)
The process of defining the OIR will generate a set of high-level requirements across the organization. These can then be developed to relate to specific assets in the form of AIR.
What AIR are for:

AIR set out the asset-related information which the asset owner/operator needs, either for themselves or for their stakeholders.

When AIR are defined:

Defining AIR is an important organizational business activity to support asset management, as well as design and construction projects. AIR has to be defined prior to any related appointment. For appointing parties with multiple assets, it is sensible to consider how the AIR can be rationalized in a streamlined and efficient way using a consistent structure as far as practicable.

Who creates them?

The appointing party, for example, the asset owner or their representative. The creation of AIR is led by the internal team responsible for asset and facilities management (where they exist).
AIR are derived from the purposes for which the appointing party requires information. These can include:

• Relevant OIR such as corporate policies
• Monitoring asset use and condition
• Monitoring energy consumption or running costs
• Asset stakeholders who require information, for example, visitors or users.

With the AIR in place, the information to be delivered can then be defined more precisely in EIR
PIR, like OIR, are high-level and identify what information will be needed for the key decision points determined by the appointing party. There is only one set of PIR per project.

PIR are partly derived from OIR. They enable understanding of the high-level information the appointing party requires during a design and construction project.

When PIR are defined Some of the PIR content may have already been defined within OIR that are applicable to design and construction projects. For example, statutory requirements or corporate project delivery policies.

Any additional PIR should be identified and added to those derived from OIR at the inception of a design and construction project before the appointments for any consultants or contractors are tendered.

Organizations with many projects may find it helpful to consider and define their PIR as a separate offline exercise from any particular project being started.
The appointing party, for example, the project client, the asset owner (indirectly through OIR) or their representative.
What they include PIR are derived from the purposes for which the appointing party requires information. These can include:

• Relevant OIR such as corporate key performance indicators (KPIs)
• Project business case, for example, financial information to establish value for money and affordability
• Strategic brief, for example, strategic programme to establish an opening date for a school
• Project stakeholders who require information, for example, local residents
• Project tasks which the appointing party themselves need to carry out, for example, completing an application.

With the PIR in place, the information to be delivered can then be defined more precisely in EIR.
Development of PIR should go hand in hand with the strategic project management activities being defined, rather than as a standalone activity. Note that the appointing party does not have to issue a separate document called PIR.

The points to consider as defined in ISO 19650-2.
Project Requirements – A clear set of questions that need to be answered by the Project Team?

Information Deliverables – The source material for obtaining the answer

1. What is the minimum amount of information needed?
2. Who needs the Information?
3. Why or What is the Information needed?
4. How must the information be produced?
5. What supporting material (if any) is needed to produce the information?
6. When is the information needed?
Exchange information requirements (EIR) specify the information that is needed to be delivered by a lead appointed party or by an appointed party at each information exchange.

EIR are defined in sufficient detail such that they can be incorporated into the contract between an appointing party and a lead appointed party, or between a lead appointed party and an appointed party.

Appointing party’s EIR to be met by lead appointed parties.
Lead appointed party’s EIR to be met by appointed parties.
The appointing party’s process of defining OIR, AIR and PIR will satisfy ISO 19650-2 clause 5.2.1 a) by specifying the information required and the degree of granularity needed to fulfil organizational, asset and project-related activities.

These will inform EIR.
The appointing party’s EIR are combined with the lead appointed party’s information requirements to form the lead appointed party’s EIR.
They are created to ensure that the correct information is delivered to an appointing party or lead appointed party, which enables them to fulfil specific and necessary activities during a project and during the operational phase. EIR/EIR (ISO 19650-3) have several functions, including:

• Selection of those lead appointed parties who can best demonstrate delivering the requirements
•   Specifying precisely what information is required at each information exchange, i.e. the information the lead appointed party (information provider) is to deliver (on behalf of its delivery team) to the appointing party (information receiver (specifier)), to enable the appointing party to carry out its purposes effectively
•   From a technology perspective EIR enable pre-defined mappings to be established, allowing communication between systems across the project team, to improve interoperability
•   Supporting the carrying out of checks to ensure that the information received from the lead appointed party is compliant with what was initially required by the appointing party.
EIR/EIR (ISO 19650-3) have to be defined prior to every appointment and issued as part of the appointment process:

For an appointing party, this occurs before any consultants, specialists or contractors are selected.
EIR/EIR (ISO 19650-3) have to be defined prior to every appointment and issued as part of the appointment process:

For an appointing party, this occurs before any consultants, specialists or contractors are selected
The appointing party should develop one master set of EIR for each project, which is then filtered to create a tailored set for each appointment. Therefore, where there are multiple appointments during a project there will be multiple EIR.

For appointing parties with multiple assets, it is sensible to consider how the EIR can be rationalized so that an appointment level they are specified in a streamlined and efficient way using a consistent structure as far as practicable.