Module 2

Transition to ISO
19650
Royal Institute of Chartered
Engineers
RICS
Table of Content
1. PART 1: INTRODUCTION TO ISO 19650..........................................................................................3
 1. PART 1: INFORMATION REQUIREMENTS
1.1. Key learning points - Part 1
 How the client requirements are developed
 The purpose of key BIM information requirements (OIR, AIR, PIR, EIR) to be put into place at
the strategic definition stage of a project

1.2. Why is this important?

1.2.1. Self-reflection
Do you think information requirements are a key aspect to information management? Why?

1.2.2. Information requirements are crucial for project success

Under ISO 19650 series, information requirements may be developed by:

 The appointing party

 The lead appointed
 Appointed parties

Figure 1 - Who has information requirements?

Information requirements can come from respective organisations or interested external parties.
The appointing party should be able to express these requirements to other relevant organisations
and individuals to either specify or inform their work.
Understanding the purpose,
intent, and nature of information requirements
is crucial for project success.
As identified by the UK BIM Framework guidance, the key enablers to collaborative and effective
information management are present when information requirements are:
 Clearly defined
 Value-driven
 Prepared at the outset of the project

As stipulated in ISO 19650-1 Clause 5.1:

“The appointing party should understand what information is required

concerning their asset(s) or project(s) to support organisational or project

objectives. To enable effective information requirements, the appointing

party (for example the client) should clearly communicate to other

organisations their information need via the exchange information

requirements. A clear hierarchy of information should be set out linked to

the project, asset(s) and organisational objectives.”

ISO 19650-1 Clause 5.1

1.3. Developing information requirements

1.3.1. The appointing party’s information requirements’ purpose and scope

In this section, we will concentrate on the appointing party’s information requirements. The
following section has been taken directly from the ISO19650-1 section 5.1:
The appointing party should state their purposes for requiring information deliverables, including
the aspects of the asset that are intended to be managed. These purposes can include:

1.3.1.1. Asset Register

A register of assets should be provided to support accurate auditing and reporting; this should
include both spatial and physical assets and their groupings.

1.3.1.2. Support for Compliance and Regulatory Responsibilities

The appointing party should specify the information required to support the maintenance of the
health and safety of the users of the asset.
1.3.1.3. Risk Management
Information should be required or suppressed to support risk management, especially to identify
and review the risks that a project or asset can be exposed to, for example, natural hazards, extreme
weather events or fire.

1.3.1.4. Support for Business Questions

The appointing party should specify the information required to support the review of the business
case for ownership and operation of the asset; this should include continuous development of the
following impacts and beneficial aspects of the asset from the earliest deliverable onwards:

 Management of capacity and utilization: documentation of the intended capacity and

utilization of the asset should be provided as it is required to support comparisons of actual
use, utilization and portfolio management.
 Management of security and surveillance: information should be required or suppressed to
support the management of the security and surveillance of the asset and neighbouring or
adjacent sites in line with security requirements.
 Support for renovation: renovation of each space or location and the whole asset should be
supported with detailed information about the capacity, in terms of areas, spaces,
occupancy, environmental conditions and structural load bearing.
 Predicted and actual impacts: the appointing party should require information relating to
the impacts from quality, cost, scheduling, carbon (CO2), energy, waste, water consumption
or other environmental effects.
 Operations: information necessary for the normal operations of the asset should be
provided to help the appointing party anticipate the cost of asset operation.
 Maintenance and repair: information on the recommended maintenance tasks, including
planned preventative maintenance, should be provided to help the appointing party to
anticipate and plan for costs of maintenance.
 Replacement: information on the reference or expected replacement service life and costs
should be available to the appointing party to anticipate the costs of replacement; recycling
of the physical assets should be supported with detailed information relating to the principal
constituent materials.
 Decommissioning and disposal: information on the recommended decommissioning should
be provided to help the appointing party anticipate and plan for end-of-life costs.

TOP TIP
1. Information requirements associated with the delivery
phase of an asset should be expressed in terms of the
project stages that the appointing party or lead
appointed party intends to use.
2. Information requirements associated with the
operational phase of an asset should be expressed in
terms of foreseeable life cycle trigger events such as
planned or reactive maintenance, fire equipment
inspection, component replacement, or change of asset
management provider.
1.3.2. The four facets of information requirements
(UK BIM Framework, Guidance Part D)
While the previous extract from ISO19650-1 concentrates on the importance of the information
purpose, we would like to dive deeper into the definition of the information requirements.

The purpose of information provides the reason why the information is required.

Key point
Always start with the reason (purpose) before the information itself is considered.

However, knowing the reason does not necessarily provide

specificity of the information required!

As per the Guidance Part D from the UK BIM Framework, information in accordance with the ISO
19650 series can be described across four main facets: purpose, content, form and format. Click on
the buttons below to find out more.

1.3.2.1. Purpose
The need that the information will fulfil. For example, to convey fire performance of a wall.

