0% found this document useful (0 votes)
49 views31 pages

V.2.0 CFIHOS Implementation Guide For Principal

The CFIHOS Implementation Guide outlines the Capital Facilities Information Handover Specification, aimed at standardizing information exchange in the process and energy sectors. It details the procedures for implementing the CFIHOS standard from a Principal's perspective, emphasizing the importance of structured data and document handover during project transitions. The guide also highlights the collaborative development of CFIHOS, supported by over 70 organizations, to enhance efficiency and reduce costs in information management across the supply chain.

Uploaded by

zwff8449z5
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
49 views31 pages

V.2.0 CFIHOS Implementation Guide For Principal

The CFIHOS Implementation Guide outlines the Capital Facilities Information Handover Specification, aimed at standardizing information exchange in the process and energy sectors. It details the procedures for implementing the CFIHOS standard from a Principal's perspective, emphasizing the importance of structured data and document handover during project transitions. The guide also highlights the collaborative development of CFIHOS, supported by over 70 organizations, to enhance efficiency and reduce costs in information management across the supply chain.

Uploaded by

zwff8449z5
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 31

CFIHOS October

C-GD-001 2024

CFIHOS - Implementation Guide for Principal


CFIHOS – Implementation Guide for Principal

Acknowledgements

In 2012, Shell approached Netherlands-based process industry organization USPI to


explore turning their corporate information standard into an industry-wide standard. The
result was the CFIHOS (Capital Facilities Information Handover Specification) project.

Its aim is to offer practical, standardized specifications for information handover that work
across the supply chain – operators, contractors and suppliers. The most recent CFIHOS
industry standard (Version 1.4) was published in October 2019 by USPI with support from
the Engineering Advancement Association of Japan (ENAA). This document, describing the
scope and procedures of CFIHOS, is part of this standard.

Following a member vote in 2019, the future governance, development, and maintenance
of the CFIHOS project and standard moved from USPI to IOGP in January 2020, becoming
Joint Industry Project (JIP)36.

Disclaimer
Whilst every effort has been made to ensure the accuracy of the information
contained in this publication, neither IOGP nor any of its Members past present or
future warrants its accuracy or will, regardless of its or their negligence, assume
liability for any foreseeable or unforeseeable use made thereof, which liability is
hereby excluded. Consequently, such use is at the recipient’s own risk on the basis
that any use by the recipient constitutes agreement to the terms of this disclaimer.
The recipient is obliged to inform any subsequent recipient of such terms.

This publication is made available for information purposes and solely for the private
use of the user. IOGP will not directly or indirectly endorse, approve or accredit the
content of any course, event or otherwise where this publication will be reproduced.

Copyright notice
The contents of these pages are © International Association of Oil & Gas Producers.
Permission is given to reproduce this report in whole or in part provided (i)
that the copyright of IOGP and (ii) the sources are acknowledged. All other rights are
reserved. Any other use requires the prior written permission of IOGP.

Page 2 of 31
CFIHOS – Implementation Guide for Principal

These Terms and Conditions shall be governed by and construed in accordance


with the laws of England and Wales. Disputes arising here from shall be exclusively
subject to the jurisdiction of the courts of England and Wales.

Page 3 of 31
CFIHOS – Implementation Guide for Principal

CFIHOS – Implementation Guide for Principal

Version Date Comments/History

1.4 April 2020 IOGP republication of CFIHOS document first


published in October 2019.

1.4.1 December 2020 Minor text changes to Section 3 ‘How to use the
CFIHOS Standard on a Project’ - following bug fixes
to the CFIHOS Standard to ensure continued
alignment.
1.5 October 2021 Minor change correcting spelling error in Figure B-1

1.5.1 2022-11 Minor text changes for bug fixes throughout the text
of the document
2.0 2024-10-31 Version 2.0, no change

Page 4 of 31
CFIHOS – Implementation Guide for Principal

Foreword

The Capital Facilities Information Handover Specification (CFIHOS) is an industry standard developed
to improve how information is exchanged between the companies who own, operate, and construct
equipment for the process and energy sectors. Starting with a common equipment naming
taxonomy and supporting specifications, its goal is to become a common language for the exchange
of information in these sectors.

The initial focus is on information, both structured data and traditional document formats, which
must be handed over when a project moves from its development to operations phase. Ultimately,
the aim is for CFIHOS to become the de-facto standard for information exchange throughout the
physical asset lifecycle, from vendor information through to decommissioning.

The Reference Data Library or “RDL” lies at CFIHOS’ heart. This library gives a standard and unified
naming convention for equipment, its attributes, disciplines, and documents. The CFIHOS RDL
includes:

 A list of classes for Tag and Equipment (what the equipment does and what it is)
 A list of properties (attributes, measures, characteristics etc.)
 Lists of requirements by class (data and document requirements)
 Standard unique coding of data to facilitate digital design and other workflows
 A list of document types
 A list of disciplines.

At present, CFIHOS covers only the exchange of structured data and documents - not graphical,
geometry, and model data. In the future, CFIHOS could be extended to include graphical and design
tool and support spare parts procurement, inspection, test requirements, commissioning check
sheets, Work Packaging, configuration management, and even drive payment.

