ISO19650 process covers all party’s roles and responsibilities. For this training, we are focused on what their duties are as ‘Appointing Party’.
The appointing party is responsible for identifying and engaging one or more individuals (from within their organization or from a third party) to undertake the information management function in respect of the project. The scope of the information management function to be undertaken by the individual(s) is also determined by the appointing party. Collectively this scope covers all of the appointing party’s activities as described in ISO 19650-2. It is important that whoever undertakes the information management function has the appropriate knowledge and skills required. A lead appointed party could in theory, carry out some or all of the information management function. It is suggested that an individual (or individuals) carrying out the information management function on behalf of the appointing party should not be carrying out the lead appointed party’s own information management function.
Firstly – to make sure that your information management function is fulfilled by people within your organization or people acting on your behalf or a combination of both. Then wherever the ISO 19650 series refers to the “appointing party” this means the organization(s) fulfilling the client’s information management function.
The ISO 19650 series refers to the lead appointed party in two ways: 1. The prospective lead appointed party i.e. a party tendering for the role of lead appointed party; or 2. Lead appointed party i.e. a party who is confirmed in that role.
In ISO 19650-2, most of the requirements below the level of lead appointed party are directed at a task team. There is a lot of flexibility within ISO 19650 regarding the relationship between appointed parties and task teams – in some cases, each task team might be a separate appointed party, in other cases, an appointed party might include a number of task teams, and in yet more cases a task team might include a number of appointed parties.
Project information requirements (PIR) are defined by the appointing party. They identify the information needed to satisfy strategic objectives at key decision points during a design and construction project. They inform the exchange information requirements (EIR), which are appointment, not project-based. It is important that PIR are appropriately defined since they are fundamental to the robustness of the EIR and the delivery of the information needed. Note that the PIR are not expressed in tender or appointment content.
During the project the appointing party needs to understand: a. The purposes for which information is required. For example to support the organization or the asset to function or to enable the design and construction project to progress to the next stage. b. The information which will be required for those purposes. The way that the information is identified might depend on the knowledge of the appointing party and the nature of the decisions that are to be made. The appointing party may know precisely what information is required but equally, they might not.
For example, if a key decision to progress to the next stage is related to whether construction can be completed by a specific date, the PIR might identify that construction programme information is required for board review. Alternatively, if the decision to progress to the next stage is related to a broader area, say: the safe construction and operation of the asset, then the PIR might identify that information is needed to demonstrate that the design is safe to construct and operate.
Clause 5.1.2 lists seven points of consideration for establishing project information requirements: 1. The project scope. Basic information about the project. 2. The intended purpose for which the information will be used by the appointing party The reasons why information is required by the appointing party during the project. A list of possible purposes is set out in ISO 19650-1 clause 5.1. 3. The project plan of work How the project will be broken down into stages or intervals. 4. The intended procurement route How appointments/contracts will be structured, the relationships between parties and the rules that govern a project. 5. The number of key decision points throughout the project The points during a project where the appointing party requires information to make informed decisions. 6. The decisions that the appointing party needs to make at each key decision point Decisions that an appointing party may be required to make during a project to achieve the desired outcomes, ensure project progression and/or to feedback into wider organization strategies. 7. The questions to which the appointing party needs answers, to make informed decisions These questions provide a check to ensure that decisions can be made using the information provided. If the appointing party concludes that some of these points are not relevant or do not aid beneficial communication of the PIR then there is no requirement to do anything beyond ‘consider’ and document that no further action is needed.
Information delivery milestones are defined to determine when information models will be exchanged from the delivery team to the appointing party and/or between delivery teams. Clause 5.1.3 identifies four key considerations for determining information delivery milestones. 1. The appointing party’s key decision points 2. It’s own information delivery obligations (if any) 3. The nature and substance of information to be delivered at each key decision point 4. The date(s) relative to each key decision point that the information model is to be delivered They require the appointing party to think about the information needed for their own purposes plus information delivery obligations they might have themselves. The latter is particularly relevant where a programme of works is being delivered, where a project might consist of separate enabling works and construction contracts or where a traditional procurement approach is adopted.
Information delivery milestones should be programmed such that they support key decision points and project progression. However, given the point at which milestones are determined they are unlikely to be date specific. It may be appropriate to position the milestones within or at the end of project stages.
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 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.
The benefits of a well-defined project information standard is 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 used 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
When establishing the information standard, the appointing party considers: Exchange of Information: What standardized elements for exchanging information have been established for the project. For example, the information standard may establish project-specific codes to support the national annex information container naming convention and the permitted values for metadata fields. It may also specify the naming and numbering systems for elements such as: Components, Types, Systems, Storeys, and Spaces.
It may also specify the naming and numbering systems for elements such as: Components, Types, Systems, Storeys, and Spaces.
Structuring and classification of Information: What work breakdown structures and classification system(s) have been established for the project. For example, the information standard may establish a work breakdown structure based on a classification system (such as Uniclass 2015), a schedule of packages, or other criteria.
Method of specifying level of information need: What method of describing the level of information need has been established for the project. For example, the information standard may establish that the NBS level of definition convention shall be used. In which case it will likely either cross-reference to an external source or include the textual description and an associated code for each level of detail and level of information.
It should be noted that as the information standard is project-specific, some of the established information standards may not be applicable depending on the nature of the appointment. For example, additional handover information may be included within the information standard which are not relevant for an appointment to produce a concept design.
When establishing the information production methods and procedures, the appointing party considers: Capture of existing asset information: How existing information will be captured? For example, the information production methods and procedures may establish what properties need to be captured about existing asset information, the permitted values, or measurement units. It may also specify which information container(s) this information is captured within.
Generation, review or approval of new information: How information is produced, reviewed or approved. For example, the information production methods and procedures may establish that information should be produced within a specified software application. It may also specify how to review information by providing a procedure or a specific workflow to be followed.
Security or distribution of information: How to implement specific security requirements or how to share information. For example, the information production methods and procedures may establish that additional meta-data relating to a security rating should be applied to all information containers. It may also specify the common data environment (CDE) solution to be used for the distribution of information.
Delivery of information to the appointing party: How information is provided to the appointing party. For example, the information production methods and procedures may establish what procedure to follow when delivering information such as whether additional checks are required or if an additional CDE solution is to be used.
It should be noted that as the information production methods and procedures are project-specific, some of the established production methods and procedures may not all apply to all appointed parties. Remember that the information production methods and procedures are set out at project rather than appointment level. Its amalgamation with the standard may prove beneficial as both are project-specific and often used in tandem (unlike the exchange information requirements, which is an appointment specific resource).
The appointing party considers existing reference information and shared resources to support tender of all appointed parties.
Reference information could be relevant to the overall project, such as Ordnance Survey mapping or information relating to adjacent assets and/or utilities owned by other organizations. Reference information could also be selected information from the existing asset information model, such as low-temperature hot water and chilled water schematics.
In addition, reference information may include the information delivered during a preceding appointment, usually by a different delivery team. For example, performance specifications are prepared by the appointing party’s design team for tendering a design and build contract. It is possible for a prospective lead appointed party to receive reference information that it produced itself in a previous appointment, for example, a masterplan produced by Ryder Architecture would be reference information for the subsequent design development package that the same practice is bidding for along with a number of other practices.
Shared resources can take many forms, such as document templates, 3D object libraries or custom line styles and clause 5.1.6 provides examples. 1. Process output templates (BEP, MIDP) 2. Information container templates (2D/3D geometrical models, documents) 3. Style libraries (line, text and hatch, etc) 4. Object libraries (2D symbols, 3D objects etc) To provide a practical illustration the client might provide a template for the BIM execution plan, to be used by all prospective lead appointed parties, to make sure that this part of each tender submission is structured in the same way and can be consistently evaluated.
Finally, an important consideration for both reference information and shared information is the use of open data standards.
Before any information can be exchanged between the appointing party and their delivery team(s), a set of workflows and exchange solutions must be agreed and implemented that form the common data environment (CDE). A workflow may for example, include the approval process and timescales, a solution may be a file management system.
Email example.
It is important to establish what is meant by metadata as the ISO 19650 series offers no formal definition. Metadata is defined as “A set of data that describes and gives information about other data” (Oxford Dictionary, 2019). To put this into context, the information container unique ID (see ISO 19650-2 National Annex), can be thought of as metadata because it “describes and gives information about other data”. However, ISO 19650-2 requires additional metadata to be assigned but it should not be part of the unique ID. The ISO 19650 series makes it clear that authors keep strict control of their information throughout its development. It is recommended that this is achieved by the author using metadata assignment. This communicates what version the information container is at and the purpose for which it can be used.
ISO 19650-1 clause 12.1 recommends the following metadata assignment to information containers within a CDE: • A revision code (in accordance with an agreed standard) • A status code (Showing permitted use(s) of information) ISO 19650-2 clause 5.1.7 then requires that the CDE enables assignment of these codes plus the assignment of: • A classification code The scope of the metadata assignment may expand beyond the recommendations and requirements of the ISO 19650 series, for example, to include asset-focused information.
The appointing party is accountable for ensuring this CDE is implemented, configured and supported throughout the project. They may delegate this to a third party but it should be in place to enable tender information to be shared (and therefore before issuing tender information to any prospective lead appointed party). It is therefore not practical to delegate this activity to a prospective lead appointed party at this stage.
It is however, acceptable to transition hosting, managing and supporting of the CDE to a lead appointed party after the appointment but “transitioning” is the operative word as it must be functional before transitioning.
How will our supplier name information? How will suppliers share and exchange information? How will the appointing party review the exchange information?
The document naming standards will appear on all models, 2D outputs, drawings, specifications, schedules and other documents related to the project. The project common data environment (CDE) will enable each information container (file name) additional attributes [metadata] assigned: • Status (suitability); • Revision • Classification etc.
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.
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 breakdown 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.
When implementing the CDE, it must enable: • Each information container to have a unique ID, based upon an agreed and documented convention comprised of fields separated by a delimiter. For example: ensuring the chosen CDE solution is configured in line with the UK National Annex clauses NA.2 and NA.3 contained in ISO 19650-2.
• Each field to be assigned a value from an agreed and documented codification standard For example: the CDE solution helps users find information quickly like model files by searching for the Type M3 or CR (refer to National Annex clause NA.3.6 contained in ISO 19650-2) D drawing Information in the form of a graphical depiction of shape, size, etc., of a physical part or assembly, usually to scale G diagram Information in the form of a graphical/symbolic depiction showing the functions of the objects composing a system and their interrelationships using graphical elements and symbols, or the behaviour of variables using graphs I image Information in the form of a static image or picture and not defining any relationships between objects L list Information in the form of columns and rows, such as tables, spreadsheets and datasets M model Two- or three-dimensional physical or digital description of the ideal shape of object(s) and/or space(s) T textual Information in the form of characters and paragraphs – for example in written instructions and descriptions V video/audio Information in the form of moving images, animation or sound • Each information container to have the following attributes assigned; 1)status 2) Revision 3) Classification Note: the CDE solution allows additional data to be tagged to information containers beyond the information container unique ID to assist the project team in their understanding of what is the latest information and how it can be used.
• The ability for information containers to transition between states and the recording of the name of user and date when information container revisions transition between each state Note: the CDE workflow can keep a detailed audit trail of each information container’s content, status and revision activity. This can also provide clarity about what and when sign off is required before a transition can take place.
• Controlled access at an information container level For example: the CDE solution and workflow can allow configuration that restricts access to information containers that have not reached a sufficient level of maturity or are too sensitive for specific organizations or individuals to have access to them
Each appointment must contain an information protocol, i.e. all lead appointed party’s appointments and all appointed parties’ appointments. The lead appointed party’s appointment will contain the project’s information protocol, and this will be included in the appointed party’s appointment documents with any appropriate differences to reflect each appointment.