1.3.2.2. Content
Content is split into:

 Content summary - The overall content of the information. For example

fire strategy information or elemental cost.
 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’.

1.3.2.3. Form
 How information is presented.
 For example, a schedule or a drawing, etc.

1.3.2.4. Format
How information is encoded. For example, PDF or IFC(-SPF), etc.

1.3.3. Categories of information requirements (ISO19650-2)

According to ISO 19650 series, having well defined information requirements is
crucial for the project’s success and these requirements are split into the
following categories:
1. Organisational information requirements (OIR)
2. Project information requirements (PIR)
3. Asset information requirements (AIR)
4. Exchange information requirements (EIR)

Each set of requirements has its own purpose and before going into explaining
each set we would like to describe their relationship between them.

1.3.3.1. Relationship between the four categories of information

requirements – key workflows

When thinking about the project delivery with no asset management

considerations we would be looking at the PIR, which contributes to the EIR,
which effectively specifies the Project Information Model (PIM) as identified in the
image below (this workflow is covered by ISO19650-2):

Figure 2 Workflow from PIR to EIR to PIM

If we consider asset management with no project delivery considerations, then

we would be looking at the OIR which encapsulates the AIR, which effectively
specifies the Asset Information Model as shown in the image below (this
workflow is covered by ISO19650-3):

Figure 3 Workflow from PIR to EIR to PIM

However, on a project t per project level we normally have asset and project
delivery requirements combined, meaning that all information requirements
should be considered. According to ISO 19650-1 the relationship between
information requirements could be represented in the following diagram:
 Figure 4 Hierarchy of information requirements

1.4. Organisational Information Requirements (OIR)

OIR are developed by the appointing party (asset owner/operator).

OIR explain the information needed to answer or inform high-level strategic objectives within the
appointing party.
These requirements can arise for a variety of reasons such as:
1. strategic business operation
2. strategic asset management
3. portfolio planning
4. regulatory duties
5. policy-making

Organisations often comprise multiple departments (Finance, Human Resources and Estates, etc.)
which may need to use information generated through the BIM process. For example:

1. The Finance department may need to report annually on retail space vs

back of house space; HR may need to report on square meterage per
employee. If these requirements are known going into a project –
then their answers can be made part of the contractual
deliverable!
2. The Estate department may be split into Capital Investment and Asset
management – both of which have different information requirements at
the project Handover.

Key point
All these diverse requirements need to be collated and articulated in one place – the OIR.
Once the strategic level information requirements are defined, they can be used to provide input to
the AIR and PIR.

Example
ISO 19650-3 Annex A.2 provides examples of activities requiring asset
information and examples of organisational information requirements

1.4.1. Organisational activities

A wide range of organisational activities, including asset management and

facility management activities, can lead to the organisational information
requirements (OIR).

These can be grouped according to whether they are:

1. strategic
2. tactical
3. operational

1.4.2. Why is grouping important?

Doing so can help identify both the frequency at which information will be
required and the types of stakeholders who require it.

1.4.3. Ungrouped activities

Because organisational views on which activities belong to which group

(strategic, tactical, operational) can differ, so the following examples have not
been grouped:
 asset accounting, activity costing, forecasting
 planning and budgeting
 demand management and customer expectation policy
 capital investment and life cycle costing
 innovation and change management
 interfacing with regulatory bodies
 publication of asset information for use by the public
 asset operation or utilization
 asset modifications, refurbishment, replacement, reuse/redeployment,
disposal, recycling
 spares, materials and purchasing
 data, information, and knowledge management
 contractor and supplier management
 human resources, skills development, and competencies
 maintenance, inspection, condition, and performance monitoring
 contingency planning and emergencies
 energy efficiency and environmental aspects, e.g. renewable resources,
recycling, waste management, air purity, hygiene
 risk assessment and management
 safety, health, and environmental management

1.4.4. Grouped activities

The following are examples of OIR, which can also be grouped according to
whether they are strategic, tactical, or operational. Information to support:

 the financial benefits of planned improvement activities

 a means to predict the performance of the asset to support operational
decision making
 the operational and financial impact of asset unavailability or failure
 the life cycle cost comparisons of alternative capital investments
 expiry dates of warranties
 an assessment of the end of an asset’s economic life, e.g. when the asset-
related expenditure exceeds the associated income
 quality targets for the performance of assets
 service levels for asset management and facility management
 the cost of specific activities (activity-based costing), e.g. the total cost of
maintaining a specific asset/asset system
 asset replacement values
 financial analysis of planned income and expenditure
 the financial and resource impact of deviating from plans that can result in
a change in asset availability or performance (for example what is the
financial impact of deferring the maintenance of a specific generator by
six months?)
 overall financial performance; and — identification, assessment, and
control of asset-related risks.

1.4.5. EXPLORE
Have a look at the Centre for Digital Built Britain -
International BIM Toolkit Documents for the templates and
guidance for OIR

1.5. Project information requirements (PIR)