CFIHOS is being developed collaboratively by project members as a practical standard to ensure the
systematic and reliable exchange of information between all participants involved in the information
supply chain, thereby reducing cycle times and costs. More than 70 organizations contributed to the
development of CFIHOS Standard, which is supported by several leading software industry design
tools.

Page 5 of 31
CFIHOS – Implementation Guide for Principal

Contents

Foreword............................................................................................................................ 5
1 Introduction................................................................................................................ 7
1.1 General............................................................................................................ 7
1.2 Scope............................................................................................................... 7
1.3 Target Audience............................................................................................... 7
1.4 CFIHOS Document Structure............................................................................7
1.5 Terms, Definitions, Acronyms and Abbreviations.............................................9
1.6 Information Management Principles and Processes in Projects........................9
2 Contract Information Requirements..........................................................................10
2.1 Contractual Information Requirements Overview...........................................10
2.2 Contract Information Management Scope of Work.........................................11
2.3 Contract Information Specification.................................................................11
3 How to use the CFIHOS Standard on a Project..........................................................12
3.1 Specify Information Requirements.................................................................13
3.1.1 Select CFIHOS Contract Scenario Template...................................................14
3.1.2 Identify Additional Project Specific Requirements..........................................14
3.1.3 Adjust CFIHOS Template for Local Needs.......................................................15
3.1.4 Generate Reference Data...............................................................................15
3.1.5 Add Reference Data to Specification..............................................................16
3.1.6 Finalize Contract Information Requirements..................................................16
3.1.7 Incorporate in Tender Documents..................................................................17
3.1.8 Adjustments Due to Bidder Clarification.........................................................17
3.1.9 Finalize Information Specification at Contract Award.....................................17
3.2 Generate Information Deliverable..................................................................17
3.2.1 Contractor Actions......................................................................................... 18
3.2.2 Principal Reviews and Validates Information Delivered..................................18
3.2.3 Principal Returns Comments..........................................................................19
3.2.4 Contractor Incorporates Comments...............................................................19
3.3 Handover of Information................................................................................19
4 Where to retrieve CFIHOS Documents, Tools and Templates....................................20
Annex A: Data, Information, and Documents...................................................................21
Annex B: Contract Scenario Templates............................................................................22
Annex C: Contract Information Requirements Package – Overview.................................30

Table of Figures
Figure 1 CFIHOS Document Structure................................................................................7
Figure 2 How to use CFIHOS on a Project - Overview.......................................................11
Figure 3 Process for creating a Contract Information Specification based on CFIHOS......12
Figure 4 Overview of the CFIHOS templates....................................................................13
Figure 5 Process for Generating Information Deliverable based on CFIHOS.....................17

Page 6 of 31
CFIHOS – Implementation Guide for Principal

1 Introduction

1.1 General
This document describes how to implement the Capital Facilities Information Handover Specification
(CFIHOS) from a Principal’s (Owner/Operator’s) perspective. This guide does not discuss the
expected organizational Information Management (IM) maturity required for effective
implementation of the Specification.

1.2 Scope
This document describes how to implement the CFIHOS standard:
 Use of the specification in contracts for projects and assets
 How to create a specification for the handover of engineering information between
Contractor and Principal that is tailored to the scope of the project or asset
 How to use and adopt the CFIHOS Reference Data Library (RDL)
 How to exchange information.

When using this document, it is recommended that the following should be referenced and
understood together:
 CFIHOS Specification Document [C-SP-001]
 CFIHOS Implementation Guide for Contractor [C-GD-002]
 CFIHOS Reference Data Library [C-ST-001]
 CFIHOS Data Model [C-DM-001]
 CFIHOS Scope and Procedure [C-TP-001]
 CFIHOS Contract Scenario Templates.

For further instructional material on how to read the CFIHOS Data Model, refer to the Data
modelling Training Material [C-DM-901] on the CFIHOS SharePoint site.

1.3 Target Audience


This document should be read by:
 Project Managers who are typically accountable for the delivery of project information to
the asset
 Engineering or Operations Managers who typically own the information to be specified and
handed over
 Project Information Managers and consultants who are typically responsible for specifying
the information and implementing the handover process between the various
stakeholders, based on the CFIHOS Specification and Reference Data Library
 Personnel who configure IT systems needed to produce, validate or store the data and
documents to be handed over.

1.4 CFIHOS Document Structure


The documents which form part of and support the CFIHOS standard are organized as shown in
Figure 1. This guide, Implementation Guide for Principal, is indicated in the red circle.

Page 7 of 31
CFIHOS – Implementation Guide for Principal

Figure 1 CFIHOS Document Structure

It is recognized that Principals may have different ways of organizing their contract documents for
Capital Projects. For example, some Principals might include detailed descriptions of requirements
within a Scope of Work, whereas others’ Scopes of Work might be a high-level description, with
detailed requirements described in separate Specifications and Administration or Coordination
Procedures.

Another difference is that some Principals collect all of their Information Requirements into a single
Information Management Scope of Work, whereas others define Information Requirements
alongside requirements for different parts of the Scope of Work.

However the Principal chooses to organize its Information Requirements, the following must be
included in order to benefit from the CFIHOS standard:

