Information Requirements ISO 19650 feature image

Explaining Information Requirements in ISO 19650

I will begin by repeating the truth told thousands of times within the AEC industry – we are one of the least productive and least technologically advanced industries in the world. In our projects, we are reactive and think too late about most things. We use a variety of software, but rarely squeeze a maximum potential out of them. The information we create is too often ad-hoc (because somebody has unexpectedly realised he needs something delivered by yesterday) and the requirements tend to be unpredictable (raise the hand if your client didn’t change his mind in the middle of the process… Nobody out there?).

Is there any solution for us or we will always be dangling at the end of the productivity chain? ISO 19650 comes with one – good quality information requirements. In fact, it is they that start every project, define inputs and drive every process. Indeed, each organisation and project should prepare good requirements to receive better quality delivery and to design and build better.

In this entry, I will explain how I understand different information requirements. Each of those terms encompass a scope for a separate article, so here, I will just cover the basic facts and clarify the concept. If you have any comments on that entry – happy to hear them and to expand my knowledge.

Table of Contents

What are the information requirements?

According to ISO 19650 series, information requirements specify for what, when, how and for whom we should produce data. Let us divide this definition into parts:
  • For what: a purpose. Requirements specify what actions can be fulfilled with the delivered information. For instance, a purpose might be maintaining an air handling unit.
  • When: the date or the event that the information should be delivered upon. It can be the deadline of tendering process or a milestone in a project. Keep in mind that information requirements have to be defined as early as possible.
  • How: in what way. Content, form and format of the delivered information. Requirements should be structured in a way to enable automated checking rules.
  • For whom: who is the receiver of information. It might be a person, team or organisation. Oftentimes it is the Appointing Party (but it can as well be the Lead Appointed Party that receives information from its Appointed Parties).
As we see from the above definition, the Appointing Party (or information receiver) has to understand first for what purpose they even require the information. Only after that can the client communicate requirements to the Lead Appointed Party (information provider). And the latter has to understand what to deliver to satisfy the needs of the Appointing Party. In this entry, I described the way different parties interact with one another.