Similarly to the organisational information requirements, the project

information requirements (PIR) explain the information needed to
answer or inform high-level strategic questions within the appointing
party, in relation to a particular built asset project throughout the
project's key decision points.
When developing the PIR the appointing party shall consider:
 the project scope (project-specific)
 the intended purpose for which the information will be used by the
appointing party (for example, to effectively operate the facility)
 the project plan of work (for example, RIBA Plan of Works)
 the intended procurement route (for example, two stage Design and
Build)
 the number of key decision points throughout the project (for
example, RIBA stage 4 may have two information exchanges in
addition to the end of stage information exchange)
 the decisions that the appointing party needs to make at each key
decision point (for example, approve planning suite of documents)
 the questions to which the appointing party needs answers, to make
informed decisions (for example, Plain Language Questions could be
utilised)

Repeat clients may develop a generic set of PIR that can be adopted,
with or without amendment, on all of their projects.
Additionally, PIR does not need to be a stand-alone document and could
be incorporated into other information requirements.

1.5.1. EXPLORE
Have a look at the Centre for Digital Built Britain International BIM Toolkit
Documents for the templates and guidance for PIR:

International BIM toolkit - Centre for Digital Built Britain

https://www.cdbb.cam.ac.uk/AboutDBB/Promoting-digital-construction-
Internationally/international-bim-toolkit

1.6. Asset information requirements (AIR)

As per ISO 19650-1 Asset Information Requirements (AIR) set out

managerial, commercial, and technical aspects of producing asset
information.

-What you should include in the managerial and commercial aspects?

The managerial and commercial aspects should include the information standard and the production
methods and procedures to be implemented by the delivery team.

-What you should include in the technical aspects?

The technical aspects of the AIR specify those detailed pieces of information needed to answer the
asset related OIR.
These requirements should be expressed in such a way that they can be incorporated into asset
management appointments and deliverables to support organisational decision-making.
When should you prepare AIR?
A set of AIR should be prepared in response to each trigger event during asset operation and where
appropriate should also refer to security requirements.

The information needed to develop asset information requirements is

primarily described in ISO 19650-3 and ISO 55000, ISO 55001 and ISO 55002.

1.6.1. Considerations when establishing and developing AIR

1.6.1.1. Establishing AIR

To establish the asset information requirements the appointing party shall consider:

 the purpose(s) for which asset information needs to be managed as an effective

organisational resource
 the ownership of the assets and the information associated with them
 information required across groups of assets as well as for individual assets
 where an ISO 55001 asset management system is in place, the impact of its asset
management strategy and plans.

1.6.1.2. Developing AIR

When developing the asset information requirements, the appointing party should identify the
foreseeable trigger events for which information shall be managed. There are a number of trigger
events that should be considered, for example:

 inspection of an asset
 maintenance work on an asset, whether planned or reactive
 minor works on an asset, such as minor repairs, component replacements or minor upgrades
 initiating a project to deliver a new asset
 major works on an existing asset such as major repairs, refurbishments, or major upgrades
 creation of a new asset

1.6.2. Linking the information to the asset management

In addition to the above, the appointing party shall consider how the information is going to be
linked to the asset management enterprise systems.

It is crucial to identify how the information gathered throughout the project delivery phase will link
to document management, CAFM, enterprise resource planning systems, etc.

Each system may have a requirement, which should be translated into the AIR to avoid ambiguity.

1.6.3. Example:

The AIR should capture the requirements to specify the Asset Information Model.
 ISO19650-3 Annex A.4 provides great examples of information that can be required within an AIM:

1.6.3.1. A.4.1 Managerial information

The following are examples of information that can be required within an AIM to support managerial
OIR:

 unique asset identifiers

 locations of the assets, possibly using spatial referencing or geographical information
systems
 spatial data relating to assets, for example pavement areas, room sizes
 warranties and guarantee periods
 access planning and work schedules
 historical record of proactive and reactive maintenance tasks performed
 future schedule of maintenance and inspection tasks including details of overdue tasks, and
including details of the maintenance organisation and details of qualifications/certifications
required to carry out each task
 asset related standards, process(es) and procedure(s)
 the presence of any hazardous contents or waste
 details of asset destination at end of current life
 details of emergency plans including responsibilities and contact details
 details of historical asset failures, causes and consequences (if known)

1.6.3.2. A.4.2 Technical information

The following are examples of information that can be required within an AIM to support technical
OIR:

 engineering data and design parameters

 details of technical dependencies and interdependencies of assets
 commissioning dates and data
 operational data including performance characteristics and design limits

1.6.3.3. A.4.3 Legal information

The following are examples of information that can be required within an AIM to support legal OIR:

 details of ownership and maintenance demarcation where assets interface across a system
or network of assets
 work instructions together with diagrams and reporting requirements, legal obligations such
as health and safety file information, and safety/environmental considerations
 asset related contractual information
 task risk assessments and control measures

1.6.3.4. A.4.4 Commercial information

