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?
- 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).
High-level and detailed 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.
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.
Information requirements outside of the design and construction phase
Organizational Information Requirements
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 | ||
| Air Handling Unit maintenance | Ventilation system schema | drawing | |
| Maintenance routines | document |
Information requirements during design and construction project delivery
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
| 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 | 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
- ISO 19650
- UK BIM Framework and ISO 19650 Guidance
- The NBS
thank you for this very useful article.
My pleasure! Glad you liked it 🙂
Yes, I like how simply the information was delivered.
Thanks for the big effort; you caught my attention for the next articles.
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