Eir Guidance

Exchange Information
Requirements (EIR)
Guidance
BIM Toolkit | Exchange Information Requirements (EIR)
Guidance
Contents
Executive summary 1
1 Introduction 2
1.1 Exchange information requirements (EIR) purpose 2
1.2 Information management goals and objectives 3
1.2.1 Goals 3
1.2.2 Objectives 4
1.3 Information requirements hierarchy and documentation progression 4
1.3.1 Information requirements hierarchy 5
1.3.2 Exchange information requirements (EIR) response requirements 6
1.3.2.1 Pre-appointment BIM execution plan (pre-BEP) 6
1.3.2.2 Supplementary documents 7
1.3.2.3 Supplier capability and capacity assessment 7
1.3.2.4 Mobilisation plan 8
1.3.2.5 Information delivery risk assessment 8
1.3.2.6 Delivery team’s BIM execution plan (BEP) 9
2 Information requirements 10
2.1 Information purpose 10
2.2 Plan of work 11
2.3 Information delivery milestones 11
2.4 Information security requirements 12
2.5 Spatial coordination requirements 12
2.6 Project information model (PIM) 14
2.7 Asset information model (AIM) 14
2.8 Information management key performance indicators (KPIs) 15
2.9 Health and safety and design construction risk management 16
3 Information standards, information production methods and

procedures 18
3.1 Information standards 18
3.1.1 Project-specific standards 19
3.1.2 Information identification conventions 20
3.1.3 Method of assignment for level of information need 23
3.1.4 Data authoring 24
3.1.5 Information software platforms 25
3.1.6 Information model quality 26
3.2 Information production methods and procedures 27
3.2.1 Information management functions 27
BIM Toolkit | Exchange Information Requirements (EIR)
Guidance
3.2.2 Information collaboration process 29

3.2.2.1 Common data environment (CDE) workflow 30
3.2.2.2 Information exchange frequency 32
3.2.2.3 Mobilisation 32
3.2.2.4 Training 33
3.2.3 Authorisation and acceptance process 33
3.2.4 Spatial coordination strategy 34
3.2.5 Legacy information and shared resources requirements 35
3.2.6 Capture of existing asset information 35
3.2.7 Information container breakdown structure 36
3.2.8 Lessons learnt 37
Click or tap here to enter text.Click or tap here to enter text.Click or tap here to enter text.
Tables
Table 1.1: Information delivery risk assessment 8
Table 2.1: Information delivery milestones 11
Table 2.2: Spatial coordination information requirements 13
Table 2.3: Health and safety information requirements 17
Table 2.4: Key performance indicators (KPIs) 15
Table 3.1: Information container naming convention 20
Table 3.2: Metadata 21
Table 3.3: Security metadata 22
Table 3.4: Preferred software authoring tools 24
Table 3.5: Required exchange formats 25
Table 3.6: Information software platforms 26
Table 3.7: Quality requirements 26
Table 3.8: Information management responsibility matrix 28
Table 3.9: Legacy information and shared resources 35
Figures
Figure 1: Hierarchy of information requirements, source ISO 19650–1:2018 5
Figure 3.1: Common cata environment (CDE) workflow 31
Figure 3.2: Volume strategy; source: ISO 19650:2 37
BIM Toolkit | Exchange Information Requirements (EIR) 1
Guidance
Executive summary
The international information management standards ISO 19650–1:2018 and ISO 19650–2:2018 define
the recommended concepts and principles for information management using building information
modelling (BIM), as well as specifying the activities to be undertaken to support information
management during the delivery phase of an asset.
The ISO 19650 series outlines that the appointing party shall communicate their information
requirements for the delivery phase of an asset, to the project delivery team, through the creation of
several tender documents, including the exchange information requirements (EIR) and project
information standards, the information production methods and procedures.
To assist with the adoption of the ISO 19650 series principles for construction and infrastructure
projects, both the template and this guidance document have been structured to include the information
requirements (Section 2) and the project information standards, production methods and procedures
(Section 3). For more complex/non-traditional projects with multiple delivery teams, or for a project
delivery team with wide-ranging building information modelling (BIM) experience, the project information
standards, production methods and processes should be separated into their own contractual
document.
This guidance document has been developed to assist users in the completion of the exchange
information requirements (EIR) template.
Guidance
1 Introduction
Provide a high-level
explanation of the purpose
of the exchange The appointing party, {client name}, has developed these
information requirements exchange information requirements (EIR) for {project name}.
(EIR), how they will be It is structured to provide an understanding of its intended use,
used during the the information requirements and the relevant information
appointment and the standards, production methods and procedures to be adopted on
organisational objectives the project.
behind adopting the ISO
19650 series principles.
<This section is intended to help readers understand how the exchange information requirements (EIR)
should be used. This may be particularly useful for members of the prospective delivery team who may
not have experience with the ISO 19650 series principles. If any subsection content, especially Sections
1.3.2, is contained within another contractual document, it is recommended that it be omitted to prevent
confusion.>
1.1 Exchange information requirements (EIR) purpose
Explain the purpose of the The exchange information requirements (EIR) provide a
exchange information specification of the information requirements that are to be met
requirements (EIR) and throughout the delivery phase of an asset. This includes the
how they should be used acceptance criteria of the information standards, information
during this appointment. production methods and procedures.
<The following example demonstrates the document’s purpose, providing a summary for the reader(s).
When completing the template, use this section to explain the function of the exchange information
requirements (EIR), keeping in mind that this may be some task teams’ first experience of building
information modelling (BIM) processes and associated documentation.>
This exchange information requirements (EIR) document and its annexes form part of the invitation to
tender suite of documents. It outlines the information requirements that the delivery team must comply
with.
All existing project information will be supplied within the invitation to tender documentation suite, via
the common data environment (CDE).
Guidance
1.2 Information management goals and objectives
Provide a brief description

of your organisation’s
{Client name} are committed to the use of building information
commitment to building
modelling (BIM) for delivery of this project, enhancing existing
information modelling
processes, to realise both cost and programme benefits, through
(BIM); the subsections
promoting a collaborative approach to project delivery.
below will allow you to
expand on this.
<The example below demonstrates an appointing party’s goals and objectives for implementing the ISO
19650 series principles on a project. The aim is to provide the prospective delivery team with a greater
understanding of the intention of the requirements. These may be copied directly from the project
information requirements (PIR) if applicable. If the intention is for this document to be a technical
specification, for more experienced delivery teams, this section should be omitted.>
1.2.1 Goals
Identify high-level
organisational goals,
which will help the delivery
team to understand why
implementing building
information modelling The following information management goals support {client
(BIM) on the project is name}’s continuous improvement aims for delivery of their
important. Goals are projects.
usually wide overarching
targets that define the
general intentions and
ambitions of an
organisation.
<The example below demonstrates possible goals that the appointing party might want to achieve,
which should align with the project information requirements (PIR):>
• Promote continuous collaboration and coordination across the whole delivery team.
• Have access to the right project information at the right time, to make informed decisions.
• Utilise available, accurate project information for various uses, to the benefit of the project
stakeholders.
• Use information to drive transparent sign-off of deliverables.
• Achieve measurable cost savings through implementing information management processes
and coordination.
• Embed BIM information management processes as business as usual.
• Handover usable information at completion of the construction works.
Learn lessons collectively on the use of building information modelling (BIM) and record these for future
use.
Guidance
1.2.2 Objectives
Objectives are more