The following are examples of information that can be required within an AIM to support
commercial OIR:

 descriptions of assets and the asset systems they serve

  functions of assets, including any interdependencies to the activities that require them
 data (details of the organization that supplied the asset) including asset lead time
 the condition and duty of assets including intensity of use
 key performance indicators
 condition and performance targets or standards
 criteria of non-conformance and the actions to be taken
 the criticality of assets and spaces to the organization
 identities and levels of spares held inter-changeability, specifications, and storage locations

1.6.3.5. A.4.5 Financial information

The following are examples of information that can be required within an AIM to support financial
OIR:

 whole life costs of asset deployment including cost of historical and planned maintenance
tasks
 operating costs
 downtime impact
 current asset replacement value
 original purchase/leasing costs

1.6.4. EXPLORE

Have a look at the Centre for Digital Built Britain International BIM Toolkit Documents for the
templates and guidance for AIR:

International BIM Toolkit Documents for the templates and guidance for AIR

https://www.cdbb.cam.ac.uk/AboutDBB/Promoting-digital-construction-Internationally/
international-bim-toolkit
1.7. Exchange information requirements (EIR)

Exchange information requirements (EIR) should specify those detailed pieces of information needed
to answer PIR and AIR.

How to represent in detail the detailed pieces of information needed?

Requirements represented in the EIR may be split into:
 documentation
 geometric information
 alphanumeric information

Since the EIR topic is quite broad, we will explain the contents of the EIR in the next module when
we go through the invitation to tender stage.

1.8. Hierarchy of information requirements

Developing information requirements might be quite complex. However, understanding the

relationship between multiple requirements might assist you in developing your own.

Guidance part D from the UK BIM Framework provides a fantastic diagram outlining the hierarchy
of the information requirements:
 Figure 5 Hierarchy of the information requirements

As mentioned before, it all starts at the organisational level, where the appointing party should
outline their strategic programme objectives that are captured in the OIR.
The OIR will guide the requirements needed to answer project delivery requirements, which are
covered in the PIR and operational requirements which are covered in the AIR. Both AIR and PIR are
still considered to be relatively high-level requirements, which will be detailed in the EIR.

1.9. Assessment and need

In this lesson, we will cover the information management process according to ISO 19650-2.

We’ll explore how the project information requirements (PIR) and delivery milestones are
determined, how to establish the project’s information standard as well as production methods and
procedures, the project’s reference information and shared resources, common data environment
and project’s information protocol.

1.9.1. Information management process according to ISO19650-2

Now that we understand the nature of the requirements, let’s go into the information management
process as per the ISO 19650-2 standard.

While ISO 1950-2 concentrates on the delivery phase of the assets, we know from the previous
lesson that information requirements pertain to both delivery and operational phases, thus asset
information requirements would be considered at this stage as well.
TOP TIP
While we will explain information management functions in

Part 2 of this module, we would like to mention that there

is the information management assignment matrix in

Annex A of the ISO19650-2.

This is a great resource for assigning the responsibility of

information management functions.

1.9.1.1. EXPLORE
Follow the link to access the detailed information management assignment matrix in excel published
by the UK BIM Framework.

https://www.ukbimframework.org/resources/

OK, let's begin by reviewing the first information management activity which is to appoint individuals
to undertake the information management function and establish their responsibilities.

1.9.2. PIR and delivery milestones

1.9.2.1. information management activity

1.9.2.1.1. 1st information management activity

When appointing individuals to undertake the information management function, it is important to
remember that the identification of the responsibilities is crucial to avoid ambiguity of who is
responsible for information management tasks.
 1.9.2.1.2. 2nd information management activity
Once we have identified the responsibilities on the project, we would move to the second activity
which consists of establishing:

1. Project information requirements (PIR), and

2. Information delivery milestones

Both of these activities would be performed by the appointing party or appointing party’s
representative.

Figure 7- Project’s information requirements (1.2) project’s information delivery milestones (1.3)

While the content of the PIR was

covered in the previous lesson, we
would like to draw your attention to
the information delivery milestones.
1.9.2.2. Information delivery
milestones
These would be most likely aligned to the plan of works and key decision points (however, this is
not always the case) and the dates would be set most likely by the project managers.
To illustrate the complexity of the activities undertaken per project and demonstrate the number of
decision points please refer to the diagram below provided by the UK BIM Framework Guidance
Part D. The diagram illustrates how the ISO 19650 information management activities are overlaid
throughout the project.

Figure 6 Example of key decision points and information delivery milestones in relation to the RIBA Plan of work stages
2013

Key
Reference to numbers 2 to 7 reflect the information
 Key
management activities set out in ISO 19560-2 clauses 5.2
to 5.7, which are as follows:
2 Invitation to tender
3 Tender response

4 Appointment

5 Mobilization

6 Collaborative production of information

7 Information model delivery

Key point
The key takeaway from the diagram is that information exchanges should be planned in advance of
the key decision points to allow for review and approval processes.