1. “What” information is to be provided.


2. “How” the information is to be provided, including the format (document or data, file
type) and how it is to be identified (document type, metadata, data identifier [CFIHOS
Unique ID]).
3. “When” the information is to be provided. This is outside the scope of the CFIHOS
Specification [C-SP-001], however, the CFIHOS Scope and Procedure [C-TP-001] provides
some basic information on this topic.
4. The quality measures that are used to understand the completeness, timeliness, and
accuracy of the information. This is not currently addressed by the CFIHOS standard,
however, the CFIHOS Scope and Procedure [C-TP-001] provides some basic information on
this topic.

Page 8 of 31
CFIHOS – Implementation Guide for Principal

1.5 Terms, Definitions, Acronyms and Abbreviations


A complete definition of terms is available in the CFIHOS Specification Document [C-SP-001]. A few
key terms used in this document are included below.

This symbol identifies important points to consider for the specific section where it is located.

Contract Information Management Scope of Work (IM SoW): In this contractual document the
Principal specifies the terms and conditions for information delivery by the Contractor. Where it is
applicable and feasible, quality benchmarks and criteria on how the Contractor is to fulfil these
requirements may be included. For any details there could be either referred to specific specification
documents or included in the scope of work. The term Project Information Management Scope of
Work can also be used.
CFIHOS Scope and Procedure document [C-TP-001] is used as a reference to create the project or
contract specific Information Management Scope of Work.

Contract Information Specification (CIS): The resulting document when this CFIHOS industry
guideline is applied to a particular project describing the specific set of requirements to be fulfilled.
Linked to this document is a Reference Data Library that describes the data characteristics and
document types.
The CFIHOS Specification Document is the basis for creating a project or contract specific
Information Specification.

Discipline Document Type: An association between Disciplines and Document Class names. In the
CFIHOS context, the term Discipline Document Type is a unique identifier for types of documents,
which allows deliverables to be specified and content owners to be assigned by discipline. This term
has been developed to cater for situations where a document class is common to more than one
discipline. For example, a Data Sheet can be produced by different disciplines depending on the
nature of the associated equipment.

Contractor (EPC Contractor): This is the party that carries out all or part of the design, engineering,
procurement, construction, commissioning or management of a project or operation of a facility.
The Principal may undertake all or part of the duties of the Contractor.

Principal (or Owner / Operator): This is the party that initiates the project and ultimately pays for it.
The Principal may also include an agent or consultant authorised to act for, and on behalf of, the
Principal.

Prime Contract: This is the main contract for the project/scope of work between the Principal and
the Contractor. There might be additional sub-contracts related to the project/scope of work, which
must refer to the main contract and its terms and conditions - for example, contracts between
contractor and sub-contractors.

Reference Data Library (RDL): Reference Data Library of the metadata of Data and Documents
described in CFIHOS Specification Document [C-SP-001]

Shall is used to dictate absolute requirements.

Should is used to describe recommendations where noncompliance can be acceptable.

1.6 Information Management Principles and Processes in Projects


Important Information Management aspects to consider for large engineering projects:
 A Capital Project typically delivers two assets to the Principal organization; a physical asset

Page 9 of 31
CFIHOS – Implementation Guide for Principal

and an information asset


 Principals are responsible for the specification of the requirements for both the physical
asset and the information asset
 The Project Prime Contract contains requirements and terms and conditions for both the
physical asset (“Technical Requirements”) and the information asset (“Information
Requirements”)
 Contractors, Suppliers/Manufacturers (Vendors) and other third parties are responsible for
creating and delivering a high-quality information asset to the Principal, which in turn can
be used for Operations and Maintenance
 The information asset will include both Documents (printed or electronic, for human
interpretation) as well as Data (stored in a structured format and manipulated using
software applications). Annex A further describes Information, Data, and Documents.

From a Principal perspective, the information management process involves three steps:
1. Specify the Information Requirements to support both project execution and
operations/maintenance activities. CFIHOS seeks to establish a consistent industry standard
for such Information Requirements, to make the process of specifying easier and to reduce
the cost of the information asset. The overall Information Requirements are contained in the
Prime Contract.
2. Control the content to validate that the information generated by Contractors,
Suppliers/Manufacturers (Vendors) and others is compliant with the Information
Requirements; to track quality, progress and completeness against the Contract Information
Specification (CIS). Controls should ideally be executed as closely as possible to the source of
information to reduce the time and cost of correcting any issues.
3. Capture, Handover, Use & Share the information asset to optimize its value, e.g. from
Suppliers/Manufacturers (Vendors) to Contractors to Principal Project and Asset Operations
teams.

The focus of this guidance is on step 1, i.e. how to use the CFIHOS standard to select and specify
Principal’s Information Requirements to Contractors and other parties contracted by the Principal.

2 Contract Information Requirements

2.1 Contractual Information Requirements Overview


A Principal typically has a contracting and procurement process by which a Prime Contract or
another contractual vehicle will be agreed with a Contractor to deliver a project scope. The
Principal’s Information Requirements need to be included in this Prime Contract or another
contractual vehicle, as appropriate.

The objective of the Principal typically is to ensure that the Contractor delivers the minimum set of
information required to effectively execute the project and manage its projects and assets. To this
end, the Information Requirements need to be articulated and embedded in the Prime Contract.