specific; they are precise To ensure a consistent approach to the production, management
actions or measurable and modification of information, the building information modelling
steps that the delivery (BIM) goals should be read in conjunction with the following
team can undertake to objectives that {client name} wish to achieve during the project.
achieve the goals.
<The example below demonstrates possible objectives to be adopted to achieve the overall goals.
Provide objectives that align with your specific goals:>
• Outline the requirements for producing project information in a single common data
environment (CDE) to be shared across all project work packages.
• Exchange agreed project information at established intervals during the project.
• Establish project-specific key performance indicators (KPIs) to measure progress and establish
project benchmarking.
• Collaborate using information models and data to ease review and decision-making.
• Have a fully coordinated design before commencement on-site.
• Ensure that appropriate asset metadata is embedded in the project information model (PIM)
and is suitable to meet the asset information requirements (AIR).
1.3 Information requirements hierarchy and documentation progression
Outline how the

information requirements
are structured and relayed
The subsections below outline the wider information
to the delivery team.
requirements’ structure and provide an understanding of how the
Include an explanation of
information deliverables are defined and the subsequent
what is expected in
information delivery plan developed.
response to these
exchange information
requirements (EIR).
Guidance
1.3.1 Information requirements hierarchy
Provide an understanding
of how the exchange
Information requirements for the delivery phase of an asset are
information requirements
defined by wider organisational strategic and project-specific
(EIR) are defined and their
requirements. These are relayed to the delivery team through the
influence on the
exchange information requirements (EIR).
information deliverables for
handover.
<The example below demonstrates the ISO 19650 series hierarchy of information principles, as
illustrated in Figure 1 (Hierarchy of information requirements, source ISO 19650–1:2018). This section
provides the delivery team with a better understanding of how these information requirements have
been developed, including which information deliverables they directly specify and produce.
Depending on the experience of the delivery team, this section may be omitted. If this section is to be
retained within the exchange information requirements (EIR), ensure that it accurately reflects the
appointment information requirements and subsequent information deliverables.>
Figure 1 (below) illustrates how the scope of this document is influenced by the hierarchy of information
requirements, as stated in ISO 19650–1:2018, and its subsequent provision of the specification for the
project information model (PIM).
Figure 1: Hierarchy of information requirements, source ISO 19650–1:2018

Guidance
1.3.2 Exchange information requirements (EIR) response requirements
All parties will have until the {insert date} to raise any queries
regarding the exchange information requirements (EIR), including
appendices or referenced documentation.
Outline the response All parties participating in the project bid will produce a pre-
criteria for the exchange appointment BEP (pre-BEP) in response to the exchange
information requirements information requirements (EIR), which should be submitted via
(EIR), which should align {insert method for tendering} to the appointing party no later
with the recommendation than {insert date}.
of ISO 19650–2:2018.
All submissions will be reviewed. The successful party will be
informed by {insert date}. A workshop should then be held
between the appointing party and lead appointed party to review
any comments and confirm acceptance.
<If these response requirements are included within another document, this subsection should be
omitted in order to avoid confusion.
Describe the response criteria and timeframes that need to be adhered to as part of this invitation to
tender. When a delivery team first adopts the ISO 19650 series principles, it may be useful to describe
the documents and their purpose.>
1.3.2.1 Pre-appointment BIM execution plan (pre-BEP)
The pre-appointment BIM In accordance with international ISO 19650 series, the
execution (pre-BEP) is prospective lead appointed party should produce a pre-
produced at the tender appointment BIM execution plan (pre-BEP) to demonstrate the
stage in response to the delivery team’s proposed approach and the relevant information
invitation to tender. It management competencies, to meet the exchange information
outlines how the delivery requirements (EIR).
team propose to meet the
information requirements In addition to information requested as part of the appointment
for this project. Describe process, a comprehensive pre-appointment BIM execution plan
the expected content. (pre-BEP) will include the following content.
<The example below demonstrates the expected pre-appointment BIM execution plan (pre-BEP)
content. Ensure that all the information you wish to receive as part of the tender submission in response
to the exchange information requirements (EIR) is outlined, including any supplementary
documentation or appendices.>
• Information delivery strategy:

o Approach to meeting the exchange information requirements (EIR)
o Objectives for information collaboration
o Delivery team’s organisational structure and composition
• Federation strategy
• Delivery team’s high-level responsibility matrix
• Proposed platform system schedule
• Information standards; proposed amendments and additions
• Information production methods or procedures; proposed amendments and additions
Guidance
1.3.2.2 Supplementary documents
Outline any supplementary

documents that you would
expect to be submitted as
part of the pre-
appointment BIM
execution plan (BEP). The documents below should be submitted alongside the pre-
appointment BIM execution plan (BEP).
This is especially
important if you are
supplying templates to be
completed to assist with
the evaluation process.
<Provide an explanation of any supplementary documents expected as part of the tender submission,
including any references to templates that should be used.>
1.3.2.3 Supplier capability and capacity assessment
Describe any expectations

of any pre-qualification
All task teams in the prospective project delivery team should be
questions specifically
able to demonstrate that they either possess, or have the
related to building
opportunity and commitment to attain, the relevant required skills
and experience to be eligible for pre-qualification.
(BIM) that the delivery
team are to answer. As part of the tender return, the prospective lead appointing party
should complete the capability and capacity assessment. Each
These could be
question should be answered and evidence supplied where
included/combined with a
appropriate.
wider project pre-
qualification questionnaire.
<If the capability and capacity assessment questions/criteria form part of a separate supplier’s
assessment/pre-qualification questionnaire, this could be referenced here, or this section could be
omitted to avoid confusion.
The prospective delivery team or task team(s) should answer an assessment, which provides evidence
of their capability (experience, training, etc.) and capacity (resource and information technologies) to
meet the information requirements.>
Guidance
1.3.2.4 Mobilisation plan
A mobilisation plan helps

to ensure that everything
is in place and working
correctly before a project
begins, which limits any
potential delay to the The lead appointed party should provide an explanation of the
project start date. mobilisation plan that will be performed prior to the project
commencement.
The delivery team should
identify all training, tests
and checks that will be
performed before any
project work begins.
<If the mobilisation criteria are included within another tender return or contractual document, this
subsection should be omitted to avoid confusion.>
1.3.2.5 Information delivery risk assessment