1.9.3. Establishing project’s information standard

As part of the assessment and need activities, the appointing party or appointed parties
representative shall establish project information standards, project information production
methods, procedures and shared resources, which are normally undertaken concurrently.

Considerations for developing the project’s information standard

When developing the project’s information standard the appointing party shall consider:
1.9.3.1. The exchange of information within the appointing party’s
organisation, between the appointing party and external stakeholders,
operators and maintainer and between appointed parties and lead
appointed parties.

Information container
Exchange format
type
1.9.3.2.
Animations (as required) .mp4
Documents .pdf
.pdf and .dwg (as
Drawings
required)

2D Models .dwg (key floor plans)

Schedules .xlsx / .pdf

Visualisations .jpg

Asset Data .xlsx (COBie)

Federated models .smc or .nwd

.nwc and .ifc (IFC-SPF)

Model renditions
Coordination View

Native 3D models
(Autodesk Revit) .rvt

When developing the project’s information standard, the appointing party

shall also consider the means of structuring and classifying information.
For example

In the UK the appointing party may want to utilise Uniclass 2015 classification
system, while in the US the appointing party might want to utilise Omniclass.

In addition to the classification systems appointing parties may have internal

room numbering guides, which would be included in the project information
standard.
 1.9.3.3. The appointing party shall also consider the method of
assignment for the level of information needed. It is good practice to
utilise the BS EN 17412-1-2020 standard and explain the method and
level of information needed.

Level of Information
Method of assignment
Need
Information provided should comply
with the requirements included in the
project’s information production
Documentation
methods and procedures and be
appropriate to the RIBA Stage for which
the document is issued.

NBS BIM Toolkit is used to determine

the level of geometric detail
Geometric information
assignment. Refer to the EIR for further
breakdown.
The key driver for alphanumeric
Alphanumeric information is the facilities
information management system utilised by the
Appointing Party. System requirements
are described in the EIR.

1.9.3.4. Last but not least, The appointing party shall also consider the
use of information during the operational phase of the asset.

An appointing party may want to use information for the

operational phase which is managed through the Planon
computer-aided facilities management system.

1.9.3.5. Establishing the project’s information production methods and

procedures
In addition to the project’s information standard, the appointing party is responsible for establishing
the project’s information production methods and procedures. In doing so, they shall consider:
1. The Capture of existing standard information

For example, the appointing party may want to utilise laser scanning processes.
If they have a preferred method for capturing the existing asset, they may specify it under project’s
information production methods and procedures.

2. The generation, review, or approval of new information

For example, the appointing party may prescribe the method of how the lead appointed party
(architect) shall number the rooms in the new facility.

3. The security of distribution of information

For example, the appointing party may utilise the security triage process defined in the ISO1965-5 to
identify the security requirement for the project. In most of the cases, the implementation of the
CDE with rigid access permissions will satisfy the security of information distribution.

4. The delivery of information to the appointing party

This is where the appointing party shall consider linked enterprise systems and identify how the
information will be delivered at the key information exchanges as well as at the handover.

For example, the appointing party may identify that they want project information to be transferred
to their internal SharePoint system at the project handover.

1.9.4. Establishing the project’s reference information and shared resources

As part of the assessment and need activities, the appointing party shall consider inclusion of:

1. Existing asset information

The appointing party shall consider the inclusion of existing asset information:
 from within the appointing party’s organization
 from adjacent asset owners (utility companies, etc.)
 under license from external providers (mapping and imagery, etc.)
 within public libraries and other sources of historical records

For example, an appointing party may have an existing facility asset register maintained by their
CAFM system, which would be issued to the delivery team as part of the existing asset information.
The existing asset register would be updated by the delivery team and submitted back to the
appointing party at the end of the project.
2. Share resources

The appointing party shall consider the inclusion of shared resources, for example:
 process output templates (BIM execution plan, master information delivery plan, etc.)
 information container templates (2D/3D geometrical models, documents, etc.)
 style libraries (lines, text, hatch, etc.)
 object libraries (2D symbols, 3D objects, etc.)

For example, an appointing party such as the Ministry of Justice may have developed a library of 3D
objects for prison design that they want the delivery team to utilise on the project .
3. Library objects defined within national and regional standards
For example, an appointing party may include Health and Safety Risk symbols as the common object
library to be used by the delivery team.
Figure 9 - project’s information standard; project’s information production methods and procedures;
shared resources

Figure 7 The diagram above identifies where we are in the information management process according to ISO19650-2

1.9.5. Establishing common data environment

One of the last but definitely not the least tasks associated with assessment and need activities is the
establishment of common data environment.

As we feel the CDE is a crucial component of any project, we will explain the role of Common Data
Environment in Part 3 of this module in greater detail.

1.9.6. Establish project’s information protocol

Finally, we conclude the assessment and need activities by establishing the project’s information
protocol.

1.9.6.1. What is information protocol?