These Information Requirements normally consist of the following elements to be created by the
Principal (based on the CFIHOS Standard) and contractually mandated to the Contractor via the
Prime Contract:

1. Contract Information Management Scope of Work (IM SoW), including


 High-level description of the information (data and documents) that should be
delivered, “When”
 A framework of rules and principles covering the “How” of information exchange

Page 10 of 31
CFIHOS – Implementation Guide for Principal

and management.

2. Contract Information Specification (CIS) providing detailed requirements of “What”


information should be delivered and in which format the information should be
delivered, including:
 Reference Data (based on CFIHOS RDL)
 Reference Documents (ex: Principal’s Transmittal specification, Tagging convention,
etc. Not in CFIHOS scope).

Depending on the structure of each Principal’s Prime Contract, the contractual requirements
covering information management and handover may not necessarily be centralized into a single
Information Requirements Package and may be found dispersed throughout the Prime Contract.
However, in this guide, the terms “Information Requirements” and “Information Requirements
Package” have been used interchangeably as described above.

In addition to the Information Requirements, the complete Contractual Requirements include the
Technical Requirements, also containing Scope of Work and Specifications. The Information
Requirements will cover the handover of the information asset, while the Technical Requirements
cover the physical asset.

Note: The specification for the internal processes of the Contractor or the Principal is not part of the
scope of CFIHOS and are not covered in this document. The Technical requirements for the physical
asset are not within the scope of CFIHOS and are also not covered in this document.

2.2 Contract Information Management Scope of Work


The Prime Contract’s IM SoW identifies to a Contractor their contractual responsibility to deliver
information to the Principal. The IM SOW should also point to the Contract Information Specification
which should identify what information is to be delivered and the format of that information.

The goal of the Contract IM SoW document is to define the scope, processes, interdependencies and
acceptance criteria for the exchange and handover of information between Contractor and Principal.
It should allow Contractor to understand the expected deliverables, their timing and other success
criteria, and it should enable the Principal to monitor the quality and progress of information
creation and delivery in a progressive manner before the final handover. In summary, the IM SoW
will point to the relevant Contract Information Specification (which identifies what information
needs to be delivered in executing a contract). The IM SoW will then also typically define (See
CFIHOS Scope & Procedure Document [C-TP-001] for details):

 IM Standards
 Information Lifecycle, principles and security
 Manage Information and Data
 Change Management
 Interface Management
 Data Governance
 IT requirements related to IM
 IM organization and roles
 IM processes, activities, phases and milestones.

2.3 Contract Information Specification


The goal of the Contract Information Specification is to define the technical aspects of the
Information Requirements, for which CFIHOS forms the basis as outlined below. CFIHOS identifies a

Page 11 of 31
CFIHOS – Implementation Guide for Principal

full generic “super-set” of information that may be produced in a project. Principals may choose to
augment this “super-set” of requirements with their project specific requirements.

However, Principals are encouraged to challenge and consider the costs vs. benefits of their
additional requirements. In practice, information delivery is phased over time and the information
delivery scope is split into individual packages. To facilitate implementation, CFIHOS therefore
defines five templates that reflect typical contracting scenarios, and which can be tailored to reflect
the scope of information to be delivered by a Contractor. These contract scenario templates are:

1. Engineering Procurement Construction (EPC) or Engineering Services Contractor (ESC) scope.


2. Front End Engineering and Design (FEED) scope.
3. Document Only Scope (incl. Conceptual Engineering, Surveys/Studies, etc.) – for Document-
centric projects.
4. Package Vendor Scope.
5. Standard Equipment Scope.
6. Concept Design.

The Contract Information Specification will:


 Provide the definition of Information objects to be delivered as part of the contract scope.