identify and report The delivery team should identify any potential risks that may
anything that could prevent them from delivering information in line with the
potentially prevent them information delivery milestones and provide a description of the
from meeting the delivery measures they intend to implement to mitigate these risks.
milestones, providing a This should include any assumptions made regarding the
description of how they information requirements. All items should be graded in terms of
intend to reduce or remove the severity of the impact on the project.
the risk.
<The example below, Table 1.1: Information delivery risk assessment), demonstrates that a schedule
could be included in the pre-appointment BIM execution plan or as a supplementary document, to define
any potential risks to meeting the information delivery milestones.
If the risk register is combined/included within other tender return or contractual documentation for risk
management, this subsection should be omitted in order to avoid confusion.>
Table 1.1: Information delivery risk assessment

Information
Work Potential Resolution
delivery Consequence Severity
stage resolution date
risk
Ensure that the CDE is
CDE isn’t Collaboration is
2 Med accessible before 19.06.20
accessible delayed
project commencement
Guidance
1.3.2.6 Delivery team’s BIM execution plan (BEP)
In accordance with ISO 19650 series, upon appointment, the lead

The delivery team’s BIM
appointed party will confirm the delivery team’s BIM execution
execution plan (BEP) will
plan (BEP).
be compiled by the lead
appointing party upon The first iteration should be a collaboration with the wider delivery
appointment. This involves team and include any comments from the appointing party.
updating their pre-
appointment BEP (pre- A workshop with the appointing party and whole delivery team
BEP) to include any should be held to provide a clear understanding of how the
feedback from the delivery team’s BIM execution plan (BEP) ensures delivery of the
appointing party and exchange information requirements (EIR). Any necessary
ideally further collaboration clarifications or feedback from this meeting should be confirmed
with the wider delivery by the appointing party prior to acceptance of the BIM execution
team. plan (BEP).
The delivery team’s BIM The delivery team’s BIM execution plan (BEP) must be submitted
execution plan (BEP) by the lead appointed party via {insert method for submission}
should demonstrate the on the {insert date}.
delivery methodology. This
A comprehensive delivery team’s BIM execution plan (BEP) will
section should outline the
include the content listed below. The purpose is to demonstrate
minimum content
an information delivery strategy that complies with the exchange
requirements.
information requirements (EIR) in a standardised method.
<The example below demonstrates the expected delivery team’s BIM execution plan (BEP) content,
which could either be adopted directly or modified to best suit the project requirements.>
• Information delivery strategy:

o Information management matrix
o Delivery team’s organisational structure and composition, including information
management matrix
o Approach to meeting the exchange information requirements (EIR)
• Federation strategy
• Delivery team’s high-level responsibility matrix
• Platform system schedule
Supplementary documents:
• Delivery team’s detailed responsibility matrix

• Master information delivery plan (MIDP) and task information delivery plan(s) (TIDP)
Guidance
2 Information requirements
Specify the information

requirements, which
should detail the
information deliverables
required to meet/answer This section captures the specification of each information
the project information requirement, which are to be adhered to in order to ensure the
requirements (PIR), where successful delivery of each delivery milestone.
applicable.
Each requirement should The delivery team shall detail their approach and programme in
align with the information order to comply with these requirements.
exchanges/delivery
milestones and be suitable
for the relevant delivery
team’s appointment.
2.1 Information purpose
Describe the intended use

of information generated
throughout the delivery
phase of an asset, which The information purposes of the list below are to achieve the
could include the relevant organisation’s information management goals.
project stages, providing
an understanding of each
requirement’s purpose.
<The information purposes could be identified either in this section or appended to the exchange
information requirements (EIR). They should align with, or be equivalent to, the project information
requirements (PIR), where applicable:>
• Complete feasibility study

• Planning permission
• Stage completion
Guidance
2.2 Plan of work
Define the project work

stages, which are typically
associated with a national
standard and reflected in
The project’s plan of work is the staged approach to the design
the ‘contract stages’.
and construction processes of the project.
These are provided to help
with understanding the
information delivery
milestones (below).
<Provide an explanation of the staged approach of the project, which could be a reference to a national
standard.>
2.3 Information delivery milestones
Information delivery
milestones are predefined
points where specified
information deliverables Information should be exchanged throughout the life of a project,
are exchanged, at various to enable decision-making at crucial milestones. The following
stages of a project. milestones are to be adhered to on the project/appointment.
Specify these milestones
for the project and relevant
appointments.
<The delivery milestones should reflect the project information requirements (PIR), where applicable.
Table 2.1) uses the above plan of works project work stages mapped against the milestones and their
relevant deliverables. These should be a high-level overview description/title, with the detailed
specifications being identified in the following (corresponding) information requirements in the
subsections below.
Ensure that the information milestones allow the appointing party, and its stakeholders, an agreed
period to evaluate and validate the information deliverables.>
Table 2.1: Information delivery milestones

Milestone
Project
Work package/activity Deliverables Date

stage
work
Feasibility study Programme

1 26.08.20
area schedule
2
Planning application
2
Guidance
2.4 Information security requirements
Identify any security All information generated for this project shall comply with the
requirements that are to following information security requirements. As a minimum, the
be adhered to on this baseline security measures defined below shall apply to all
project. project stages:
This could be based on 1. Protection of any commercially sensitive and/or personal

the appointing party’s data/information, as required, in compliance with ISO
security requirements for 19650–5:2020.
sharing information, or it 2. Information should be shared with members of the
could be project-specific, delivery team only, unless approved by the appointing
for instance, an asset that party.
is sensitive in nature, such 3. All project communication and information exchanges are
as a prison. conducted via the common data exchange (CDE).
<The ISO 19650–5:2020 security triage (Section 4.7) should be used to help to identify whether a
security management plan is required. If this is the case, a reference should be provided. If it isn’t
required, an organisation’s default information security requirement could be identified or referenced.>
2.5 Spatial coordination requirements
Throughout the project, the delivery team are expected to

Outline the information coordinate the information models in order to mitigate the
required to assess the potential of site rework.
accuracy of the design’s
spatial coordination. To ensure successful coordination, the following information
requirements are to be delivered at the defined work
stages/milestones.
<The example below demonstrates possible clash detection and avoidance strategy requirements that
are to be included as part of the tender submission.>
Exchange Information Requirements 13
Guidance
Table 2.2: Spatial coordination information requirements

Supporting
Milestone Description Information requirements Information container Exceptions Acceptance criteria
information
• All design
• GA plans and elevations
information in Information delivered to
• {Client’s @ 1:200 or 1:500
PDF format
name} • Visuals project specification and
1 Feasibility study • A spreadsheet N/A
project brief • GIA schedule m² adhering to project
including the units information standards
• Notional occupancy rates shown (.xlsx)
Spatial Clash resolution report,