An information protocol is the means for capturing requirements within an appointment or contract.
Every appointment should contain an information protocol, be that the lead appointed party, or an
appointed party.
The specific example of the ‘project’s information protocol’ is to contractually capture the
appointing party’s information requirements within the appointment(s) of the lead appoined
party(s).

1.9.6.2. When drawing up the protocol the appointing party should

consider:
 Specific obligations of the appointing party, prospective lead appointed parties and
prospective appointed parties relating to the management or production of information,
including the use of the project’s common data environment
 Any warranties or liabilities associated to the project information model
 Background and foreground intellectual property rights of information
 The use of existing asset information
 The use of shared resources
 The use of information during the project, including any associated licensing terms
  The re-use of information following the appointment or in the event of termination

1.10. Summary
 In summary, developing information requirements is a
rather complex activity, which encapsulates both
the delivery and operational phase requirements.
 When drafting information requirements, we need to take into
consideration the need of information from multiple appointing
party’s organisation departments, external stakeholders as well as
delivery teams information requirements.

 According to ISO19650 series we have a few resources at our

disposal to achieve robust information requirements:
o Organisational Information Requirements (OIR)
o Asset Information Requirements (AIR)
o Project Information Requirements (PIR)
o Exchange Information Requirements (EIR)

 Each of these resources require scrupulous thinking to identify

the purpose, context, form, and format of the information to
enable the delivery team to deliver the project.
 In addition to the above, at the assessment and need stage the
appointing party shall:
o Identify individuals undertaking information management
tasks
o Establish project milestones
o Establish project’s information standard
o Establish project’s information production method and
procedures
o Collate shared resources
o Implement common data environment and
o Incorporate information protocol in their appointments
 The list of tasks is quite long, thus it is important to allocate
sufficient time for this stage before moving to the invitation to
tender.

2) 2. PART 2: INFORMATION MANAGEMENT & FUNCTION

The key point for you to focus on in this part are:
The information management functions, including the aspect of the asset
information management functions, the project information management
functions and the task information management functions.

2.1. Why is this important?

Does ISO 19650 information management process apply to all
project information?
YES
This means that everyone within the project team will inevitably interact
with this process to some extent. Some of these interactions will be complex,
requiring direct involvement in the management of the process. Others will
simply require the adoption of a consistent and structured approach.

Key point
Understanding the nature of these interactions is critical to the success of the information
management process.
This section of the module will explain the various ‘function’ that has collective responsibility and
authority for the ISO 19650 information management process.

TOP TIP
Don’t confuse information management functions with job or professional titles. These relate to
design, construction, or operation responsibilities, etc, however the term function relates
to information management responsibilities. Often these two types of responsibility will be carried
out by the same team(s) or individual(s).

2.2. The information management function

2.2.1. Principles of information management functions

The information management function encompasses the collective responsibility and authority for

the information management process set out in ISO 19650-2

ISO 19650 Guidance Part A (edition 3): The information management function and resources, UK BIM Framework

A key principle of ISO 19650 is that activities within the information

management process are to be undertaken by a single ‘information

management function’.

This function is owned by the appointing party who is ultimately accountable for implementing the

process. Also, an individual within their organisation should be nominated to carry out the function

on their behalf.
This function is owned by the appointing party who is ultimately accountable for implementing the

process. Also, an individual within their organisation should be nominated to carry out the function

on their behalf.

Assignment of the information management function by the appointing party

The assignment of the information management function will require the appointing party to

establish a scope of services that considers:

3) PART 3: INFORMATION MANAGEMENT & FUNCTION
The key point for you to focus on in this part are:

The key elements and benefits of using a Common Data Environment (CDE)

3.1. What is a CDE? Introduction

The term Common Data Environment (CDE) is defined in ISO 19650-1 Clause 3.3.15 as:

Agreed source of information for any given project or asset, for collecting, managing, and
disseminating each information container through a managed process.
ISO 19650-1 Clause 3.3.15

More simply put, a CDE is a central repository for project and asset
information, acting as a single source of the truth. It is used to collect,
manage, collaborate, and share project information with the project team.

3.1.1. Features of a CDE

A CDE has two distinct features, a process workflow and a technical solution.

3.1.1.1. Process Workflow

These workflows are processes that help ensure information is managed, fit for purpose and readily
available for those who need it, when they need it.

3.1.1.2. Technical Solution

This solution is a tool that supports the process workflows. These solutions are typically digital, and if
so, are often known as Electronic Data Management Software/Systems/Solutions (EDMS) outside
of the construction industry.

3.1.2. Benefits of a CDE

Besides acting as a central repository there are many reasons why using a CDE is beneficial.

3.1.2.1. Main benefits of a CDE

The importance of these benefits varying is dependent on a party’s perspective, however, these are
some typical considerations:

 Information is made readily available, without the need to request it

 Information is coordinated between parties, everyone has access to same up-to-date source
 Information sharing, review and approval has an audit trail
 Information can be reused to support dependent activities
 Access to information can be controlled and restricted
 Project information is already gathered in a single location, ready for handover
