Lesson 1, Topic 1
In Progress

Parties and Responsibilities

ISO 19650-3 uses the same principle parties and their relational interfaces in the operational phase as prior phases.

Whilst organizations and individuals fulfilling these principal party positions may change between phases, the information management function, standard, and processes remain constant, supporting the migration and evolution of the information model across the asset’s lifecycle.

The (asset-related) appointing party is the organization requiring and receiving the asset information. They can be the property/ asset owner, an estates department, an internal asset management team, or an outsourced operator/asset manager (usually on a medium-to-long-term contract from the legal asset owner). They have authority and responsibility for the long-term operations and management of the asset or asset portfolio, and they ensure the required asset information is correctly specified, received, and maintained to support the whole asset lifecycle. The appointing party prepares a set of information management resources to define the quality of information and the processes and protocols governing its production and ownership.

A lead appointed party is directly appointed by the appointing party to manage the delivery of a specific set of asset-related information. The same organization or team will almost certainly also be delivering the technical services, or functions that generate the required information (as an appointed party – we’ll come onto next) or outcome which includes the delivery of (asset-related) information requirements. For example, a lead appointed party can be an in-house maintenance team carrying out periodical statutory or routine maintenance checks, or an external contractor appointed to replace a faulty plant item or install a new lift or fire alarm system.

In the case of a small in-house maintenance job, this might involve just one maintenance engineer as the lead appointed party answering to an individual asset manager as appointing party. The overall process is the same but clearly, it is applied in a proportionate way.

An appointed party is appointed by the lead appointed party to generate and deliver a specific set of asset-related information. This information relates to the appointed party’s particular technical sub-services, subfunctions or works which includes the delivery of (asset-related) information requirements.

The distinction between a lead appointed party and an appointed party is that a lead appointed party is only concerned with managing the information process in their team whereas the appointed parties carry out the technical work and generate the associated information. An appointed party’s outputs feed into or form part of their lead appointed party’s overall deliverables to the appointing party (asset owner/ operator).
The appointing party is the Asset Owner/User or the party managing information on behalf of the Asset Owner/User.

A lead appointed party is a party appointed by the Asset Owner/User.

An appointed party is a party appointed by the lead appointed party. The appointed party is the party that provides the information.
The appointing party (the Asset Owner/User) is likely to have several appointments with lead appointed parties (for example, for Facilities Management, Asset Management, Surveyor), and a lead appointed party is likely to have several appointments with appointed parties (especially where they are an Asset Manager) – remember that an appointed party is a party that provides the information.
A lead appointed party and their appointed party/parties make up a delivery team.

Where there is a lead appointed party there will be a delivery team (even if the delivery team only consists of one lead appointed party organization). Most assets will therefore comprise multiple delivery teams, regardless of the structure of the overall project (facilities management, asset management and so on).

The project team comprises the appointing party (the asset owner/user) plus all delivery teams.

It is therefore essential that information is coordinated across delivery teams as well as within delivery teams.
Notice the change in names for the last two stages.
Many of the responsibilities identified in ISO 19650-2 are relevant to and repeated within ISO19650-3, showing very clearly that operations input is required right from the very start of the project and during delivery. However, there are a few principle differences or key requirements that we’ll go through next.
Organisational information requirements are identified in ISO 19650 as a key part of the process and critical to feeding into the following requirements. ISO 19650-3 highlights this step as a key function for the operational process, requiring the appointed party to lead the process and needing to be undertaken right at the start of the project before tendering the first lead appointed party’s appointment.

The organisational information requirements are used to capture high-level information needed to support strategic objectives and may come from a range of internal departments or key external stakeholders.
Example 1:

The marketing department of a hotel chain could require information about the condition of public spaces (such as reception areas, restaurants, bars) across all hotels in the chain.
Example 2:

A bank lending money to the hotel chain could require information (OIR) about the average annual occupancy of the hotel rooms and the function suites across all hotels in the chain.
Where the appointing party is managing a portfolio of assets, then OIR can be across the whole portfolio, or related to a group of similar assets (for example pumping stations for a water utility). They can also relate to a single asset, but must still be linked to strategic objectives within the organization.
Another critical step at the very start of a project, prior to appointments being issued, and again a key responsibility of the Appointing Party to carry out is the development of Asset Information Requirements.

They set out the asset-specific information needed for the assets identified in the previous step. Information need might be driven by departments or teams within the organization or external bodies, such as to support maintenance tasks.

It could also be prescribed through legislation, such as to support Health and Safety or environmental protection.

•AIR’s will be developed with the OIR’s in mind, therefore being a subsequent step but they’ll typically be at an individual asset level or category of asset level.
A hotel group operating brands at different price points/quality levels could have separate AIR related to the condition of public spaces for each brand in the overall portfolio. This could be extended to the individual hotels within each brand. The AIR would be tailored to the facilities and public areas provided at each hotel or across each brand.
A water and sewerage utility would have separate AIR for its different asset classes (pumping stations, treatment works, pipeline networks, reservoirs, administrative offices, etc).
Once the AIR has been established the next activity is to consider foreseeable trigger events.