This will be based on a CFIHOS template (EPC, FEED, etc.) and further tailored for the
project
 Specify the related CFIHOS based Reference Data tailored for the project
 Define the quality validation rules
 Specify the handover format (file formats, database, XML, CSV, # of paper copies)
 Identify supplementary specifications that the Contractor will need to use to complete and
deliver the information scope. (For example, templates and configuration files for
applications and company or international specs that should be used).

3 How to use the CFIHOS Standard on a Project

This chapter describes how the CFIHOS Standard should be applied to a project. As shown in Figure 2
below:

Figure 2 How to use CFIHOS on a Project - Overview

 Section 3.1 explains how to use CFIHOS to Specify Information requirements - from a

Page 12 of 31
CFIHOS – Implementation Guide for Principal

commercial and technical perspective - using the example of a “Contract Information


Requirements Package” (Annex C – Figure C-1)
 Section 3.2 identifies the key actions the Contractor needs to complete to Generate
Information Deliverable based on requirements specified
 Section 3.3 discusses the Handover of Information deliverables in accordance with the
requirements.

3.1 Specify Information Requirements


The Contract Information Requirements are based on a CFIHOS template that is customised to
match the Principal’s Information Requirements and tailored to the scope of the specific contract by
the process outlined in Figure 3. The IM SoW is developed in parallel to the CIS as outlined in the
processes below. Each process in the boxes of Figure 3 is explained in the following sections 3.1.1 to
3.1.9.

Figure 3 Process for creating a Contract Information Specification based on CFIHOS

Working through these steps for the first time will take some time, but the generated templates can
be reused for future projects, and the deliverables may be re-used in the asset that is created by the
project for future Brownfield modifications.

As the information requirement in the Contract Information Specification (CIS) needs


to be available directly after the contract award, it needs to be unambiguous, and the
information structures and naming conventions established for the whole life cycle.
Before the actual contract award, some pre-qualification, request for a quotation or
other similar steps would usually have taken place. This is an opportunity to pre-
engage Contractors on the data and document requirements. This gives the
Contractor early insight into the Principal’s expectations and gives the Contractor an
opportunity to reflect on the availability of any pre-existing CFIHOS application
configurations into contract pricing to capture efficiency savings.

The Information Requirements should include not just information deliverables for
Engineering and Construction, but also any requirements that need to be passed from
prime Contractors to Vendors or Sub-Contractors

Page 13 of 31
CFIHOS – Implementation Guide for Principal

3.1.1 Select CFIHOS Contract Scenario Template


Select the template that is closest to the project envisaged. There are six templates:

Figure 4 Overview of the CFIHOS templates

 Template 1: EPC or ESC


Information specification template containing the Information Requirements to be delivered
for an Engineering, Procurement & Construction (EPC) Contract or Engineering Services
Contract (ESC) contract scope

 Template 2: FEED
Information specification template containing the Information Requirements for a Front-End
Engineering Design (FEED) Contract. In the FEED template, the procurement or delivery of
any hardware, and the associated information is considered to be out of scope

 Template 3: Document Only


Information specification template containing the Information Requirements for a Contract
delivering documents only. This may include scenarios like Conceptual Engineering,
Surveys/Studies and Site Preparation; but could also address projects or assets that are
managed in a mainly document-centric way where delivery of structured data is not
considered required or useful or where the maturity of the IM organization on the part of
the Contractor or Principal does not support data delivery

 Template 4: Package Vendor


Information specification template containing the Information Requirements for engineered
equipment packages (i.e. skids, part of a plant), including how to code, format and exchange
information (for review and handover) between Contractor and Principal

 Template 5: Standard Equipment


Information specification template containing the Information Requirements for standard
(off-the-shelf) equipment purchase orders, including how to code, format and exchange
information (for review and handover) between Contractor and Principal.

 Template 6: Concept Design


Information specification template containing the Information Requirements for a Concept
Design Contract. In the Concept Design template, the procurement or delivery of any
hardware and the associated information is considered to be out of scope.

3.1.2 Identify Additional Project Specific Requirements


To augment CFIHOS template requirements, the following additional requirements need to be
identified:

1. Information requirements not covered by CFIHOS: These may include corporate practices or
scope not currently included in CFIHOS. Examples include:
 Project specific list of document deliverables
 Engineering Discipline or other technical data in any specific application format

Page 14 of 31
CFIHOS – Implementation Guide for Principal

 3D Model data in any specific format with specific reference data / Reference documents
and catalogues.

2. Project Specific reference data/reference documents and specifications: These include


taxonomies, object coding and naming conventions that are specific to the project or asset
which the Principal expects Contractor to use for labelling or classification purposes
 Plant Breakdown Structure (Site, Plant, Process Unit, etc.) values to be used for the project
 Document numbering, tagging, symbols and drawing specifications and rules
 Any requirements to use any specific software applications (and associated templates) for
part of scope
 Any supplementary Company or International standards, specifications or procedures to be
used.

3. Brownfield projects may decide to comply with the numbering and classification structure of the
original asset, in which case such specific requirements should be included at this stage. A result
is a draft Contract Information Specification template that includes Project specific Information
Requirements, a pre-defined information model (entities and fields) and relevant reference
documents.

To derive maximum benefit from information delivery according to the CFIHOS


standard, the Principal and Contractor should configure software applications and
documents templates using CFIHOS Reference Data and Data Models (for the
information covered by CFIHOS). This will ensure consistency across tools and will
avoid time-consuming mapping exercises during project execution between CFIHOS
and non-CFIHOS based templates by the Principal and the Contractors.

3.1.3 Adjust CFIHOS Template for Local Needs


Local needs may be driven by local regulations, such as Document or Data required by local
regulations, but which are not part of CFIHOS, such as:
 the need for a specific number of paper copies
 the delivery of quality certificates in specific formats (paper, pdf, etc).

The changes identified are incorporated into the project template. Finally, if Principal identifies
additional properties which extend beyond those provided in the current version of the RDL, these
should also be incorporated into the project template.

The result is a draft Contract Information Specification that includes Project specific Information
Requirements with a pre-defined information model (entities and fields) and reference documents in
compliance with local requirements.

3.1.4 Generate Reference Data


The Reference Data Library (RDL) is the dictionary that is specified to the Contractor to ensure that
consistent naming is adapted for tag/equipment classes, properties, and document types, for use
with the Contract Information Specification. The reference data library is a collection of information
in a formal manner such that it is suited for (automatically) processing, interpretation, and
communication.

The RDL is organized as a series of Comma-Separated Values (.CSV) files containing Object
definitions, Tag list, Equipment list, Properties, Units of Measure, Document Types, Pick Lists and any
CFIHOS unique identifiers. The CFIHOS Specification document describes the information model that
ties the RDL CSV’s together.

Page 15 of 31
CFIHOS – Implementation Guide for Principal

The CFIHOS Contract Scenario Templates, described in Section 3.1.1, show the standard expected
RDL CSV’s that should be selected for various Capital Project hand-over scenarios.

In this step, the CFIHOS RDL is tailored to specify the reference data that is expected for the specific
contract scope. The Principal will need to adjust this information model according to their business
requirements and objectives and ensure that the appropriate RDL CSV’s are selected for the
Information Specification created.

The Principal may be able to start to populate the template with reference data already available
from an engineering information repository/Engineering Data Warehouse that will be utilised to
publish the quality checked information during the project. The Principal should also ensure that
any software templates to be furnished by the Principal for use by the Contractor are compliant with
the RDL.

3.1.5 Add Reference Data to Specification


In this step, the Reference Data is added to the information specification per the company business
standards. For example, the document default requirements from the CFIHOS RDL need to be
updated according to company or project specific requirements, including export control, security
classification, document status, and more.

This reference data set can then be attached to the Information Specification. It is recommended to
compile each reference data table into a document with a document and version number so that
any updates can be re-issued as new versions of the reference data pack.

Additionally, relevant reference documents should also be attached. These may include: document
numbering and control procedures, tagging procedures, other data management procedures, etc.

At this point the Contract Information Specification, Reference Data Library, and Reference
Documents are complete.

3.1.6 Finalize Contract Information Requirements


The next step is to complete the IM SoW with additional requirements regarding the frequency of
handovers. The timing of delivery of individual sets of information, quality controls and
responsibilities for consistency of information across the supply chain should be added.

If milestone payments or other incentives are intended to be used, these need to be defined and
aligned with requirements from other disciplines.

For example, there would be no value in defining a milestone based on the delivery of certain
documents if the responsible discipline does not need them until later in the process.

This step should ensure that delivery of the required information is specified clearly with the correct
timing to meet the needs of different users. For example, equipment information is often targeted
for delivery before commissioning but is also often crucial for to the construction contractor for the
definition of construction work packages and should ideally be targeted for delivery before
construction.

The result of this step is a complete Contract Information Requirements Package consisting of an IM
Scope of Work and a Contract Information Specification that is ready for inclusion in the Tender or
Contract documentation.

Page 16 of 31
CFIHOS – Implementation Guide for Principal

It is recommended to specify a regular or continuous (e.g. monthly) delivery of data


from contractors in the Scope of Work. This allows the Contractor to demonstrate an
understanding of the requirements, as well as allowing Principal to test internal data
validation systems.

It is important to remember that the Information Requirements Package needs to


cover requirements that need to be passed down to equipment suppliers and vendors.
Where such requirements cover items that are not covered by the CFIHOS
specification, these need to be added to the Information Requirements Package –
whether they be reference specifications (e.g. Vendor Document Numbering
requirements, Supplier/Vendor Requirements listings etc), or reference data.

3.1.7 Incorporate in Tender Documents


The finalized Contract Information Specification should then be included in the documentation for
tendering or other documents for Contractors to ensure a clear understanding of the requirements
by the Contractor. This allows feedback on feasibility and costs for delivering information according
to the specified requirements. It also enables information management staff to provide project
management with a realistic assessment of the bidders’ capabilities and the likely scale (and cost) of
any rectification work that may be required so these can be factored into the technical and
commercial evaluation.

3.1.8 Adjustments Due to Bidder Clarification


The bidders may return questions, requiring clarification that may result in amendments the IM
SOW, CIS, Reference Data or Reference Documents.

3.1.9 Finalize Information Specification at Contract Award


The Contract Information Requirements Package is finalized for formal transmittal to the
Contractors. At this point, any relevant information generated by earlier project phases (for
example design information) should also be transmitted to the Contractor, consistent with the
formats and rules defined in the Contract Information Specification.

3.2 Generate Information Deliverable


Figure 5 is an overview of Generate Information steps, described in sections 3.2.1 – 3.2.4 below.

Figure 5 Process for Generating Information Deliverable based on CFIHOS

Page 17 of 31
CFIHOS – Implementation Guide for Principal

3.2.1 Contractor Actions


Upon receipt of the Information Requirements, the Contractor would typically engage a Project
Information Management organization with adequate skills to coordinate and execute the following
steps:

 Review and Confirm understanding of the Information Requirements


 Determine the approach and procedure for changes to the specification
 Identify the sources (providers) of the information
 Ensure project-wide awareness of the requirements for information and quality
 Implement procedures & tools for information collection, validation, and handover
 Collect, validate and consolidate information
 Perform handover to Principal.

These steps are discussed in detail in the CFIHOS Implementation Guide for Contractors.

The Contractor needs to understand the Information Requirements, deciding how to meet the
requirement and then configure internal information systems to comply with CFIHOS. The
Contractor also needs to specify CFIHOS compliant deliverables in any sub-contracted work.
Typically, the first 6-9 months of this work is most intense, and much effort should be anticipated to
get the configuration right and the required sub-contracts in place.

Once this is in order, the process of delivery becomes more of an ongoing cycle between the various
parties to receive, review and finalize individual information sets, so as continuously complete
information delivery.

3.2.2 Principal Reviews and Validates Information Delivered


Initially, the focus of the Principal is typically to assure that the quality of the information
deliverables, and ensure they are compliant with the requirements. Once this aspect is addressed,
the focus typically shifts to the monitoring of the progress of the deliverables against the plan.
Information is typically on the critical path to project activities such as procurement and
construction, and good visibility of delivery against plan can enable early interventions that will keep
the project on schedule.

The Principal conducts review and validation steps. Pending the priority and criticality of the
information delivered, the Principal decides on the thoroughness of control of the information. In
case of errors or anomalies, the Principal sends notice to the Contractor for correcting the error,
with an indication of the type of the detected error/anomaly.

The correction follows the same process as the initial creation process. The internal approval and
review process of the Contractor can be different when processing corrections, this should be
defined within the Contractors project quality assurance process and depends on the classification of
the error and the priority and criticality of the information.

Typically, the Principal runs two parallel review processes, one to address deliverables in document
format that is typically reviewed in accordance with a document control process, and a second
process to address deliverables in data formats that are typically more of a “back-office” process to
ensure data compliance, consistency, and more. Joint reviews of larger data deliverables such as 3D
models may also be organized at regular intervals. The results of these parallel reviews are
consolidated together for transmittal back to the originator.

Page 18 of 31
CFIHOS – Implementation Guide for Principal

If the information meets all requirements stated in the Contract Information Specification, the
Principal formally acknowledges that the information was delivered according to the agreed
requirements.

3.2.3 Principal Returns Comments


The Principal returns comments on information delivered back to the Contractor, particularly if any
corrections are required. As may be required by the contract, the Principal formally states that the
information is accepted as complete, correct and consistent. Due dates can be agreed for this
process.

Note that comments should not be used for managing scope changes. If there is a
scope change, the Principal should re-start the process with a change specification.

3.2.4 Contractor Incorporates Comments


Pending on priority and due dates set by the Principal, the Contractor pays attention to such
comments and incorporate comments to correct Information.

Note that the quality procedures of the Contractor should cover the process of
handling comments received from the Principal. These procedures should include
guidelines about review and approval, logging and disposition of the remarks.

3.3 Handover of Information


Within a Principal project, multiple Contractors may have been engaged. This would require multiple
information management scopes and specifications to be defined and issued to the various
contractors to create the full information package/digital twin of the asset being delivered. This
information would consequently need to be validated and consolidated within project systems.

Typically, the Operations applications used for plant operations and maintenance would be different
from those used for Project execution. A system for validation and transformation and loading of the
required subset of project collected data will usually be required.

A project information handover plan will be in place. This should cover the general scope, role,
responsibility, schedule, Quality Control of information to be handed over from project to
Operations covering all forms of information (document, data, database/model) from the project
team, contractors, and vendors. This plan should also outline how interfaces between various parties
(Owner Project team, Contractors, and vendors) will be managed at various stages of the handover
process. More details in the CFIHOS Scope and Procedure Document [C-TP-001].

Separation of Project and Operate systems (within the Principal environment) is


very beneficial for avoiding information conflicts and could help create clear
boundaries for managing concurrent/parallel engineering.

Having an Engineering Data Warehouse (EDW) to store Project collected


information is essential. Having Extraction, Transformation and Loading tools for
moving data from Project to Operate systems is also important to ensure data
quality. It is good practice to be 100% as-built for Safety Critical Element
information and better than 90% as-built overall at Ready For Start-Up, with final
information handover complete within 3 months.

Page 19 of 31
CFIHOS – Implementation Guide for Principal

4 Where to retrieve CFIHOS Documents, Tools and Templates

All documents relating to the CFIHOS Standard are published on the CFIHOS website and can be
downloaded from here.

Narrative Documents
Scope and Procedures (C-TP-001)
Specification Document (C-SP-001)
Implementation Guide for Principal (C-GD-001)
Implementation Guide for Contractor (C-GD-002)
Reference Data Library
Reference Data Library (C-ST-001) – Excel version
Reference Data Library (C-ST-001) – CSV zip file
Data Model
Using the Data Model (C-DM-001) – Powerpoint
version
Data Dictionary (C-DM-002) – Full version
Data Dictionary (C-DM-002) – Light version
Supporting Templates
Contract Scenario Templates

Page 20 of 31
CFIHOS – Implementation Guide for Principal

Annex A: Data, Information, and Documents

Figure A-1 Data, Information and Documents

When Data identifies and describes pieces of information, correspondences or documents including
drawings, it is called document metadata. On the other hand, metadata defines data (entities and
attributes in relational databases) by their structures (data models), data dictionaries and reference
data libraries.

Figure A-2 Data and Documents

Page 21 of 31
CFIHOS – Implementation Guide for Principal

Annex B: Contract Scenario Templates


Here we describe
1) The six scenarios and their definitions
2) The relationship with the CFIHOS RDL
3) The instructions to follow