3.1.2.2. Highlighted benefit - Security of sensitive assets
A CDE is particularly useful whenever sensitive assets are being delivered or protection against the
loss, corruption or disclosure of valuable commercial information and intellectual property is key.
Often a CDE configured and managed in response to a specific project of client need will seek to
maintain the safety and security of:

 Personnel and other occupants or users of the asset and its services
 The asset itself
 Asset information
 The benefits the asset exists to deliver

Understanding the security framework is a fundamental aspect of establishing who can access what
information and what they can do with it. It is therefore at the heart of how common data
environments are configured and managed. Typically, this aspect is enabled by the CDE solution, but
effective CDE process workflows are required to manage access.

3.1.3. Collaboration across CDE

The success of projects is heavily reliant on the capability of the parties involved and how well they
work together. Working together not only involves the regular exchanging of information but also
understanding what happens to the information once it is delivered; this is fundamental in ensuring
information is produced to meet a purpose.

 To enable work in a collaborative environment, information needs to be produced in line

with ISO 19650-2 (Clause 5.6.2).
 bullet
Design, construction and operation information tends to build on the work of others and
should not be created in isolation

Therefore, information should be shared on a regular

basis during project stages across the project’s common data
environment (CDE).

3.1.4. CDE Process

It is a common misunderstanding that the CDE is a technical solution only. Another
misunderstanding is that it is always a single solution. However, the truth is that the technical
solution or solutions are more important than the process workflow. So long as the workflow can
provide a unifying thread, any combination of technical solutions can be used.

It is this combination of technical solution and process workflow that both principally define the CDE
(according to ISO 19650), and aid project success.

3.1.5. Clarity, reliability and quality

3.1.5.1. Identification of information

Information containers stored within a CDE should be identified using a codified (naming)
convention that facilities understanding of the information container’s content and easy access.
Applicable identification standards are typically outlined in the national ISO 19650 annex that is
applicable to the project.

3.1.5.2. Quality, reliability and traceability

As the single source of the truth, the CDE helps collect, manage, share, review, and approve all
project or asset information.
This organisation of information helps minimise the occurrence of duplicated or conflicting
information containers.
All information added to the CDE is subject to the process workflow. These provide traceability for
when and by whom information was added to the system and provide a record of the review and
approval transitions that information containers undergo.

3.1.5.3. EXPLORE

Further Information - Practical CDE Components

The UK BIM Framework ISO 19650 Guidance Part C: Facilitating the CDE (workflow and technical

solutions) documentation gives a robust explanation about practical components of CDE use;

 Components of the CDE

 Information container management through metadata assignment
 Classification through metadata assignment
 Revision control through metadata assignment
 Status allocation through metadata assignment
 Checklist of actions/key points to consider

For detailed further information about information containers with respect to the above, it is

suggested that the above guidance is read and considered.

Note – this guidance information is specific to the UK BIM Framework implementation of Status,
Metadata, Classification, and Revisions. Whilst this may not be always be accurate or applicable in all
international frameworks, it is a clear demonstration and application of ISO 19650 principles (with
respect to CDEs) within a UK context and provides one region’s example of good practice.

3.2. Who and when?

3.2.1. CLIENT
In this lesson, we are going to cover the roles of the client (appointing party) and the delivery team
and at which stages the project CDE should be established.

We’ll start with the client and then move to the delivery team.

3.2.1.1. Who provides and manage the Project CDE?

The project CDE is provided and managed by the appointing party (or a third party acting on their
behalf), for the management of all project information being developed and used by appointed
parties (delivery team).

Often this is used to facilitate information exchange between different delivery teams on the
project, or for set project information exchanges.

Typically, project CDEs are set up to facilitate information containers in the state of Shared,
Published or Archive

In some instances, CDE’s may be established allowing information containers with the status Work In
Progress information to be used on the client provided CDE, however, this is not best practice nor
envisaged by ISO 19650-2.

3.2.1.2. When should the client establish the project CDE?

The ISO 19650 process requires the client to establish the project CDE during the assessment and
need stages of the information management process.

Why is it important to do that in the assessment and need stages?

Because this will enable all invitations to tender information to be provided through a secure,
organised, and effective environment – driving many of the benefits and reasons noted above.

3.2.1.3. Third Party

When the appointing party has elected a third party to manage the project CDE

The appointing party may elect to appoint a third party to provide and manage the common data
environment. ISO 19650-2 says;

The appointing party can also appoint a third party to host, manage or support the project’s CDE. In
this case, it is recommended that this is done as a separate appointment before procurement of any
other appointed party starts. Or the appointing party can also, at a later date, appoint an appointed
party to take over the hosting, management or support of the project’s CDE.
Extracted from ISO 19650-2 clause 5.1.7

3.2.2. DELIVERY TEAM