Only tests identified
coordination including a summary of all
within the project A report on the last
4 progression/ N/A clashes and then detailed A single report (.pdf)
production working day of the month
monitoring information of each clash
methodology
rendition
<Milestone <Insert supporting <Insert information <Insert information

<Description> <Exceptions> <Acceptance criteria>
number> information> requirements> container>
Guidance
2.6 Project information model (PIM)
Define the information

deliverables required to At project handover, {insert work stage}, the project information
fulfil the handover of the model (PIM) should consist of all the approved milestone
project information model information for each work stage.
(PIM).
<This section provides an explanation of the information requirements for the project information model
(PIM) information delivery milestone. As this typically signifies part of the end of the delivery phase of
an asset, it is important to describe the expected information deliverables. The information standards,
information production methods and procedures for the deliverables are identified in Section 3.>
2.7 Asset information model (AIM)
Define or reference the

asset information At project handover, {insert work stage}, the asset information
requirements (AIR) to fulfil model (AIM) should be collated from the project information
the handover of the asset model (PIM) to meet the asset information requirements (AIR).
information model (AIM).
<This section provides an explanation of the information deliverables for the asset information model
(AIM) information delivery milestone. The asset information requirements (AIR) should be referenced,
where applicable, or included in this section. The information standards, information production
methods and procedures for the deliverables are identified in Section 3.>
Guidance
2.8 Information management key performance indicators (KPIs)
Provide project-specific
key performance
indicators (KPIs) that The lead appointed party is required to calculate and report the
support the commercial key performance indicators (KPIs) to the appointing party at
drivers. These should be agreed intervals.
quantifiable data that This enables the appointing party to determine the success of
provides the appointing their commercial building information modelling (BIM) aspirations;
party with an overview of the following key performance indicators (KPIs) have been
whether they are achieving identified.
the relevant commercial
aspirations.
<The example below, Table 2.3 (Key performance indicators (KPIs)), demonstrates possible key
performance indicators (KPIs) relating to the commercial drivers.>
Table 2.3: Key performance indicators (KPIs)
Responsibility
Work
Frequency
KPIs Requirement and deliverable stage/
milestone
Reduction Use the common data Lead Quarterly Project

design environment (CDE) to monitor the appointed stage 02 to
packages approval process for each party project
approval information delivery milestone. stage 05
This should be compared to
previous approval timeframes and
reported back to the whole
delivery team via the ‘KPI
progress report’ (PDF).
Reduction in <Description> <Insert <Frequency <Stage>
embodied responsible >
carbon party>
<Examples> <Description> <Frequency <Stage>
>
Guidance
2.9 Health and safety and design construction risk management
Identify the specific health The information models should be utilised to meet both the health
and safety requirements and safety and design and construction risk management
for the project. Expand on construction obligations of the project. This should be delivered in
the specific health and accordance with {name of standard}.
safety deliverables that the
delivery team will have to The delivery team is required to inform the appointing party of the
incorporate into the potential hazards and risks. This shall be communicated within
information model. the information model via the common data environment (CDE).
<The example below, Table 2.4 (Health and safety information requirements), demonstrates the
possible health and safety requirements that could be adopted. Alternatively, references to relevant
standards and/or protocols could be provided. Timeframes should be defined.
References to either internal or external standards should be referenced.>
The appointing party has provided the following guidance for the key health and safety deliverables
against each milestone.
Guidance
Table 2.4: Health and safety information requirements
Supporting Information Acceptance

Milestone Description Information requirements Exceptions
information container criteria
The progression of design
coordination is to be reported to
the appointing party. Risks should
have the following information
attributed to them: Schedule must be
- Risk Name federated; all
- Risk Category information should
- Risk Description be generated from
- Associated Product • Federated the information
• {Client’s name}
- Associated Activity health and model(s). Schedule
construction
Health and safety risk - Associated Location safety/risk format must comply
6 design risk N/A
management - Risk Assessment information with Section 8 of
management
Methodology schedule, in PAS 1192–6:2018
• PAS 1192–6:2018
- Agreed Mitigation .xls format and submitted bi-
- Risk Likelihood monthly.
- Risk Consequence
- Level Of Risk Work stages 02–05
- Proposed Mitigation (inclusive).
- Date Updated
- Date Reviewed
- Owner Discipline
• Risk Documentation
<Milestone <Insert supporting <Insert information <Acceptance
<Description> <Insert information requirements> <Exceptions>
number> information> container> criteria>
Guidance
3 Information standards, information

production methods and procedures
This section is divided into

two parts: the first half
should be used to This section provides the information standards, as well as the
determine the standards information production methods and procedures, that should be
that information containers implemented to meet the appointing party’s information
should comply with; and requirements. This is to ensure consistent quality and cohesive
the second half should information deliverables throughout the delivery phase of the
define their required asset.
production methodology
and procedures.
<Outline the purpose of the information standards, information methods and procedures for the
exchange information requirements (EIR) for the project.
This section has been included in the exchange information requirements (EIR) to assist with the
adoption of the ISO 19650 standard series, particularly in traditional projects where the delivery teams
work consecutively. However, this section could be separated to form its own contractual project
document, which would benefit projects where multiple delivery teams are working simultaneously,
reducing the potential for error by providing a single version of these information standards, information
production methods and procedures.
Amend this section to ensure that the information supplied to the appointing party meets the exchange
information requirements (EIR), which should include project information requirements (PIR) and asset
information requirements (AIR).>
3.1 Information standards
Define the standards that

information containers These standards are to be adhered to on this project.
should comply with.
Guidance
3.1.1 Project-specific standards
Throughout this document,

various standards will be
referenced; provide a
The standards specified below are referenced through this
list/directory of standards
section and should be adhered to as specified.
that will assist the delivery
team to understand the
information requirements.
<The example below demonstrates project-specific standards that could be adopted. Any standards
(both internal and external) that are to be used on the project should be listed, including their
revision/version. These should be reflected within the main body of the document.>
• ISO 19650–1:2018 – Organisation and digitisation of information buildings and engineering