1) CFIHOS Handover Scenarios

The CFIHOS Project delivers five generic information management specification templates. Industry
experience shows that these covers more than 90% of potential cases across the lifecycle of a plant.
The templates must be customized to produce an information management specification to meet
the specific needs of a contract.

The lifecycle phases that a plant may go through are defined in the CFIHOS RDL Picklist Activity ‘life
cycle activity class’.

The asset is not static during operation but undergoes continuous change through a management of
change process. For larger changes the same phases apply (brown field project).

Templates
The information scope is covered by the following templates:

Template 1: EPC or ESC


Information specification template containing the Information Requirements to be delivered for an
Engineering Procurement Construction (EPC) or Engineering Service Contractor (ESC) contract scope.
Information requirements would be the same for green field or brown field projects, although
volumes will typically be lower for brown field projects.

Template 2: FEED
Information specification template containing the Information Requirements for a Front-End
Engineering Design (FEED) Contract. Procurement or delivery of any hardware is out of scope.

Template 3: Document Only


Information specification template containing the Information Requirements for a Contract
delivering documents only. This may include scenarios like Conceptual Engineering, Surveys/Studies
and Site Preparation; but could also address projects or assets that are managed in a mainly
document centric way, where delivery of structured data is not considered required or useful or
where the maturity of the IM organization on the part of the Contractor or Principal does not
support data delivery.

Template 4: Package Vendor


Information specification template containing the information requirement for packages (i.e. part of
a plant), including how to code, format and exchange information (for review and handover)
between Contractor and Principal. Typically, the scope is similar to an EPC Contract, but the volumes
are smaller.

Template 5: Standard Equipment


Information specification template containing the Information Requirements for standard
equipment purchase orders, including how to code, format and exchange information (for review
and handover) between Contractor and Principal.

Page 22 of 31
CFIHOS – Implementation Guide for Principal

Template 6: Concept Design


Information specification template containing the Information Requirements for a Concept Design
Contract. In the Concept Design template, the procurement or delivery of any hardware and the
associated information is considered to be out of scope.

Page 23 of 31
CFIHOS October
C-GD-001 2024

2) Relationship between the contract scenario templates and CFIHOS RDL


A spreadsheet illustrating the scope and content of each template is available, see section 4.
CFIHOS – Implementation Guide for Principal

Page 25 of 31
CFIHOS – Implementation Guide for Principal

Page 26 of 31
CFIHOS – Implementation Guide for Principal

Page 27 of 31
CFIHOS – Implementation Guide for Principal

Figure B-1 Scope overview per CFIHOS template

Page 28 of 31
CFIHOS October
C-GD-001 2021

The selected template forms the basis of the draft Contract Information Specification. Copy the
template and rename it appropriately according to your company standards and guidelines.

The template specifies what information a Principal should deliver to a Contractor (e.g. naming
conventions, classifications etc. to be used) and what information the Principal expects to be
delivered back by the Contractor (e.g. design data and equipment documentation). Note that this
can differ from contractor to contractor even for the same type of information, depending on the
capability (maturity) of the contractor, equipment suppliers and the requirements for the exchange
of information. The result of this first step is a draft Contract Information Specification template.

While each of the CFIHOS templates identifies Plant Breakdown Structure objects that
would typically be delivered for the kind of project, consideration should be made for
the actual project scope. The scope of a particular project may well alter what is
included. For example, if long-lead items are included in a FEED contract scope, the CIS
should include the CFIHOS “Equipment” object and its properties – which would be a
deviation from the template. As such no CFIHOS PBS object or properties are marked
as mandatory to be delivered, what is mandatory for the Contractor to deliver would
depend on the specific requirements of a project/asset.

Within the definition of the data requirements in the CFIHOS specification, the
Principal will need to indicate whether or not the contractor is required to deliver
specific attributes. For example, in a FEED Contract, while a Contractor may be
required to deliver the Plant Breakdown Structure “Tag” data, this may be limited to
only 50% of such Tag properties defined by CFIHOS, because of the project’s particular
scope.

3) Instructions for usage

1. Principal selects a CFIHOS Template. The CFIHOS Template defines the structure of the
information to be delivered. Principal needs to decide on the standards to be used.
2. Principal adjusts the CFIHOS Template to create an information specification that reflects the
identified business Information Requirements. This may mean removing some elements
from CFIHOS as they are not required or adding new elements to satisfy local business
requirements.
3. Principal selects the relevant reference data (i.e. classes, properties, document types, etc.)
for use with the information specification. Ideally, these will be selected from the CFIHOS
RDL but may also include additional company and/or project specific reference data.
4. Principal aligns the reference data with the information specification according to selected
business standards. (For example, document type requirements for As-Built documents
completed, etc.)
5. Principal finalizes the information specification and the reference data files.

Note that the Contractor may return clarifications which may prompt the Principal to amend the
information specification or reference data.
CFIHOS – Implementation Guide for Principal

Annex C: Contract Information Requirements Package – Overview

Figure C-1 Contract Information Requirements Package based on CFIHOS

Figure C-2 Contract IM Scope of Work content based on CFIHOS

Page 30 of 31
CFIHOS – Implementation Guide for Principal

Figure C-3 Contract Information Specification content based on CFIHOS

Page 31 of 31

You might also like