A trigger event is one that occurs to an asset or affects it in some way. It triggers the requirement for new or updated information relating to the asset, in line with its AIR. A foreseeable trigger event is one that can be planned in advance (and which it is sensible to plan for, based on its likelihood of occurring and impact on the organization).

It is sensible to consider separate trigger events as they are likely to instigate an appointment.
A trigger event might be a series of separate actions, such as regular maintenance of a component during its lifetime, or it could represent a one-off action such as an initial condition survey after acquiring an asset from its former owner.
Yearly lift inspections and maintenance. This could be across a whole building/asset or could be for a sub-set of all lifts (such as passenger lifts) if other lifts are inspected at different frequencies.
In a flood response survey for a retail chain, this trigger event would only apply to the stores (assets) that are in a known flood-risk area. The timing of any particular flood cannot be known, but the asset owner has judged that it is sufficiently likely that the planning and onboarding of an appropriate survey team are worthwhile, given the rapid turnaround that would be needed in the event of an actual flood occurring.
It is likely that existing enterprise information systems will be used to store some of the information being collected in response to the information requirements. It may even be possible to store all the information in existing systems rather than creating new information systems from scratch to do this.

Where there are existing systems, they need to be checked to make sure that they can support the requirements of ISO 19650-3.

It is important that this is done so that the integrity of the whole asset information model (AIM), which is stored across these enterprise systems, can be guaranteed, providing a single source of truth.

For example, a Computer Aided Facilities Management system may be used to support work order ticketing, and documentation may be stored on an Electronic document management system. Both of these systems will require information to be provided from the ISO 19650 process, and they may both need to be used together to support work order requests, perhaps to fix a ventilation system or flood prevention pump; with a frontline user searching for related assets on the CAFM system, and browsing related documents on the EDMS
The asset information model (AIM) is the information generated via the information management process that provides a long-term benefits to the appointing party (asset owner or operator).

The AIM may need to be established from scratch or may incorporate some existing information systems. Clause 5.1.11 requires that the appointing party makes sure that any existing AIM can accommodate new information models generated through the ISO 19650-3 process. The appointing party should also consider if the existing AIM requires adaption where it is to be the source of reference information for the work being done by the appointed parties. Again this needs to be done prior to appointments being issued for the first lead appointed party.

The workflows for getting new or updated information into the AIM are governed by the CDE workflow and the details in ISO 19650-3 clauses 5.6 and 5.7. Any specific requirements around the structure or procedures associated with the AIM should be explained to the lead appointed parties and their delivery teams through the asset information standard and the asset information production methods and procedures.
A water authority might require instantaneous recording of movement gauges on a reservoir dam in order to have the earliest possible warning of potential failure. They might also require monthly AIM updates in relation to the condition of the buildings on a treatment works site.

ISO 19650-3 includes a list of 10 mandatory areas that the AIM maintenance processes have to cover. These include making sure the AIM continues to satisfy security requirements, and that AIM ownership and maintenance responsibility are transferred when there is a change of ownership of the corresponding asset.
During mobilisation, it’s key that the Appointing Party ensures that the Lead Appointed Party is on standby to respond to trigger events and, and continually reviewing whether the delivery team personnel, technology and other resources are still suitable for addressing the EIR, and maintaining an up to date BIM Execution Plan for the project.

The surveyor responsible for condition surveying a hospital wing retires, the Lead Appointed Party is expected to replace the resource and ensure they are suitably capable of capturing and incorporating survey information in compliance with the EIR, and the Hospital Estates Department benefits from ensuring this capability assessment is carried out prior to the new resource accessing their information.

Once the Appointed Party has accepted the information provided by the delivery team the process of incorporating the delivered information into the AIR begins.

Aggregating the information model involves the asset owner/operator (appointing party) incorporating the information containers into the AIM. This may require adding the information containers into the appropriate enterprise systems or using the information containers to update existing contents in the enterprise systems.

It is helpful if as much of this work can be automated as possible, but there might still be manual tasks to be completed. ISO 19650-3 presumes that these activities are carried out correctly and the necessary checks are in place to ensure this. It does not specify what processes and checks have to be applied.
For example:

An infrastructure owner may incorporate GIS layers into their own GIS database, and transfer the maintainable assets and associated planned maintenance regime into their Computer Aided Facilities Management system.
It is the opportunity for the appointing party to ask themselves whether the AIM is still fulfilling its purpose(s) and is being maintained in accordance with the agreed procedures. If either of these is not the case, then mitigation measures need to be put in place. It is a healthy part of any organisation’s self-reflection and continuous improvement processes

For example:

This could trigger a reassessment of the asset information requirements (AIR). If new AIR is now identified then this could lead to changes in the EIR (ISO 19650-3) that have been used to appoint existing lead appointed parties. These changes would have knock-on effects on the structure of the AIM

Or

This could trigger an assessment of the maintenance processes, and it might be concluded that the alignment frequency of the AIM to the state of the asset is either too high (more expensive than necessary) or too low (leading to the use of outdated information).

This could be particularly helpful prior to or during acquisition, as it provides an opportunity to plan how deficiencies are to be made good.