A separate delivery team CDE is often provided and implemented by a lead appointed party to
manage their project information whilst in the Work in progress state.
  Although not a requirement of ISO, this is typically done so as to retain control of
information by the delivery team until such point as they deem is suitable to share to the
project CDE.
 Information containers that are stored on a delivery team’s CDE should not be visible or
accessible to anyone else as a check, review and approve process is required before this
information can be shared with other parties.

3.3. Metadata attributes

3.3.1. What is metadata?

Metadata is data about data.

Revision, state, and classification are all information container metadata. These give categorisation
and context to the information container that can be used to derive structure in the CDE.

These metadata attributes are mandatorily required for information containers, in order for the CDE
to be compliant with ISO 19650.

A basic overview of States and Revisions will be laid out below, however, it is strongly recommended
that the section Explore above is reviewed and noted content additionally reviewed to get a fuller
picture of these topics.

According to ISO 19650-2 (clause 5.1.7 c);

The project’s common data environment – Each information container to have the following
attributes assigned:

 Status (suitability)
 Revision
 Classification (in accordance with the framework defined in ISO 12006-2)

3.3.1.1. Revision
ISO 19650-1 recommends that the information container revision system should follow an agreed
standard. The application of this system tracks the progression of information container revisions.
This is an important consideration for downstream parties who are dependent on the accuracy and
reliability of the information.

Example

As an example of best practice, the ISO 09650-2 national annex for the UK depicts the following

revision system (refer to BS EN ISO 19650 clause NA.4.3).

 Figure 8 The UK specific application of revision conventions

3.3.1.2. States
According to ISO 19650-1 (clause 12.1);

The current revision of live information containers within the CDE should be in one of the following
three states:

 Work in progress
 Shared
 Published

Current information containers can exist across all three states, depending on their
development.
There should also be an archive state providing a journal of all information container transactions
and an audit trail of their development.
See the below figure taken from ISO 19650-1 (Figure 10) for context of these states:
Figure 9Information Containers transition between states by the workflow process.

3.3.1.3. Classification
ISO 19650-2 clause 5.1.7 requires that information containers be assigned classification metadata in
accordance with ISO 12006-2.
It is important to classify information containers to agreed and established type standards in order
to understand the contents of the information container, rather than the form of the information
container (as this is typically dealt with by other metadata in the CDE solution).

Uniclass 2015 is compliant with ISO 12006-2 and is the preferred classification system in the UK. It
is referenced in the ISO 19650-2 National Annex.

Uniclass 2015 contains multiple classification tables which can be used to classify different types of
information containers.
The appointing party should define the classification method in the project’s information standard
as the national annex only acts to make a recommendation.
This would indicate which of the Uniclass 2015 tables are used for classifying information containers.
If the appointing party does not have a preference, then the lead appointed party would define
requirements.
3.4. Scenario 2
A new landmark museum is planned for the centre of the capital city.

During procurement, a prospective lead appointed party communicates to the appointing party that
their organisation’s policies require that information they produce be stored within their own
enterprise systems until it has been reviewed and found suitable for sharing externally. This policy
stems from a condition within their organisation’s indemnity insurance.

Simultaneously, project specific security requirements create two material considerations for the
management of project information:
1. An overarching requirement that all project information be protected, and unless approved
by the appointing party be made available only to members of the immediate project team
2. A heightened requirement for the museum’s security room which is considered a sensitive
area. Only parties with legitimate need should have access to information about this
location.

The solution
A common data environment may consist of multiple technical solutions since it is the workflows
between these that is most important. The nominated individuals for the appointing party and lead
appointing party agree that information in the work in progress state should be controlled within the
lead appointed party’s technical solution. The shared and published states will remain under the
control of the appointing party. A work in progress to shared state workflow is established which
incorporates both the check, review and approve processes needed by the lead appointed party’s
policy and the transition between the two technical solutions.

To resolve the overarching security consideration, the appointing party restricts common data
environment access to individuals within the project team. This restriction applies across both
technical solutions. A workflow is established by which parties can seek appointing party approval to
share information with external parties.

To resolve the heightened security consideration, the appointing party identifies a volume
encompassing the security room which is considered sensitive. Only individuals directly involved in
the design and construction of the security room will be permitted access to information within this
volume. Information containers holding information relating to the security room volume will be
appended with metadata identifying this condition. Using this metadata, the appointing party will
configure the technical solution so that only known and permitted individuals can view these
sensitive information containers.

3.5. Summary
 Using a project CDE on construction projects is explicitly included in ISO 19650-2, being the
responsibility of the Appointing Party to implement. However, there are a number of
reasons why implementing a CDE is beneficial, not just because it’s a requirement of ISO
19650.
 A CDE is made up of a CDE technical solution and CDE process workflow, both elements
must be present.
 Early establishment of a CDE is recommended, ideally before Tender stage, before
procurement of any other appointed party starts.
 There are important principals for management of Information Containers within a CDE that
must be considered, Revision, Status, and Classification.