Stage 1 – Assessment and Need – BIM Academy: Learning and Development

Information Management is distinct from information production and delivery but is closely linked to them. Information Management should be applied during the whole life cycle of the asset.

Within the information management process, the number and description of sub-divisions of the asset life cycle (solid rectangles), points of information exchange (solid circles) and decision points for delivery teams, interested parties or appointing party (diamonds) should reflect local practice, interested party and appointing party requirements, and any agreements or requirements specific to project delivery or asset management.

Key decision points are when the appointing party and other stakeholders make informed decisions about the project such as, whether or not it is financially viable to proceed to the next stage or decisions about the appointment of the project team. These decisions are made using information received from information providers.

A key decision point can be “y” weeks before the end of a work stage or after the beginning of a work stage.

Some suggest that a key decision point aligns to the end of a work stage but key decisions can be made at any time. Examples might include decisions related to tendering or planning permission. Key decision points need to be mapped out at the start of the project,

Information delivery milestones are predefined points that specify when the required information should be delivered to the appointing party.

Information delivery milestones should be defined relative to key decision points, for example, “x” weeks before a key decision point. There are likely to be cases where multiple exchanges may occur at the same information delivery milestone, for example where information models are to be delivered for checking by different delivery teams before being used by the appointing party at a key decision point,

When key decision points and information delivery milestones are defined it will be unlikely that all their specific dates will be known. Even so, the dates can and should be defined in relative terms as indicated

Key Decision Points:

2. Invitation to tender
3. Tender response
4. Appointment
5. Mobilization
6. Collaborative production of information
7. Information model delivery

The level of information need is a framework for defining the quality, quantity and granularity of information.

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

The level of information need is a framework to define the quality, quantity and granularity of information requirements.

To find out more about the level of information need please refer to BS EN 17412-1:2020 Building Information Modelling: Level of Information Need. Concepts and principles.

The level of information need is a framework to define the quality, quantity and granularity of information requirements.

More information about the level of information need refer to BS EN 17412-1:2020 Building Information Modelling: Level of Information Need. Concepts and principles.

The level of information need is used to communicate clearly the degree of information required according to its purpose; no more and no less.

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

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

It is the level of information need framework that allows first the information receiver (specifier) (appointing party or lead appointed party) to define the different “shapes” and “sizes” of the information deliverables in a standardized way. Using the level of information need, the information receiver (specifier) can define the quality (green or purple circles, blue or pink triangles), quantity (two triangles and three circles) and granularity (small or big circles) of information.

At each stage of the process, the model and data progression growth as the project matures and develops. An increase in the graphic model definition and structured data also increases.

LOD 1 -Brief Information (Mass, layout intent and space definition) (SYMBOLIC)
LOD 2 – Concept Information (Overall definitions) (CONCEPTUAL)
LOD 3 – Developed Generic Detailed Information (Layered details) (GENERIC)
LOD 4 – Specified Detailed Coordination Information (Defined element details) (SPECIFIC)
LOD 5 – Specified Manufacture/Fabrication Information (FOR CONSTRUCTION/RENDERING)
LOD 6 – As Constructed Information (AS BUILT)
LOD 7 – In-use

Information should be defined across the following three sub-divisions, for the Project Information Model (PIM) and the Asset Information Model (AIM):

Geometrical information
Alphanumerical information
Documentation.

Each sub-division of level of information need is defined in detail in BS EN 17412-1.

Responsibility Matrix

1. Project lifecycle stages.
2. Purpose of each stage.
3. Alignment with agreed data drops.
4. Graphical and non-graphical information requirements.
5. Split between disciplines.
6. Responsibilities for each and the required level of information need.

Information delivery milestones identify the key information delivery items and dates in relation to the project’s plan of work.

The benefits of a well-defined project information standard are that it enables information to be:

• Searched and retrieved – To ensure that information is discoverable, secure and retrievable
• Used and Re-used – The information that users can be reused or repurposed
• Spatial Coordination – The information is spatially is coordinated
• Presentational Consistency – Presented in a format that all parties can access and view

How information should be exchanged using different formats. The transferred format is essential to ensure that information that exchanges not only can be exchanged but is fundamentally useful for all readable and useable.

How will our supplier name information?
How will suppliers share and exchange information?
How will the appointing party review the exchange information?

A classification system is a means by which ‘things’ can be codified and named consistently so that the same thing is not codified or described in different ways.

Classifications enable you to break down an asset into small manageable parts that make up the asset. The benefit of doing this will help clarify the bills of quantities (basically your cost for the project and control budgets). And at a granular level, help you schedule your workflow for construction sequencing through tagging a product level at a system level for completion of works.

Classifying information into codes enables tagging of models outputs to the COBie datasheets. This will help with “Costing” e.g. the Bills of Quantity’s and project management activities.

Graphical models that are not spatially coordinated presents a significant risk to any project as the information is not accurate and the decisions made using that information will be wrong.

There are a few ways to ensure that graphical models can be spatially coordinated from the outset, including, but not limited to:

• Origin & Orientation – The origin of a graphical model is the real-world point that all information is referenced against and its orientation reflects the rotation of the asset in accordance with the origin.

• Coordinates – In combination with the origin, a coordinate system is primarily used to enable graphical model elements to be placed in the correct location in the real world.

• Units – Units are primarily used within the construction industry as a method of measure; distance, volume, quantity, currency and performance.

• Construction Tolerances – A graphical model can be produced to an infinite accuracy, whilst its corresponding physical asset simply cannot. When expressing dimensional accuracy, it is important to understand the construction tolerances that the physical asset can achieve.

The key driver behind implementing project CDE is to ensure clarity in terms of information purpose, suitability security and currency.

It allows project teams to develop and progressively share their information for better coordination and ultimately more timely and efficient information delivery.

Work in Progress

•Visible to all members of the Task Team (with appropriate permissions)
•Can be edited and the information within them created or amended by the Task Team
•Should be considered as “UNAPPROVED” and therefore not used for any purpose

Prior to sharing the Task Team must:

•Check container (against the Project Information Standard)
•Review information within the container (technical content)
•Approve information within the container is to be shared.
•Designate what the information is suitable for.

Shared

•Visible to all members of the Delivery Team (with appropriate permissions)
•Cannot be edited and can only be viewed as READ ONLY
•Can only be used for the suitability for which the information within it has been approved
•Are the most current approved revision on the container

Published

•Visible to all Project/Asset Team members (with appropriate permissions)
•Cannot be edited and can only be viewed as READ ONLY
•Are the most current authorized revision of the container

Archived

• Visible only to CDE administrators (with appropriate permissions)
• Cannot be edited and can only be viewed as READ ONLY
• Should be considered as ‘out of date’ as they have been superseded

Tasks for the Lead Appointed Party:

• Review information within the container
• Authorize information within the container for the Appointing Party acceptance

Task for the Appointing Party:

• Review information within the container
• Accept information within the container as contractual deliverable
• Identify the container as an accepted contractual deliverable