works, including building information modelling (BIM) – information management using building
information modelling.
• ISO 19650–2:2018 – Organisation and digitisation of information about buildings and civil
engineering works, including building information modelling (BIM) – information management
using building information modelling.
• BS 1192–3:2014 – Specification for information management for the operational phase of
assets using building information modelling.
• BS 1192–4:2014 – Collaborative production of information Part 4: Fulfilling an employer’s
information exchange requirements using COBie.
• Uniclass 2015.
• PAS 1192–6:2018 – Specification for collaborative sharing and use of structured health and
safety information using BIM.
<Other standards and specification to be added here.>
If any of the standards detailed above or throughout this document are superseded during the project,
the lead appointed party shall provide the appointing party with a report detailing the change in standard
and any implications that the adoption of these changes will have for the project.
The revised standard can only be implemented following an explicit agreement from the appointing
party.
Guidance
3.1.2 Information identification conventions
Information identification
conventions (naming
conventions) are an
essential part of the
production of information. To realise true project efficiencies, it is essential that information
They allow easy containers be easy to locate and identify, without being reliant on
identification of the data, the structure of the common data environment (CDE). The use of
such as information type, a consistent information container identification convention
the originator and the area (naming conventions) is key to achieving this.
of the project that
information relates to, This section contains specific references to identification
without opening the conventions for files, spaces and objects.
information container.
Provide references to all

relevant naming
conventions, either internal
or external standards.
3.1.2.1 Information container identification

<The example below, Table 3.1 (Information container naming convention), demonstrates possible
information container identification naming conventions (only); it is based on the United Kingdom’s
National Annex (NA). The applicable National Annex could be adopted.
Provide either a detailed explanation of the identification for information containers, spaces and
objects/elements within your project or references to identification standards that should be adhered
to.>
Information container identification conventions should follow the definitions outlined in ISO 19650–
1:2018.
Each data field represents a specific property with an associated code, including the permitted number
of characters for each.
Table 3.1: Information container naming convention

Field 1 Field 2 Field 3 Field 4 Field 5 Field 6 Field 7
Project Originator Volume or Level Type Discipline File number
system
XXXX XXX XX XX XX X XXXX
Example: LT09-MML-00-XX-M3-C-0001
Guidance
3.1.2.2 Common data environment (CDE) metadata requirements
Metadata is a fundamental
part of the common data
environment (CDE)
management. Metadata
helps to manage the
Information containers should include a metadata field; this could
information workflow.
be achieved via the common data environment (CDE) for
Identify metadata
metadata associated with file containers. The delivery team
requirements, which will
should describe how they will implement the following metadata
depend on the complexity
requirements.
of the project.
All files shall be populated with appropriate metadata in
This section should specify
accordance with the requirements below.
the metadata that is to be
assigned to all information
containers within the
common data environment
(CDE).
<The example below demonstrates potential subsections that provide further information about
metadata requirements, aligned with ISO 19650–2:2018, using the codification identified from the
United Kingdom’s National Annex (NA). An applicable National Annex could be adopted.>
Status and revision metadata

Information containers within the common data environment (CDE) shall be assigned the following, see
Table 3.2: Metadata, status and revision metadata).
Table 3.2: Metadata

Status code Description Suitability Revision
Work in progress (WIP)
S0 Work in progress N/A P01.01, P0n etc.
Shared (non-contractual)
S1 Suitable for coordination For coordination P01, P0n etc
S2 Suitable for information For information P01, P0n etc
S3 Suitable for review and comment For comment P01, P0n etc.
S4 Suitable for stage approval For acceptance P01, P0n etc.
S6 Suitable for PIM authorisation Preliminary revision P01, P0n etc.
S7 Suitable for AIM authorisation Preliminary revision P01, P0n etc.
Published documentation (contractual/completed)
A1, An Authorised and accepted For construction C01, C0n etc.
CR As constructed record As built C01, C0n etc.
document
Guidance
Security classification
All project information shall be treated with confidence. The

project security requirements have been identified in the
information requirements.
Security classification The specified security classification should be assigned to the
codes help to manage relevant information container.
information containers that
require restricted access. These metadata codes are to determine the information’s
visibility within the common data environment (CDE) and
throughout the project; the delivery team are to outline their
approach to complying with the security requirements of this
project.
<The example below, Table 3.3: Security metadata), demonstrates possible security classification; it
is important that this section be modified to suit both project and/or national requirements.>
Table 3.3: Security metadata

Code Title Description
Publicly Available Information approved for publication outside the appointed party
PA
information system.
Internal Use Only Information for appointing party {client name} only and authorised
IO
appointed party.
Confidential Information that is commercially or operationally sensitive, and

CI disclosure or loss could have an impact on the appointed party
businesses, not limited to financial or reputational damage.
Legally Privileged Legal professional privilege protects confidential communications

LP
between lawyers and clients.
Strictly Confidential This refers to information that is commercially or operationally

SC sensitive, and disclosure would have a significant impact on the
appointing party’s business, its assets or individuals.
Price Sensitive ‘Inside information’ in the UK and ‘material non-public information’ in

PS
the US.
Critical National Information that relates to critical national infrastructure systems and
CNI Infrastructure processes utilised for the safe, secure and reliable transmission of
electricity and gas.
Information classification
To assist with the identification of information containers and

Provide references to the model elements, it is important that the relevant information
information classification classification requirement that complies with the information
standards to be adopted requirements be adhered to.
for information containers
and model elements. Provide a methodology for incorporating these classifications in
line with information requirements.
Guidance
3.1.3 Method of assignment for level of information need
It is important that every

delivery team member
understands exactly what
information they are This section specifies the level of information need (LOIN)
responsible for producing, standard that is required for specific information deliverables.
which includes how much
data and graphical detail
are required at each
project stage.
3.1.3.1 Level of detail (LOD) and level of information (LOI)

<Example of possible level of detail (LOD) and level of information (LOI) requirements, which could be
replaced with a reference to an applicable standard.>
To articulate the specified level of information need, the following properties have been assigned to
information within the responsibility matrix:
• Level of detail (LOD) refers to the amount of detail shown in the graphical digital representation,
at a particular stage of the project.
• Level of information (LOI) refers to the amount of information (data) contained/associated with
the model at a particular stage of the project.
Both the level of detail (LOD) and level of information (LOI) will increase through the life cycle of a
project, potentially at different rates, and they are therefore specified separately. These shall be defined
using the NBS definitions library available at https://toolkit.thenbs.com/definitions
Guidance
3.1.4 Data authoring
The delivery team should state their planned authoring software

and version for all information containers in order to mitigate any
potential interoperability issues, impact and disruption.
Consider which native file
It is fundamentally important that all task teams that plan to use
formats will be required in
different software from those listed in the table below clarify their
order for the appointing
procedure to enable complete collaboration and interoperability
party to utilise the
for all relevant information containers.
information model.
The lead appointed party is responsible for procuring, testing and
implementing any required IT infrastructure, hardware and
software required for activities within their scope.
<The example below, Table 3.4 (Preferred software authoring tools), demonstrates possible data
authoring requirements in a table format that provides a list of desirable software for model and drawing
authoring.>
Table 3.4: Preferred software authoring tools

Discipline Software Year Version Format
Architecture Software X 2019 X.1 XYZ
Civil - - - -
Structural - - - -
M&E - - - -
Drainage - - - -
To support the use of, and access to, information for all project stakeholders, the following guidelines
shall be met:
• Individual information containers shall not exceed 250Mb.

• Information containers shall not contain any geometry or information greater than the level of
information need (LOIN) requirement defined in the responsibility matrix.
Guidance
3.1.4.1 Data exchange formats
Specify the file formats

required for the
information containers that
the delivery team is
required to comply with.
It is important to Information is required to be exchanged in the specified formats

understand how you at agreed stages in the programme. The formats of each file type
intend to use the are defined below.
information. For instance,
Where there is a requirement to exchange information in a format
reports may only need to
other than those prescribed, the delivery team shall provide
be issued in PDF format
details of how they will address interoperability issues.
for review and comment,
whereas schedules may
need to be in both PDF
format for version control
and XLS format for
analysis of the data.
<The example below, Table 3.5 (Required exchange formats), demonstrates possible data exchange
formats.>
Table 3.5: Required exchange formats

Native file required
Type Version Rendition required formats
formats
Project schedule, Gantt XLS(X) / PPT(X) / XML /
2018 PDF
charts MMP etc.
3D CAD models XYZ 2019.1 PDF, IFC
CAD drawings XYZ 2019.1 PDF
GIS models XYZ 2020 PDF
Cost plans XLS(X)/CSV, etc. 2018 PDF
XLS(X)/PPT(X)/XML/MMP,
Programmes 2018 PDF
etc.
Photos, videos, animations .JPG/AVI/MP4, etc. - -
3.1.5 Information software platforms
To ensure that the

The software platforms identified below will be used by the
information containers will appointing party throughout the project life cycle and into
be functional on your
operation. The delivery team is required to take them into account
organisation’s internal
when responding to the information requirements.
systems, it is important to
provide a list of the The appointing party will be using the following platforms and
software platforms that versions across their projects.
you intend to use.
<The example below, Table 3.6 (Information software platforms), demonstrates proposed information
software platforms. Outline what systems are to be utilised by your organisation, including version
requirements, where applicable.>
Guidance
Table 3.6: Information software platforms

Purpose Software/platform Version
Data management system Y Software Y.2
(e.g. common data
environment (CDE))
Drawing and model viewers <Software name> <Software version>
If the delivery team do not wish to use these specific software solutions for the delivery or production of
project information, they should recognise the above listed platforms and identify how they will
exchange information with these platforms.
Any restrictions when interfacing with the above systems should be raised with the appointing party
prior to using systems other than those listed here. These limitations shall include:
• Access to systems and software, as well as licensing restrictions;

• Hardware restrictions;
• Security restrictions; and
• Network restrictions and integration issues.
3.1.6 Information model quality
Provide the minimum

quality assurance
Task team members shall execute the following quality control
requirements that each
(QC) procedures.
aspect of the information
model should adhere to.
<The example below, Table 3.7: Quality requirements), demonstrates a possible quality assurance and
quality control methodology that may be adopted in table format. Ensure that the minimum expectation
of all information is outlined.>
Table 3.7: Quality requirements

Information container
Quality requirements
aspect
Geometrical model files Spatial integrity information models shall not be accepted if deemed
unsuitable:
• All items are to conform to their level of detail (LOD) requirements
within the responsibility matrix.
• All drawings shall be derived from geometrical models to maintain
accuracy and coordination.
Model spatial integrity The following rules shall apply to the model spatial integrity:
• Space definition – bounding boxes used to represent spaces and
zones shall match architectural requirements and data values.
• All walls shall be properly joined to prevent spaces being incorrectly
defined. Bounding boxes of spaces shall not conflict.
• Spatial information shall be generated and associated with bounding
elements (walls, doors, windows, floors, columns, ceilings).
Material integrity <Specific quality requirements>
Guidance
3.2 Information production methods and procedures
The different methods of

generating data and
information can potentially
impact its functionality.
The following information production methods and procedures
Determine the information
are to be adhered to on this project.
production methods and
procedures. This could
include responsibilities,
workflows and approval
processes.
<Define information production methods and procedures, as specified within ISO 19650–2:2018, 5.1.5,
which should reflect the purpose and functionality required for the information deliverables.>
3.2.1 Information management functions
This section allocates the responsibility for each member involved

in information management activities within the project.
The following principles apply to all building information modelling

To prevent poor (BIM) roles and responsibilities:
information management, • Information management is part of everyone’s job;
it is important that
• These tasks can be performed by more than one
everyone involved in the
individual;
project understands their
• An individual can perform more than one task;
information management
• Individuals must be competent to undertake these
function responsibilities.
tasks;
• Individuals must have the authority to undertake
these tasks.
These do not negate any design responsibilities.
<ISO 19650–1:2018 Annex A, Table 3.8 (Information management responsibility matrix), provides an
RACI (responsible, accountable, consulted and informed) matrix for the information management
functions. If adopted, this should be completed to identify the delivery teams’ responsibilities. This table
could be expanded or reduced to suit; ensure that it includes only the relevant activities for the project.>
Key
R Responsible for undertaking activity
A Accountable for activity completion
C Consulted during activity
I Informed following activity completion
Guidance
Table 3.8: Information management responsibility matrix
Lead appointed party

Appointing party
Appointed party
Information management activity
Third party
Appoint individuals to undertake the information management function.
Establish the project's information requirements.
Establish the project's information delivery milestones.
Establish the project’s information standard.
Establish the project's information production methods and procedures.
Establish the project’s reference information and shared resources.
Establish the project's common data environment.
Establish the project's information protocol.
Establish the appointing party’s exchange information requirements.
Assemble reference information and shared resources.
Establish tender response requirements and evaluation criteria.
Compile invitation to tender information.
Nominate individuals to undertake the information management function.
Establish the delivery team's pre-appointment BIM execution plan (pre-BEP).
Assess each task team’s capability and capacity.
Establish the delivery team's capability and capacity.
Establish the delivery team’s mobilisation plan.
Compile the delivery team's tender response.
Confirm the delivery team's BIM execution plan (BEP).
Establish the delivery team’s detailed responsibility matrix.
Establish the lead appointed party’s exchange information requirements.
Establish the task information delivery plan(s).
Establish the master information delivery plan.
Complete the lead appointed party’s appointment documents.
Complete the appointed party’s appointment documents.
Mobilise resources.
Mobilise information technology.
Test the project’s information production methods and procedures.

Guidance
Lead appointed party

Appointing party
Appointed party
Information management activity
Third party
Check availability of reference information and shared resources.
Generate information.
Undertake quality assurance check.
Review information and approve for sharing.
Information model review.
Submit information model for lead appointed party authorisation.
Review and authorise the information model.
Submit information model for appointing party acceptance.
Review and accept the information model.
Archive the project information model.
Capture lessons learned for future projects.
3.2.2 Information collaboration process
Define the expectations for Collaboration of all project information is key to effective project
collaboration on this delivery. Collaboration is enabled by the project tools, for
project and describe the example, the common data environment (CDE), but it is made
relevant collaboration effective by the culture and tone set by the leadership team.
processes. This should Improved processes for sharing information should not suppress
include information traditional informal collaboration such as holding meetings but
exchanges and meetings rather provide efficiencies by forming a ‘single source of the
for the whole delivery truth’.
team.
The following subsections outline the project’s collaboration.
requirements.
Guidance
3.2.2.1 Common data environment (CDE) workflow
Outline the common data

environment (CDE)
procedures for the project.
If the common data
environment (CDE) is
The appointing party {lead appointed party/appointed party}
being hosted by the
will be managing the common data environment (CDE) and
appointing party, a
provide access to the delivery team, meeting any project security
detailed description of the
requirements. All information containers (i.e. reports, drawings,
information exchange
models, specification) will be shared via the common data
process should be
environment (CDE) solution. Information exchanges are to be
provided. If it is to be
performed as per the prescribed workflows below.
hosted by others, provide
an overview of the
minimum workflow
requirements that they are
expected to meet.
<The example below demonstrates a high-level common data environment (CDE) workflow, which
could be adopted or modified to suit your project needs. Ensure that each expected procedure is
outlined, including responsibilities, where appropriate. It is expected that the lead appointed party may
wish to expand this section following their appointment.>
Figure 3.1: Common data environment (CDE) workflow) below illustrates the process overview that the
delivery team must use for the creation, collaboration and issue of project information. This is required
for consistency, ensuring that information is managed and delivered in a timely manner.
This workflow is based on the ISO 19650–1:2018, Figure 10 (Common data environment (CDE))
concept.
Guidance
Figure 3.1: Common data environment (CDE) workflow
Diagram key:
1. The delivery team will produce their information either on a separate common data environment
(CDE) solution or on their local server. When information is ready to be shared with the delivery
team, the task team will perform their quality control procedures to ensure that information
meets the information standard. If the information container is deemed suitable, it will be
uploaded to the common data environment (CDE) as SHARED. SHARED information
containers with an appropriate status may be used by the delivery team for collaboration
purposes. These information containers are referenced by the relevant task teams to support
the development of their own information. This process happens until a sufficient degree of
information has met the requirements to fulfil an information delivery milestone.
2. When information is ready to be submitted for project stage completion at an information
delivery milestone, it is uploaded to the common data environment (CDE) as SHARED with the
appropriate status code (see Section 4.3.1), which informs the lead appointed party that the
information container is ready to be authorised and accepted, if appropriate.
Authorised/accepted information containers will be uploaded to the common data environment
(CDE) as PUBLISHED; typically, PUBLISHED information containers will become the project
information model (PIM).
3. ARCHIVE facilitates an audit trail of all the information containers shared and published
throughout the project.
Guidance
3.2.2.2 Information exchange frequency
Define the minimum

frequency of information
exchanges expected of the Collaboration requires regular, concise and effective
delivery team. This should communication. It relies on the delivery team being able to
include everything from access the current version of all relevant information, which can
coordination meetings to only happen through consistent information exchanges.
periodical graphical model
sharing.
3.2.2.3 Mobilisation
A mobilisation plan helps

to ensure that everything
is in place and working
Before project commencement, and when a new task team is
correctly before a project
appointed, the mobilisation activities below should be undertaken:
begins, which limits any
potential delay to the - Software, hardware and network set-up procedure;
project start date. - Software and platform training (common data
environment (CDE) platforms and building information
modelling (BIM) authoring and coordination software);
identify all the training,
- Software, platforms and hardware testing strategy.
tests and checks that will
be performed before any
project work begins.
Guidance
3.2.2.4 Training
Every delivery team’s

In order to promote consistency of project information standards,
combined building
information production methodology and procedures, training
should be provided to the delivery team on the information
(BIM) experience will be
requirements only, by the lead appointed party.
unique, and each
appointed party will be This will be provided through team inductions and/or the provision
responsible for any of appropriate training material. This will cover:
training requirements that
are identified in the • Overall software platforms architecture;
delivery team’s capacity • Common data environment (CDE) protocols (including
assessment. structure and usage);
However, to promote • File, space and element identification conventions;
consistency of project • Levels of information need (LOIN);
information standards,
• Coordination and collaboration process;
information production
methodology and • Information production workflows;
procedures, it is important • Graphical outputs;
that the lead appointed
party provides training for • BIM responsibilities;
the whole delivery team on • Document change control procedures;
these project-specific Metadata and master information delivery plan (MIDP).
requirements.
<The example below demonstrates possible elaboration of training prerequisites.>
Team inductions should occur when a new task team joins the project and/or after any subsequent
changes to building information modelling (BIM) documentation.
Records of previous and ongoing training will be submitted to the appointing party upon request. This
can include a register of completed training, as well as sample material used in the delivery of training.
3.2.3 Authorisation and acceptance process
The common data

environment (CDE)
workflow provides an When the delivery team has completed an information container,
overview of how they shall submit it for authorisation and acceptance.
information should be
managed. This section The following outlines the authorisation and acceptance
should provide a detailed processes that the appointing party shall undertake on this
description of the project.
authorisation and
acceptance processes.
<Below is an example of possible authorisation and acceptance processes that align with the ISO 19650
standard series that may be adopted, if suitable for the project needs. Provide a step-by-step guide that
instructs the prospective delivery team how to submit information and the various outcomes.>
Authorisation
1. The task team will upload the information as SHARED with the appropriate status code (in line
with Section X.X.X), which identifies that the information container is suitable for lead appointed
Guidance
party authorisation. If the common data environment (CDE) does not have the functionality to
notify the lead appointed party of the information status and upload, it will be the responsibility
of the originator to inform them of the intent to submit information for authorisation.
2. The lead appointed party will verify the information/work package against the master
information delivery plan (MIDP), appointing party exchange information requirements and lead
appointed party exchange information requirements:
a. If the information does not conform to the information requirements for that information
exchange, this will be identified within the common data environment (CDE) feedback
function, and this should notify the originator that the information requires amendments
before resubmitting it to the lead appointed party for authorisation.
b. If the information is authorised, the lead appointed party will ask the relevant task teams
to submit the information, via the common data environment (CDE), for appointing party
acceptance, if applicable.
Acceptance
3. The task team will upload the authorised information as SHARED with the appropriate status
code (in line with Section X.X.X), which identifies that the information container is ready for
appointing party authorisation. If the common data environment (CDE) does not have the
functionality to notify the appointing party of the information status and upload, it will be the
responsibility of the lead appointed party to inform them of the intent to submit information for
authorisation.
4. The appointing party will verify the information/work package against the master information
delivery plan (MIDP) and appointing party exchange information requirements:
a. If the information does not comply with the information requirements for that information
exchange, the relevant metadata will be applied to all information containers associated
with this information exchange via the common data environment (CDE). This should
notify the information originator that the information requires amendments before
resubmitting it to the appointing party for authorisation.
b. If the information is authorised, the party responsible for managing the common data
environment (CDE) will apply the relevant metadata so that these information
containers are considered PUBLISHED.
Failure to authorise or accept deliverables according to the master information delivery plan (MIDP) will
not imply an additional variation/compensation to the contract.
3.2.4 Spatial coordination strategy
Outline the expectations

for how the delivery team Throughout the project, the delivery team are expected to
are to ensure a coordinate the information that they exchange in order to mitigate
coordinated design the potential of site rework. This will be a combination of
through spatial information planning, including the federation strategy and clash
coordination. Specify how renditions.
the delivery team should
illustrate the spatial The delivery team should define the procedures to ensure that
coordination workflow and spatial coordination is achieved, including timeframes,
the methodology of responsibilities and reporting.
reporting clash resolutions.
Guidance
3.2.5 Legacy information and shared resources requirements
Reference any legacy

information or shared To assist with both the tender process and the collaboration of
resources that are to be information production throughout the delivery phase of the
utilised on this project. asset, the following legacy information and shared resources
Specify their intended use, have been provided.
permissions and location.
<If any legacy information (past planning applications, etc.) or shared resources would assist with the
development of the project, they should be made available to the delivery team. Use this section to
provide the information reference and its intended usage.>
All legacy information and shared resources are located within the common data environment (CDE)
and shown in Table 3.9 (Legacy information and shared resources).
Table 3.9: Legacy information and shared resources
Information name/
Reference Format Origin Allowed usage
description
LT09-MML-00-XX-M3-C- Existing infrastructure
XYZ MML For reference only
0001 model
<Format> <Informatio
<Insert information <Insert information name <Insert information
n
container identifier> or description> container identifier>
originator>
3.2.6 Capture of existing asset information
Describe how the delivery

team are to capture
existing asset information
throughout the project.
This may be through the Any existing project/asset information that is required should be
use of traditional survey captured using the following methods and procedures.
techniques or more
sophisticated techniques
such as 3D scanning and
photogrammetry.
<Outline the method for capturing existing information relating to the project.>
Guidance
3.2.7 Information container breakdown structure
The information container

breakdown structure is an
important model The information container breakdown structure should be
coordination management developed during the information planning activities. It should
tool. The appointing party explain how the information model is intended to be divided into
should outline how the sets of information containers.
information model should
be organised and divided. The information container breakdown structure explains the
The appointing party can methodology to manage interfaces associated with the asset
also decide to delegate during its delivery phase.
this part of the process to
the lead appointed party.
<The example below demonstrates possible information container breakdown structure requirements.
These could be modified to suit project needs.>
The information container breakdown structure should divide the project information model (PIM) into
discipline-specific subsets such as:
• Civil engineering
• Landscape
• Architecture
• Structural
• Mechanical
• Electrical
If more breakdown/subsets are required because of the anticipated file size or project complexity, this
should be identified in proposed amendments to the information standard as part of the tender response
by the prospective lead appointed party.
The information container breakdown is considered the first step to spatial coordination within the
project; it should explain the methodology to manage the interfaces associated with the different
disciplines during the project, as well as any intended federations of information container breakdowns.
Figure 3.2 (Volume strategy; source: ISO 19650:2)Error! Reference source not found. provides a
federation strategy example in case of a linear infrastructure project. The different discipline areas are
depicted in different colours.
Guidance
Figure 3.2: Volume strategy; source: ISO 19650:2
3.2.8 Lessons learnt
To maximise the success

of projects, as well as To maximise the success of projects, as well as mitigating their
mitigating their failures, it failures, it is important to obtain feedback and recommendations
is important that from the whole delivery team.
feedback/lessons learnt be
This will take place during lesson learnt reviews, which should be
integrated into project
conducted at the end of the project by the appointing party. All
activities.
feedback should be reported to the appointing party. Any
Specify when lesson learnt suggested adjustments to the current information requirements,
reviews should occur and information standard or information production methods or
how the feedback should procedures should be reported to the appointing party, detailing
be adopted in the current the implications of adopting these changes.
project, if appropriate.

Eir Guidance

Uploaded by

Copyright:

Available Formats

Eir Guidance

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Eir Guidance

Uploaded by

Copyright:

Available Formats

Exchange Information

3 Information standards, information production methods and

3.2.2 Information collaboration process 29

1.1 Exchange information requirements (EIR) purpose

1.2 Information management goals and objectives

Provide a brief description

Objectives are more

1.3 Information requirements hierarchy and documentation progression

Outline how the

1.3.1 Information requirements hierarchy

Figure 1: Hierarchy of information requirements, source ISO 19650–1:2018

1.3.2 Exchange information requirements (EIR) response requirements

1.3.2.1 Pre-appointment BIM execution plan (pre-BEP)

• Information delivery strategy:

1.3.2.2 Supplementary documents

Outline any supplementary

1.3.2.3 Supplier capability and capacity assessment

Describe any expectations

1.3.2.4 Mobilisation plan

A mobilisation plan helps

1.3.2.5 Information delivery risk assessment

The delivery team should

Table 1.1: Information delivery risk assessment

1.3.2.6 Delivery team’s BIM execution plan (BEP)

In accordance with ISO 19650 series, upon appointment, the lead

• Information delivery strategy:

• Delivery team’s detailed responsibility matrix

Specify the information

2.1 Information purpose

Describe the intended use

• Complete feasibility study

2.2 Plan of work

Define the project work

2.3 Information delivery milestones

Table 2.1: Information delivery milestones

Work package/activity Deliverables Date

Feasibility study Programme

2.4 Information security requirements

This could be based on 1. Protection of any commercially sensitive and/or personal

2.5 Spatial coordination requirements

Throughout the project, the delivery team are expected to

Table 2.2: Spatial coordination information requirements

Spatial Clash resolution report,

<Milestone <Insert supporting <Insert information <Insert information

2.6 Project information model (PIM)

Define the information

2.7 Asset information model (AIM)

Define or reference the

2.8 Information management key performance indicators (KPIs)

Table 2.3: Key performance indicators (KPIs)

Reduction Use the common data Lead Quarterly Project

2.9 Health and safety and design construction risk management

References to either internal or external standards should be referenced.>

Table 2.4: Health and safety information requirements

Supporting Information Acceptance

3 Information standards, information

This section is divided into

3.1 Information standards

Define the standards that