shit in shit out
The concept from a T-shirt (https://shop.spreadshirt.fr/audiofanzine/) applies as well to information requirements. Poor information requirement -> world-class BIM software and experienced team -> lots of time for design process -> poor information delivered.

High-level and detailed information requirements

How do we define the requirements? Before I dive into all types of requirements let me first discuss the granularity of information requirements.

High-level requirements

High-level requirements answer the question “for what” from the definition of information requirement. They are the starting and the definition point for why information is needed. The Appointing Party must understand what information they should require to support their objectives. The purposes can be defined by themselves or by their client.

High-level requirements are defined in Organisation Information Requirements and Project Information Requirements. In ISO 19650-1, these are referred to as “interested parties’ information requirements”.

Example

A developer intending to build an office has his requirements. They support his objectives as an organisation with a specific business model. Into his requirements, the developer also adds the requirements of his client: a future building manager.

Detailed requirements

Detailed requirements answer the question “how” from the definition. They can take the form of a spreadsheet specifying the content, form and format of each information required. The detailed requirements take care of all the bits and parts of the project. Of course, the appointing party does not need to have detailed requirements for each piece of information. For some elements, it is enough to define the purpose and leave the details to the Delivery Team.

Asset Information Requirements and Exchange Information Requirements specifies the detailed requirements. In ISO 19650-1, these are referred to as “appointment information requirements”.

Example

The detailed requirements specifies which object properties should be delivered at each stage of the project. Or what is the wished energy consumption. Or what Appointing Party needs as deliverables at the end of the construction phase.

high-level and detailed information requirement
This graphics presents which information requirements are high-level and detailed as well when in the project delivery phase they are used.

Information waste

The other extremely important concept is information waste avoidance. ISO 19650-2 is explicit about not generating information that:

  • Exceeds the required level,
  • Extends beyond the scope,
  • Duplicates information created by other task teams,
  • Contains superfluous details.

In other words:

  • Appointing Party (the client) has to require only the information he knows is going to use (I observe the tendency to require too much information),
  • Appointing Party should not require or define information that the Delivery Team needs for themselves to drive the process (the client should not step into the contractor’s shoes),
  • The Delivery Team has to create the information only up to the level of requirement set by Appointing Party. This relates to both level of detail and scope,
  • A Task Team should not duplicate the information created by another Task Team. As a practical example, we should avoid duplicates in the federated model. We should not have walls, slabs or other design elements that comes from different models.
progression of information
Figure according to ISO 19650-3

Information requirements outside of the design and construction phase

Those are the requirements that are bound to an Appointing Party. They establish a set of requirements that should be worked upon long before the start of the design phase (OIR) and that define the deliverables for the end of the construction phase (AIR). We could think of those two as a frame that needs inside filling.

Organizational Information Requirements

OIR are high-level requirements defined by a company concerning their assets, business operation and departments. Different organisations have different information needs. OIR helps to understand what information a company needs, moreover its clients and stakeholders. 

Example

OIR is a document that stresses what sort of information a company would need to operate its portfolio of buildings. Is it a hospital owner? Then it probably stresses more on information about the operation and maintenance of complex installations and equipment that costs millions. Does the company manage offices? Then probably equipment in the building is not necessary since this is the responsibility of the lessee firm. Instead necessary would be maintenance documents for systems in the building and a set of requirements for interior design.

Asset Information Requirements

AIR is formed out of Organisational Information Requirements. The Appointing Party is responsible to specify the detailed requirements for the content, form and format of information to correspond to the specific asset being designed and built.

AIR is the precise description of the information required to operate and maintain a specific built asset through its lifecycle. The information required in AIR focuses on the as-built state. It defines not only what information is required (content) but also how it should be delivered (form and accepted formats of deliverables). AIR has to be defined after OIR but before any contract is signed (since the tender should base on i.a. AIR).Once specified, Asset Information Requirements determines the content of an Asset Information Model (AIM described in previous article).

Example

The detailed information is presented in the form of a spreadsheet boiled down to every requirement that we need to successfully operate the building. Information delivery might be required in a format that enables later import into our CAFM system. Below the example of two specific requirements in AIR.

Content summary Content breakdown Form Format
Emergency routes Alphanumerical information: IfcSpace with the property ‘escape route’ space model IFC
Geometrical information: escape route drawing drawing PDF
Air Handling Unit maintenance Ventilation system schema drawing PDF
Maintenance routines document PDF

Information requirements during design and construction project delivery

Those are the project-specific requirements that are based upon requirements created by the Appointing Party before the project start-up (OIR and AIR). Those requirements are specified for and used during the whole project delivery phase.

Project Information Requirements

PIR is a set of high-level information requirements, partially created from OIR (OIR provides an input to PIR, i.e. OIR is not the only one source). PIR focuses on information that the Appointing Party requires at key decision points during a design and construction project delivery. While creating PIR, the Appointing Party should take into consideration the project plan of work and tie its key decision points with the schedule.

A key decision point takes place when the client makes a decision based on information provided by the delivery team. Key decision points define the information delivery milestones, i.e. when the required information has to be delivered to the Appointing Party. Defining such events eliminates a good part of the last-minute information requirements.

ISO 19650-2 comes with a list of suggested points to consider while creating PIR:

  • the project scope;
    the intended purpose for which the information will be used by the appointing party;
  • the project plan of work;
  • the intended procurement route;
  • the number of key decision points throughout the project;
  • the decisions that the appointing party needs to make at each key decision point;
  • the questions to which the appointing party needs answers, to make informed decisions.

Once specified, Project Information Requirements determines the content of a Project Information Model (PIM described in previous article).

Example

A decision point described in PIR might be whether or not to build an additional building (project scope) basing on the cost estimate delivered by the contractor at the end of the concept design phase. PIR specifies a high-level requirement for what is needed to make this decision. EIR specifies detailed input on what information has to be exchanged at this delivery milestone.

Another decision point might be the choice of the facade system during the concept phase based on the noise and thermal calculations delivered by the Lead Appointed Party.

Exchange Information Requirements

EIR is a set of detailed requirements of information to be delivered by various Task Teams during information exchanges (events of satisfying the information requirements by information delivery). EIR specifies also the structure and the definition of the information delivered. In other words, by meeting requirements set in EIR, Appointing Party and Lead Appointed Party are able to carry out their activities during the project delivery and operation. EIR is specified first by the Appointing Party. Secondly, the Lead Appointed Party adds up its own requirements for the Delivery Team. Then they are divided among all the Appointed Parties. And so on.

EIR is usually a set of interconnected requirements that specifies every information exchange. Satisfying one requirement might serve as an input to the next one (e.g. meeting requirements by delivering an architectural design of the building is an input for a structural engineer and his information exchange).

EIR originates from both Project Requirements and Asset Requirements (PIR and AIR provides an input to EIR, i.e. they aren’t the only sources).

Example

EIR might specify the table of properties in the models that have to be followed at the end of each phase. Or a table defining the types of model quality controls performed depending on the stage of the design phase (visual control, model integrity control, data validation etc.).
Content summary Content breakdown Form Format Information Exchange Date
Schedule of spaces Alphanumerical information: room function number, room name, programmed area schedule XLSX At delivery milestone 1
Emergency routes Alphanumerical information: IfcSpace with the property ‘escape route’ space model IFC At delivery milestone 4
Geometrical information: escape route drawing drawing PDF At delivery milestone 4

Summary

In conclusion, those are the four different types of information requirements. It is also important to keep in mind that if an Appointing Party operates a portfolio of the assets it is advisable to streamline those documents so that they fit future projects.

Hopefully, by the implementation of this process our industry can begin to think with the end in mind.

Resources

Did you like that post ? Share it with others !

We spend a lot of time and effort creating all of our articles and guides. It would be great if you could take a moment to share this post !

Share:

Comments:

Subscribe
Notify of
guest
4 Comments
Oldest
Newest
Inline Feedbacks
View all comments
daniel
2 years ago

thank you for this very useful article.

Nizar Ghaib
Nizar Ghaib
1 year ago

Yes, I like how simply the information was delivered.
Thanks for the big effort; you caught my attention for the next articles.

Les Morrison
1 year ago

Hi Konrad
Always a pleasure to read your excellent Blogs. Thank you for this one which includes an explanation on High-Level Strategy and Requirements – a part of Assessment and Need that needs greater expansion.
In your example respecting High-Level information requirements/strategy, I understand why you would consider the Client as you have. However, from a legal aspect, perhaps they would be considered the Appointing Party rather than an end-user, even if they were the end-user.
Les Morrison

Author:

Download BIM CASE STUDIES:

After reading this guide you will learn:

  • How BIM is used on the biggest projects in Norway
  • What were the challenges for the design team and how were they solved
  • What were the challenges on the construction site and what was our approach to them

Newest articles: