SP-2065 Technical Data Management

Petroleum Development Oman L.L.C.
Document Management in Engineering and Operations
Document ID SP-2065
Document Type Specification
Security Restricted
Discipline Technical Data Management
Engineering and Operations Information

Owner
Management (UOI)
Issue Date June 2018
Revision 6.0
This document is the property of Petroleum Development Oman, LLC. Neither the whole nor any part of this document
may be disclosed to others or reproduced, stored in a retrieval system, or transmitted in any form by any means
(electronic, mechanical, reprographic recording or otherwise) without prior written consent of the owner.
Petroleum Development Oman LLC Revision: 6.0
Effective: Jun-18
I Document Authorization
Authorized For Issue – June 2018
Page 2 of 38 SP-2065: Document Management in Engineering Projects and Operations Printed: June 25, 2018
The controlled version of this CMF Document resides online in Livelink®. Printed copies are UNCONTROLLED.
Effective: Jun-18
II Revision History
The following are brief revision summary of this document. Details of all revisions prior to
these are held on file by the issuing department.
Revision Date Authors Scope / Remarks
No.
Revision Mar- Mike Turberville 1. Updated numbering requirements. Aligned with
2.0 11 UEPI/1 changes to SP-2047
2. Roles and Responsibilities moved to Section 2
3. Definitions and Abbreviations moved to
Appendices
4. Updated some text to reflect changes in PDO
Doc management strategy for Projects
5. New Owner and Custodian.
Revision Apr-11 Mike Turberville UEP/1 6. Updated numbering requirements

3.0 7. Additional Clarity and Guidance on numbering
8. Request/Advice form added as Appendix 4
Revision Sep- Kingsley Chime Updated to reflect actual practice
4.0 12 UEPI/41A
Revision Nov- Kingsley Chime 1. 5.3.1: review return code for vendor added
5.0 15 UEPI/41A 2. Appendix 9: A4 document template added
3. 5.4: added relationship between old and new
numbering format
4. 2.4.2: Vendor Data Book and Manual Index
moved to SP-1131
5. 2.5.1: As-Built modification requirement moved
to PR-1666
6. “Request for Issue “requirement deleted.
7. Project code administration included
Revision Dec- Kingsley Chime UOI/41 1. Return code on 5.2.1 reflected on appendixes
5.1 15 2. New version of IM Kick-off form attached.
Revision May- Kingsley Chime UOI/41 1. Document Issue code separated from status
6.0 18 code
2. Updated section 5.1 to illustrate application of
Issue and Status codes
3. Added requirements to accommodate FEED
Office undertaking detail design.
4. Improved vendor document requirement
Effective: Jun-18
The related CMS Documents can be retrieved from the CMS Business Control Portal:
FR-01 PDO Control Framework (FR-01)

PL-14 The PDO Intellectual Property (IP) Policy
CP-117 Project Engineering Code of Practice
CP-115 Operation of Surface Product Flow Assets
CP-102 Corporate Document Management Code of Practice
CP-139 Corporate Data Management Code of Practice
CP-199 Information Management Code of Practice
CP-224 Technical Data Management Discipline Governance
GU-556 Guideline for Vendor Project Document Deliverables
PR-1666 E & O Document, Drawing and Data Management Procedure
PR-1692 PDO Document Retention Procedure
PR-2117 Engineering Project Data Control Procedure
SP-2067 PDMS Model Specification
SP-2099 2D Drafting Specification
SP-2117 Information Confidentiality Classification Specification
SP-2122 E&O Information Management Specification
SP-2133 Project Engineering Design System (EDS) Specification
SP-2134 PDMS Global Specification
SP-2141 3D Laser Scanning Specification
SP-2142 Project Data Specification
SP-2144 Engineering Project IM Scope of Work.
SP-2195 Project Initiation and Closeout Specification (RAMZ/AutoPCC)
SP-2213 Asset Registration and Verification Standard
External Document: DEP 82.00.10.30-Gen: Engineering Information Specification (EIS) -

2012
Effective: Jun-18
Table of Contents
1. INTRODUCTION ........................................................................................................................... 7
1.1. Purpose................................................................................................................................... 7
1.2. Scope ....................................................................................................................................... 7
1.3. Distribution / Target Audience ....................................................................................... 7
1.4. Review and Improvement ................................................................................................ 8
1.5. Step-out Approval ............................................................................................................... 8
1.6. Abbreviations ........................................................................................................................ 8
1.7. Definitions .............................................................................................................................. 9
2. DOCUMENT MANAGEMENT ................................................................................................ 11
2.1. General Requirements.................................................................................................... 11
2.2. Project Initiation ................................................................................................................. 11
2.3. Document Planning Strategy ....................................................................................... 11
2.4. Design Document Planning .......................................................................................... 12
2.5. Vendor Information Planning ........................................................................................ 13
2.6. Document File Format .................................................................................................... 16
2.7. Review and Return of Comments .............................................................................. 17
2.8. Document Approval ......................................................................................................... 20
2.9. Documents Reviewed/Approved in 3D Model ....................................................... 21
2.10. Demolition Works .............................................................................................................. 22
2.11. Document with Hold Point ............................................................................................. 22
2.12. Cancelled and Superseded Documents .................................................................. 22
2.13. Suspended Project ........................................................................................................... 23
2.14. Construction Work Packs .............................................................................................. 23
2.15. Design and Construction Changes ............................................................................ 23
2.16. Red-Line Mark-Up (RLMU) ........................................................................................... 23
2.17. Final Information Deliverables Handover ................................................................ 24
2.18. Check-out and Check-in Requirements ................................................................... 26
2.19. Correspondence Numbering and Control ............................................................... 26
2.20. Quality Management ....................................................................................................... 27
3. DOCUMENT NUMBERING STRUCTURE ....................................................................... 28
3.1. Document Taxonomy ...................................................................................................... 28
3.2. Issue and Status Code ................................................................................................... 30
3.3. Revision Convention and Control ............................................................................... 31
3.4. Renumbering of “Old System” Documents ............................................................. 31
3.5. Vendor Documents Numbering ................................................................................... 32
3.6. Project ID and Project Code Administration ........................................................... 32
4. DOCUMENT EXCHANGE ....................................................................................................... 33
4.1. Collaboration Media ......................................................................................................... 33
4.2. Exchange of Documents ................................................................................................ 33
5. ROLES AND RESPONSIBILITIES ....................................................................................... 35
6. APPENDIXES ............................................................................................................................... 38
6.1. Appendix 1 – User Feedback Form ........................................................................... 38
Effective: Jun-18
6.2. Appendix 2 – IM Kickoff Form ...................................................................................... 38

6.3. Appendix 3 – Blank VDRL and Equipment List and Customized VDRL ..... 38
6.4. Appendix 4 – Information Requirement scope for MR/PO ............................... 38
6.5. Appendix 5 - Document Status Code Descriptions ............................................. 38
6.6. Appendix 6 – Vendor MRB Document Cover Sheet ........................................... 38
6.7. Appendix 7 - Vendor Document Schedule (VDS) Blank template ................ 38
6.8. Appendix 8 - Vendor Document Requirement Catalogue (VDRC) ............... 38
6.9. Appendix 9 – Document Templates: Excel, Word and Drawing .................... 38
6.10. Appendix 10 – Comment Resolution Sheet (CRS) ............................................. 38
6.11. Appendix 11 – Vendor Document Requirement Matrix (VDDM) ................... 38
6.12. Appendix 12 – Document Distribution Matrix ........................................................ 38
6.13. Appendix 13 – Document Deliverables Register .................................................. 38
6.14. Appendix 14 – Master Document/Drawing Revision Conversion .................. 38
6.15. Appendix 15 - Equipment List and Vendor MRB Delivery ................................ 38
Effective: Jun-18
1. INTRODUCTION
Information Management (IM) is one of the key requirements of Engineering and Operations
CoP (CP-117 and CP-115) within the Opportunity Realization CoP (CP-223). Within the
framework, project design deliverables need to be generated, reviewed and approved before
they are translated into physical assets that can be procured, constructed, commissioned
and operated.
Poor management of information has resulted in missed opportunities, higher costs, process
safety issues and even litigation. Engineering and Operations functions have adopted a
common framework for Information Management practice for PDO and their contractors that
ensure documents/drawings generated are delivered in a format compatible with PDO
systems. This document specifies the standard for document management in Engineering
and Operations, which shall be used in conjunction with PR-1666: Document, Drawing and
Data Control Procedure.
1.1. Purpose
The purpose of this specification is to define requirements for document management that
would support creation of documents suitable for use to support operations. These
requirements comprise:
 Documents requirement planning
 Document numbering taxonomy
 Document development, issue, review, approval and update
 Control hardcopy requirements
 Document templates, exchange and tools
Document exchange process refers to the flow of documents within the project team, as well
as between the project team and external parties.
1.2. Scope
This document specifies the document management standard to be implemented in
engineering projects, which would deliver quality information deliverables for Operations. It
covers the general strategy for document management, vendor requirement, review and
exchange method, and numbering taxonomy. It defines the relationships, roles and
responsibilities of project team members, IM team, contractors and vendors during the
implementation.
1.3. Distribution / Target Audience
This document shall be used by PDO project delivery teams comprising of a project
manager, project engineers, technical discipline engineers and designers, operations and
project services personnel, as well as external project delivery partners: vendors, suppliers,
consultants and contractors.
Effective: Jun-18
1.4. Review and Improvement

The owner of this document is the manager, Engineering and Operations Information
Management (UOI) and the custodian is the Business Improvement Team (UOI4).
Users of this Document who identify inaccuracy or ambiguity should notify the custodian or
his/her delegate, and request changes to be initiated. The Requests shall be forwarded to the
custodian using the “User Feedback Form” provided in the Appendix 1.
1.5. Step-out Approval

Should compliance with the specification be considered inappropriate, or the intended activity
cannot be effectively completed or safely performed, a deviation request shall be processed
using the online Variance Tracking Tool. The request shall highlight those aspects of this
specification being deviated from, and obtain approval from the document owner before
deviating from any activity or requirement associated with this specification.
1.6. Abbreviations
In addition to the glossary and definition in the EIS, the following specific definitions of
abbreviations apply:
AIC Asset Information Centre
AI-PS Asset Integrity Process Safety
ARV Asset Register Verification (SP-2213).
CSV Comma Separated Values, a document format that allows data exchange
between different applications.
CSR Concept Selection Report
CMMS Computerized Maintenance Management System
DCC/DC Document Control Centre / Document Controller – Office / individual(s) that
provides all document control services as outlined on this document.
DCAF Discipline Control and Assurance Framework
DCS Document Control System – System set up and used by DCC/DC to provide
document control services during the life of a project.
DDR Document Deliverables Register – list of all project deliverables to be delivered
in a project.
DDM Document Distribution Matrix – distribution of all project deliverables as listed on
the DDR
EDMS Electronic Document Management System (Livelink) – PDO system used for
document storage/retrieval
EIS Engineering Information Specification
EPC Engineering Procurement and Construction
EMC Engineering Maintenance Contract
EOIM Engineering and Operations Information Management
ERP Enterprise Resource Planning
EPC, External Project Contractor responsible for all or part of the Design,
EMC, Engineering, Procurement, Construction, Commissioning or Management of a
Effective: Jun-18
ODC etc project, or operation or maintenance of a facility

FCP Facility Change Proposal
FID Final Investment Decision
FTP File Transfer Protocol; the platform that allows document exchange between
project team and external parties.
IDC Inter-Discipline Check
IM Information Management
IOM Installation, Operation and Maintenance Manual
ITT Invitation To Tender
MR Material Requisition
MRB Manufacturers Record Book
PDF Portable Document Format – Application or Scanned rendition format for read
only files.
PDO Petroleum Development of Oman LLC of Muscat, Sultanate of Oman
PCAP Project Control and Assurance Plan
PM Project Manager
PDMS Plant Design Management System
PO Purchase Order
PSUA Pre Start up Audit
RLMU red line mark-up drawings
TA Technical Authority
VDRC Vendor Document Requirements Catalogue – a listing provided by PDO that
gives a brief description of all the document types stipulated in PDO’s data
requirements
VDRL Vendor Document Requirements Listing – a listing compiled showing specific
deliverables requirements relating to the equipment being supplied.
VDS Vendor Document Schedule – a list of the entire Vendor document agreed with
PDO, with appropriate numbers and titles, scheduled for submission.
WP Work Package; a group of activities that are considered as one unit from the
planning perspective.
1.7. Definitions
ASSAI/Livelink Refers to a combination of ASSAI and Livelink to provide a system of

secure document control and storage solution for all documents.
ASSAI PDC ASSAI Project Data Controller: ASSAI module used by the DCC
ASSAI Web ASSAI module used by users for document review and approval process.
Revision control is typical functions provided. Details can be found on
http://www.ASSAI.nl/.
Contractor Party that have contract with PDO to provide design, construction, Study,
etc, or as defined in the Contract.
Critical List of deliverables critical for the Operations and Maintenance of an Asset
Documentation as defined in CP-115.
Compound Multiple independent documents (created, reviewed, approved and
Document numbered independently), collated and delivered against a single document
Effective: Jun-18
number revision.
Controlled / PDO E&O documents are controlled electronically in the document
Uncontrolled management system (ASSAI/Livelink), and become uncontrolled when
printed except when printed with Watermark/stamped “Control Hardcopy”.
Deliverable(s) Product(s) of an activity (ies) or undertaking(s). The product can be a
document, data or just an activity.
DCAF Discipline Control and Assurance Framework, that specifies TA level
required to review and approve discipline deliverables.
Document Manuals, drawing, reports, datasheet, etc
Document Project deliverables are managed electronically. Access to these
Security documents is on the “need-to-know” basis. All commercially sensitive
contract, project management and tender document will be retained in a
secure location on Livelink.
Electronic Electronic file created by scanning or direct rendition through software.
Image
IM deliverables Documents; drawings; MRBs; Engineering Data; SPIR; Asset
Register/CMMS; SPI/INTOOLS; Corrosion Data; Tag Register; 3D Model
IM Focal Point Information Management (IM) Staff: IM Lead, Document/Data Controller,
EDS Lead and or EDS Specialist, assigned to provide IM service
IM Kick-off Form Form used during project initiation, to request support information: Area
code, Tagging convention, EDS requirements, IM requirements existing
asset drawing/documents, etc
Inter-Discipline Contractor review cycle involving team members/disciplines outside the
Check originating discipline/team.
Livelink PDO corporate EDMS.
May The word ‘may’ is to be understood as a possible course of action.
MRB Document delivery format for vendor documentation, identified for delivery
as a result of manufacturing, installation, integration, commissioning and
handover of a piece of equipment.
Native File Editable Electronic File Format.
Petroleum Initiates the project and ultimately pays for its design and construction.
Development
Oman (PDO)
Project Team PDO staff assigned to deliver project scope (usually through contractor).
Shall The word ‘shall’ is to be understood as mandatory.
Should The word ‘should’ is to be understood as strongly recommended.
Start-up Introduction of hydrocarbon to a facility
Registers and Electronic copies of documents and drawings will be logged and filed by the
Filling DCC using appropriate document control tools (eg ASSAI) and in
accordance with the Project filing scheme.
User Any person who applies this standard.
Effective: Jun-18
2. DOCUMENT MANAGEMENT
2.1. General Requirements
 Follow PR-1666: Document, Drawing and Data Management Procedure for document
reviews and approval process
 Documents not yet issued should be kept in team work-in-progress work area (e.g.
livelink), while issued documents should be stored and controlled in a secured document
management system. Keeping work related files on the Desktop PC or any other storage
media outside dedicated work-in-progress team area is not allowed.
 PDO TAs shall review revisions but only approve key milestone stages of a document
development e.g. AFD and AFC
 Upon notification that a new member has joined the project team, IM on boarding shall be
conducted before granting access to Information Management system.
 Project deliverables review/approval status report shall be issued by the project IM team
periodically to show performance of project IM KPIs
 IM resource shall be in place to support project document management from Select
Phase.
 PDO’s standard drawing symbol and digitizing menus shall be employed, as well as data
files for existing drawings which will be provided to assist the consultant/contractor during
detailed design, refer to SP-2099 for details.
 The custodian of IM deliverables during project is the project manager. During operation,
the custodian of electronic master information from project is UOI2 (AIC) but the owner is
the Asset Operation Manager (CP-115).
2.2. Project Initiation

During project initiation, contractor shall reference the E&O IM Portal to identify existing
documents that would be modified in project. The contractor shall utilize the IM Kick off Form
(appendix 2) and request PDO to provide support information like existing reference
drawings, tag allocation, Area or Facility Code, document numbers, EDS requirements and
check out for As-Building, etc.
2.3. Document Planning Strategy
Information deliverables planning shall align with the overall project deliverables progress
measurement methodology, and should be monitored at document or work package or
project level. The IM Lead shall agree with the project team which of the following project
information development milestones would be applicable and monitored in project:
IDC Planned date for contractor to complete internal review Mandatory
IFR planned date to issue document for project team review Mandatory
AFD/AFC/ planned date to deliver Approved for Design/Construction Mandatory
ASB and As-Built
IDR planned date to issue documents for Design Review Project selection
IFH planned date to issue document for HAZOP Project selection
IFS planned date to issue document for SAFOP Project selection
Effective: Jun-18
The selected milestone dates shall be as contained in the project planning system (e.g.
Primavera), and be determined as part of project initiation and applied to develop project
DDR (for design deliverables) and VDDR (for vendor deliverables).
2.3.1. Existing Document Dependency
Where project scope includes modification of existing Asset documents, the project team
shall follow the Dependency Matrix requirements contained in SP-1131 and evaluate the
impact of the modification on the dependant deliverables.
The dependant documents shall be included by default in the project information delivery
scope of DDR and be verified/updated as part of project. Just like any existing document
identified by the contractor for modification in project, these documents shall be obtained for
reference during project and verified for impact by designated doctype design engineer.
Where project scope “impacted” any of the dependant documents it shall be checked out/in
from AIC for final update. In a “no impact” situation, the doctype discipline engineer shall
update the DDR indicating that the documents were “Verified for project scope, no impact”.
This is a key information deliverables handover assurance requirement that could impact
project closeout.
2.4. Design Document Planning
Design document planning requires each discipline to define a set of document deliverables
against each work package defined in the project planning system (e.g. Primavera). These
identified documents shall be used to create the document deliverables register (DDR).
2.4.1. Document Deliverables Register (DDR)
The DDR contains listing of information deliverables doctypes selected from PLIP, with their
tentative milestone delivery plan; click here for DDR project template. As part of project
initiation the contractor discipline engineer shall agree discipline scope with project team and
identify DDR doctypes from PLIP to become the high-level discipline DDR. The contractor
shall collate DDR discipline scope into one master DDR and issue to IM Lead and discipline
engineered for review/approval In line with DDM. The actual documents are generated
against doctype, added as new record in the DDR and shared with project team periodically:
Information development milestones defined and applied in the DDR shall be assigned a
planned start date and a planned end date (according to data from the planning system), and
shall be loaded into the project document control system with status “PLN”. The milestone
planned date for a doctype like PEFS shall be obtained from the planner and be applied for
all PEFS generated in the project unless advised differently.
The documents maturation progress can be measured as a percentage at each new
milestone attained. Contractor shall submit to PDO every two weeks the DDR progress
Effective: Jun-18
report indicating Contractor’s forecast dates of issue for review/approval of all relevant
documents/drawings.
2.4.2. Document Distribution Matrix
The DDM is a PDO business process for internal project document distribution which shall be
concluded as part of project initiation using template of appendix 12. It shall be applied each
time a project document created by a contractor, requires PDO review input and/or approval.
The PLIP contains default document distribution which shall be referred by the project team
to produce the project specific DDM. The DCC team shall apply the project specific DDM in
distributing project documents and will not accept distribution request outside the DDM.
The contractor shall develop and formalize their document distribution, as part of project
initiation, and shall be a key reference document for assurance reviews and audits.
2.5. Vendor Information Planning

Depending on the Contract strategy, PDO can engage directly with a vendor or indirectly
through a Contractor. PDO engages directly with a vendor when Purchase Order (PO) is
issued directly to the vendor (to supply one or more pieces of equipment/material, etc). In this
situation it is the responsibility of the PDO package engineer/procurement team to ensure
that the one page IM requirement (appendix 4) and customized equipment VDRL is included
in the MR/PO document, and that these deliverables are ultimately delivered to PDO.
When the equipment or material in PDO store is assigned to a contractor for installation, the
contractor shall also obtain the associated equipment information deliverables from the store
or procurement team. The information deliverables received from store is inherited by the
installation contractor and becomes part of contractor’s handover deliverables to operations.
PDO engages indirectly with a vendor when the vendor received the PO from a Contractor
(EP/EPC) with PDO. In this situation, the Contractor takes full responsibility to ensure that
customized VDRL for the equipment is included in the MR/PO document. The contractor
shall ensure compliance to this specification, and that these deliverables are ultimately
delivered.
In both situations, vendor documents shall be submitted and approved against discipline
scope of work contained in the PO before any commissioning activity is undertaken (unless
agreed to delay delivery for certain information). However if supplied equipment requires a
modification during installation, commissioning/initial operation, the party making modification
at this stage will RLMU the affected drawing/document, indicating the changes made. The
requirements for updating the vendor document shall be determined by the PO requirements
for the affected equipment. The timescale for the submission of modified documents by the
vendor will be agreed or regulated against conditions laid out in the contractual stipulations of
the PO.
2.5.1. Vendor Information Requirements
The attached vendor information requirement scope of appendix 4 and customized
equipment VDRL shall be included in MR/PO. MRBs shall be delivered for all
Engineered/Specified and Standard Manufactured equipments. Contractor shall utilize
sample template attached in appendix 15, and maintain equipment scope list for project
highlighting MRB delivery scope.
Effective: Jun-18
PDO information scope is grouped into: Engineered/Specified Equipment, Standard

Manufactured Equipment and Standard Off-the-Shelf Equipment. As contained in equipment
specific VDRL in equipment library, each procurement activity shall follow information
requirements specified for each equipment procurement group:
Engineered/Specified Equipment: Equipment manufactured based on PDO provided
design specification (no matter how small), and which PDO participate in the engineering
review. Vendor information doctype contained in customized VDRL for the equipment shall
be generated and reviewed/approved in line with VDDM/DCAF/PCAP requirements and
delivered as MRB in line with our requirement for tagging/tag format, PDF rendition of native
file, etc.
Standard Manufactured Equipment: Engineered equipments manufactured with 100%
vendor specification as soon as Purchase Order is received from PDO. As part of requisition
process, the vendor shall utilize blank VDRL template of appendix 3 to confirm their
information handover scope. Where key operate and maintain records were not included in
the vendor information scope, it could be agreed to be added as part of revised requisition.
Vendor handover MRB shall be under PDO coversheet and comply with PDO requirements
for tag format, tag-to-document mapping and PDF rendition of native file.
Standard Off-the-Shelf Equipment: Standard equipments already manufactured by the
vendor based on vendor specification and readily available for delivery. PDO will receive
information offered by the vendor (even if it is only datasheet), in the format being offered by
vendor but under PDO coversheet and document number.
The following table contains summarized vendor information scope definition for engineering
projects and FCPs:
Effective: Jun-18
2.5.2. Vendor Document Requirements Listing (VDRL)

PDO has customized and generated VDRL for all engineered equipments in the equipment
library, which shall be referred by procurement stakeholders for minimum information scope
to be included in the MR/PO.
During the requisition process, the vendor shall review PDO/Contractor’s IM requirements as
laid out in the received MR/bid package-specific VDRL. All comments or technical
clarifications or such issues as document omissions and non-relevance of document for a
particular piece of equipment should be raised and resolved.
Following the bid clarification, a revised requisition package along with the PO will be
submitted to the Vendor with a revised VDRL, listing any changes that have been made after
vendor review of the VDRL. The Vendor will be required to sign the revised VDRL as
acceptance of document delivery and submission requirements.
Where new vendor record is identified to be included in the VDRL template, the project shall
follow MoC process to add record before application in project. Handover of vendor record
not contained in the VDRL template will be rejected.
2.5.3. Vendor Document Schedule (VDS)

Upon Contract award, the vendor will be required to submit a completed Vendor Document
Schedule (VDS) for all Engineered and Standard Manufactured equipments, as part of the
first initial submission of document to PDO/Contractor. The VDS will comprise a complete
listing of deliverables intended for submission by the Vendor to complete the equipment
design requirements; timing of submission to comply with the timing set in VRDL attached to
the PO.
The VDS also includes planned submission or due dates listed against each document
stating an estimated time for each initial document submission. Once reviewed and returned,
the Vendor will be required to re-submit the revised VDS in line with any comments received
and subsequently submit updated VDS monthly or as agreed with Project team.
Typically the Vendor will include a CSV file with each VDS submission which will be
uploaded into the Project document control system. Each purchase order can be set up as
an equipment Work Package in the document control system against which the Vendor VDS
can be loaded.
As documents are reviewed, returned and approved, a percentage of overall completeness
can be rolled up against the work package. Overall package completeness will be dependent
on the current approval status of documents loaded against a given Purchase Order. When
all deliverables have been finally approved the Purchase Order would have reached 100%
completion within the document control system.
Failure to comply with this requirement may result in delays to the Project Schedule. Meeting
deliverable dates for vendor documentation is critical to project success and therefore once
agreed upon, can only be altered with consent of project team.
2.5.4. Vendor Document Deliverables Matrix (VDDM)

The VDDM contains the deliverables of VDRL with a standard distribution that could be
followed when review/approval is required. Each deliverable of the VDS that require PDO
Effective: Jun-18
review shall be distributed according to the VDDM as attached in appendix 11, and could be
adopted for use by the contractors involved in procurement.
2.6. Document File Format
2.6.1.General Format
Each electronic file shall be self contained, i.e. will not require or call in any other project
delivered electronic files for viewing or updating other than agreed reference files. It is not
acceptable for non-standard (Korean or Cyrillic) character set to be required to be installed
on user machine to allow the file to be used. All project documents shall be produced in
compliance with ISO standard A1, A3, and A4 sizes.
Where hardcopy submission forms part of the deliverable in the Project, the issue, review,
approval and “Control Hardcopy” requirement is the same as specified in this document but
the following requirement shall also be met as a minimum:
 Hard copy prints to be submitted in collated sets.
 Hard copies shall be submitted in a clearly legible paper format.
 Documents shall be scanned at their original size directly from the original hard copy.
 Images shall be scanned in an orientation that allows viewing without rotation.
 Paper copies submitted in a size over A3 should be fan folded such that the title block will
be visible and allows easy insertion into plastic wallets.
 A4 documents to be stapled or bound dependent on size.
 Standard number of copies to be submitted for review should be agreed with project
team.
Unless specifically requested by project team to deliver native file for review, and when
review cannot be effectively performed electronically in pdf format, external party shall submit
review files in pdf (made from the rendition of native file). However the following document
types shall always be submitted in native format at all revision: all schedules, ASCI files and
all business process data files (registers, EDS seed files etc).
Where dates are held in databases the format shall be DD-MM-YYYY e.g. 05-10-2010 while
dates used on correspondence, etc shall be e.g. 12 December 2007.
2.6.2. Sets and Sizes of Files
File size for each design and vendor document (VDRL record) shall be a maximum of
200MB. Larger files and document delivered in multiple renditions (e.g. doc and PDF), shall
be split into smaller files and assembled into sets for delivery against a single document
number revision.
When splitting lager files into smaller files, the following shall apply:
 Split the document at natural section breaks (indicated by section markers).
 If the document has no natural section breaks but exceeds the allowable file size, the
document shall be split into allowed file-size limit.
When assembling split files into sets of files, the following shall apply:
 Zip files are highly discouraged unless it is agreed with IM Focal point.
Effective: Jun-18
 Nominate the primary document and treat it in the same way as any other document,
giving it a document number and revision.
 Assign the same document number and revision to all other files in the Set, but name
each with a Document Title reflecting the sequence of the files as they should appear
in the complete document.
Acceptable examples are:
1. Vendor Manual Centrifugal Pump Model XYZ Sections 1 to 5
Vendor Manual Centrifugal Pump Model XYZ Sections 6 to 10
Vendor Manual Centrifugal Pump Model XYZ Appendix 1
Vendor Manual Centrifugal Pump Model XYZ Appendix 2
2. Compressor Station Layout PDF(Page 1-50 of 250)
Compressor Station Layout dwg (Page 51 – 180 of 250)
Compressor Station Layout xls (Page 181 - 250)
2.6.3. Document Title - Guideline

The document title assigned should be a true reflection of the content. Care must be taken
that a title assigned is as explanatory and unique as possible to enable the drawing to be
identified at a glance, and retrieved if searched for in the drawing control database.
Document number, title, page number (page x of n) and revision should appear on each
page of document to ensure proper identification.
“General Arrangements Separator V5105” and not simply “General Arrangement’
“Process Flow Scheme Crude System” and not simply “Process Flow Scheme’
“Structural Steel Walkways Type ‘A’ “and not simply “Structural Steel Walkways’
File name for externally (contractor, vendor, etc) generated deliverables should be the
document number only, for example: design “AAA-BB-CCCCCC-DD-EEEE-GGGGG-
HHHH.xls” and vendor AAA-BB-CCCCCC-ZV-A01-GGGGG-HHHH.xls.
2.6.4. Document and Drawing Binding
Drawings produced in A1 and A3 format shall be provided with margins to enable binding
after reduction. These shall be as follows:
 A1 to A3 – The A1 shall be provided with a blank margin 40mm on the left hand
side of the drawing.
 A3 to A4 - The A3 shall be provided with a blank margin 35mm at the top
border of the drawing.
2.7. Review and Return of Comments
For project team internally generated documents, the originator is responsible for any
updates to documents, when required; the discipline may assign the role to other persons in
the team.
In the absence of any intermediate events requiring document updates, documents shall be
updated for currency every 3 years.
Effective: Jun-18
Some documents may not require updates after a certain point for the duration of their
lifecycle, it is expected that the originating discipline will remain aware of the state of the
documents for which they have responsibility.
Every document/drawing shall go through at least one review cycle before it is approved
except for standard or typical drawings. Standard and typical drawings that will be applied in
the project shall be identified in the DDM.
2.7.1.Project Team Document Review
Documents/drawings generated by contractor and identified in the DDM for project team
review and comments shall follow the following requirements:
 ASSAI is the application through which project document deliverables are controlled
(reviewed and approved) while the actual electronic files are stored in Livelink (PDO
corporate EDMS).
 All documents issued shall be accompanied with a transmittal indicating clearly the
purpose of issue (e.g. IFI, IFR). The default review cycle time is 10 working days but can
be adjusted to suit the requirement of the project.
 Contractor shall ensure that adequate IDC review is undertaken to confirm technical
adequacy and quality before issue to PDO. Any delay or rework associated with low
quality information issued to PDO shall be the contractor’s responsibility.
 For information that does not require PDO review, contractor shall ensure that document
is reviewed internally by contractor’s engineer with commensurate technical capability.
 Documents or drawings issued for review/comment in pdf format shall be made from the
direct rendition of native file (‘comment-enabled’).
 PDO shall comment and return to Contractor within 10 working days all requested
documents which are issued in accordance with the forecast dates in the DDR. PDO
shall not be obliged to return within 10 working days any documents that are not issued
in accordance with the forecast report issued by the Contractor.
 In the event documents have not been returned to Contractor within ten working days
after issue, Contractor shall advise PDO in writing of their intention to proceed with the
Work, detailing the relevant documents. If PDO does not return the documents within the
next (….timing to be agreed with project team….), Contractor shall issue the relevant
documents at the next stage in document development and mark them with the following:
 “PDO Comment Default”;
 Number of transmittal under which the documents were submitted for
comment;
 Reference and date of reminder written advice.
 Contractor will implement all comments made by PDO unless the Contractor disagrees
with the comments, in which case the comments in question shall be discussed and the
follow up requirements agreed with PDO prior to their implementation.
 The Contractor shall maintain a Comment Response Sheet to trace comment history.
Effective: Jun-18
 In the event implementation of the comments results in substantial modifications to

documents, contractor shall reissue the modified documents which shall be clearly
marked “re-issued for Comment”.
2.7.2. Project Team Return of Comments
All comments made as a result of formal review of project documentation shall be returned
via the DCC. Project team members will be trained to use ASSAI Web to enable them to
review and provide comments on document assigned to them. Comments provided by the
reviewer shall be technically clear (not vague) and straight to the point to avoid dely.
Hands-on training shall be provided by the DCC team but users will benefit primarily from
‘learning by doing’. With this in mind, DCC will always be available to provide one-on-one
assistance when required.
There are two primary ways project team could use ASSAI/LL while providing comments:
1. Entering comments directly using comment template on ASSAI web referencing the
appropriate section of the document reviewed in which comment was made, or
2. Scan mark-up hardcopy drawing or electronic (tracked comment) copy of the document
and load into ASSAI (if possible) or send scanned copy to DCC. In this case, the reviewer
shall indicate as comments in ASSAI Web comments template that comments have been
submitted by mark-up.
In both cases, reviewer shall select appropriate review return code in ASSAI and save to
close the review cycle. Failure to do so will result in an, outstanding/overdue flag raised
against the action owner.
PDO or Contractor DCC shall utilize the comment resolution sheet of appendix 10, populate
with comments received from the review cycle, and communicate to originator via the
dedicated collaboration media under the cover of an external transmittal. This shall be
followed-up with an email notification to the receiver advising comment placement.
2.7.3. Contractor Document Management
Contractor document management systems (if different from PDO) shall have capabilities
that allows storage, review and approval audit trail, tracking of revisions and associated
metadata, and supports bulk loading and downloading of documents.
Inter Discipline Check (IDC)
The IDC is the contractor internal review milestone that is used to obtain formal review input
from discipline teams outside the originating discipline. This review cycle shall follow
contractor internal auditable review/approval process, and be completed before a document
deliverable is issued to project team for review/approval (when required) according to the
DDM.
For DCAF/PLIP doctypes, where contractor is designated to review/approve a document,
they shall copy IDC revision to PDO for IFI only as shown below:
Rev 1 - IDC Contractor review cycle Issue copy to project team - IFI
Rev 2 - IFR Project team review cycle Issue to project team - IFR
Rev X - AFC/APP Contractor approved document Issue to project team – IFI
Effective: Jun-18
PDO system would hold the review and approval version of the document revisions. Records
of IDC shall be maintained, to show contractor internal review/approval outcome, which could
be required during assurance reviews and audits.
2.8. Document Approval
Typical or Standard drawings can be issued approved at revision 1 as long as these
drawings are identified as typical/standard drawings on the DDR. Single discipline (no RTA
from other discipline) deliverables already reviewed in IDC (copied PDO IFI) should issued
AFC, as long as the recorded evidence of IDC TA input/review is attached to the Assai.
Checking of Final As-Built drafted against authorized RLMU should be done by contractor
engineer with capability to validate the outcome of the drafting work.
2.8.1. Project Team Document Approval
The following requirements shall be followed for documents/drawings identified in the DDM
for project team approval:
 These documents shall be issued for approval after project team review was completed;
refer section 3.2 for issue cycle guide.
 Documents shall be approved electronically first by the designated TA or document
owner and, or PM (or delegate) using the electronic document management system
(ASSAI), with sufficient audit trail.
 When new revision of document existing in hardcopy is issued, the hard copy custodian
shall replace existing hardcopy at all the places where they are located.
 Project team shall return to Contractor within 10 working days all documents which are
issued in accordance with the forecast. Project team shall not be obliged to return within
10 working days any documents that are not issued in accordance with the forecast by
the Contractor.
 If documents have not been returned to Contractor within 10 working days after issue,
Contractor shall advise PDO in writing of Contractor’s intention to proceed with the Work,
detailing the relevant documents. If PDO does not return the documents within the next
(….timing to be agreed with project team….), Contractor shall issue the relevant
documents at the next stage in document development and mark them with the following:
 “PDO Approved by Default”;
 Number of transmittal under which the documents were submitted for
approval;
 Reference and date of reminder written advice.
 If the documents issued for approval are returned to Contractor with comments, the
documents shall be treated as if they were issued for comments and after
implementation of the comments, be re-Issued for Approval.
 To approve a document, the approver shall log-on to Assai system and after confirming
all comments are incorporated, type "No Comment" on Assai comment template and
select appropriate return code to close the approval cycle.
Effective: Jun-18
 Documents returned with “Code A” or “Code C” is “Approved” and shall be progressed to

the next status in the development sequence. Approved documents shall be released for
subsequent implementation.
 When a document is issued for approval (IFA), it is issued to designated approval party
as shown on distribution matrix; the remaining review parties during review gets it IFI.
 Drawings shall be checked and approved by the originating party at each revision
submittal. This shall be applicable for both master drawing and project drawing changes.
 Unless otherwise stated differently in PO, the vendor document/drawing approval shall
be obtained before equipment dispatch due dates.
2.8.2. Contractor Document Approval
Documents identified in the DDM for contractor approval shall follow requirements below:
 Document approval shall follow contractor auditable internal process. Where technical
approval capability is not in-house with the contractor, they could request PDO support.
 The native AFC/APP documents/drawings shall be issued in ASSAI to PDO as IFI,
attaching relevant records that demonstrate designated and adequate review/approval.
2.8.3. Approved Documents in Hardcopy
When a document is identified to exist (or be used) in hardcopy, it shall first be approved
electronically in the document management system before printing. Party producing the print
shall stamp “CONTROLLED HARDCOPY” with wet sign on the stamp or print with watermark
(with e.g. date and time, purpose of print, who printed, etc) on all printed document to confirm
source and validity of print. When new revision of document existing in hardcopy is issued,
the hardcopy custodian shall replace existing hardcopy at all the places where they are
located.
Hardcopy drawings shall not be accepted by PDO, unless the applicable boxes on the
revision history have been completed by the Contractor and signed by the applicable
Technical Authority.
2.9. Documents Reviewed/Approved in 3D Model
Document types generated, reviewed and approved as part of 3D Model review/approval
process shall not be subjected to another round of review/approval in Assai. The 3D model
review/clash check report shall be generated, assigned PLIP doctype “AA7403 Design
Review Report” and issued in Assai to confirm review/approval outcome. Approved
deliverables shall be issued AFC and IFI in ASSAI accordingly, along with link to the location
of 3D model review/clash report.
However, the DDM records for these doctypes that would be generated from the 3D model
shall be indicated as “PDMS” instead of IFR/IFI/IFA indicating that the doctypes was
reviewed as part of 3D model review/approval process. The remark of drawing/document title
box for these documents/drawings shall indicate "PDMS Reviewed".
Final handover of drawings/documents shall be generated from 3D model system in text
searchable pdf, and delivered as part of the final information handover deliverables to AIC.
The seed file of the 3D model shall be updated directly each time the asset is modified.
Effective: Jun-18
2.10. Demolition Works

When project scopes involve demolition of all or a part of the facility, contractor shall follow
the requirements below:
 Identify all the deliverables and data systems affected by the demolition work and
highlight in DDR; notify IM Delivery team. Obtain existing information deliverables from
AIC and follow requirements of this specification.
 Create a rendition of this master As-Built file for the project (one for construction and one
for demolition), with the same reference number
 Append 9 to the sheet number of the demolition drawings and retain same sheet
number for the construction drawings, see illustration below:
Demolition Drawing LNG-25-104259-PX-2365-00001-9001
Construction Drawing LNG-25-104259-PX-2365-00001-0001
 Documents/drawings affected by demolition works as a result of modification activity
shall be returned to AIC with their original reference number:
Construction Drawing LNG-25-104259-PX-2365-00001-0001
 For a partial demolition, the affected IM deliverables shall be archived in the IM system
and the status changed to “CAN”, while the remaining deliverables shall be As-Built and
delivered as part of IM handover.
 For complete demolition work, the affected IM deliverables shall be archived in IM
system and status changed to “CAN”. In both cases the handover csv file shall clearly
indicate these IM documents impacted by demolition work, refer to PR-1666 for
demolition procedure.
2.11. Document with Hold Point
When a document is with Hold point, it would not be finalised (AFC or As-Built) until the Hold
is removed. The status of the documents with Hold shall be updated to ADH in the master
DDR. A Hold register should not be maintained separate from the DDR so that the true status
of these deliverables (hold/no-hold) would be determined and the removal of these Hold
points at the end of project will be seamless.
2.12. Cancelled and Superseded Documents

2.12.1. Cancelled Documents
Documents are cancelled as a result of demolition works or project decision not to progress
with development of a document. Originator/Responsible Engineer shall notify DCC of
intention to discontinue a document with reason, and DCC shall cancel document in
document management system with status “CAN”, and clearly inserting watermark stamp
“CANCELLED” before issuing for information in ASSAI to all stakeholders. The responsible
engineer shall distribute the weight of canceled document in the planning system so that the
overall completion percentage would be consistent. When the cancellation was initiated from
a contractor or vendor, the party shall notify the project team with reason for cancellation.
Stamping of a drawing/document as cancelled is preferred to overlaying it electronically
because such overlays can be lost on placement into the EDMS. Stamped front sheets and
Effective: Jun-18
drawing blocks shall be scanned to sit in front of the cancelled document/drawing and the
status shall change to “CAN” in ASSAI. Cancelled document numbers shall on no account be
re-allocated to newly created documentation.
2.12.2. Superseded Documents
Documents are superseded when document metadata is updated (e.g. change of doctype,
etc), and when a document is replaced with a new document. The document status is
changed to SUP, and for the second case the party superseding shall clearly identify on the
document and in the document control system, which document it has been superseded with.
2.13. Suspended Project
When a project is placed on hold, the PDO Project Engineer shall recall and freeze all the
AFC documents/drawings (electronic and hardcopy) for the Project. The Contractor shall
ensure that the status of all project documents/drawings produced, including vendor
documentation is updated in the CSV load file as “SUS” and forwarded to the IM Lead. The
IM Lead shall retain these documents in the project document management system with the
status “SUS”.
2.14. Construction Work Packs
The design Contractor (if different), shall prepare and agree the construction Work packs with
PDO Project Engineer and deliver to the construction Contractor. Copy of the transmittal
shall be delivered to PDO IM Delivery Lead
Unless stated differently in contract, at the end of construction, the construction contractor
shall generate and deliver the final RLMU drawings to design contractor to produce As-Built.
2.15. Design and Construction Changes
Follow PR-1247: Project Management of Change for design and construction change
management. Once design change is approved the drawings/documents shall be updated
and issued, and the latest revision shall sent to site.
The contractor shall maintain proper documentation of construction changes. Markups
generated as a result of different construction activities on same drawing shall be collated to
produce the master RLMU.
2.16. Red-Line Mark-Up (RLMU)
RLMU is generated: by the asset operation team when reference master document/drawing
does not reflect physical installation and as a result of project delivery of new asset or
modification of existing asset.
2.16.1. Project Delivery RLMU
After commissioning, the construction contractor accumulates all changes and prepares the
master “red line” mark-ups, which shall be checked and authorized by contractor.
The construction contractor shall obtain signatures from designated CSR and commissioning
engineer/team. The RLMU produced for different systems, etc, contained on same drawing
shall be assembled into one Master RLMU under one document number
The Contractor shall produce 2 (two) hardcopies of signed final red-line mark-up drawings,
make a clean scanned copy and distribute as follows:
Effective: Jun-18
 Original red-line mark-up to remain in field, with station control room

 One hardcopy issued to the CSR and commissioning Engineer/Team
 One hardcopy issued to the design Contractor to commence As-Building
Any further changes made during commissioning/start-up and initial operation of facility shall
be noted in an updated RLMU and delivered to the design contractor for As-Building.
2.16.2. Multiple Projects RLMU
 If RLMU generated from 3 different project on the same drawing is available at the
station, these drawings shall be stapled together and inserted in the drawing folder
accordingly
 Where any of the projects delivers ASB, the field OXO16X shall “replace” that drawing
(out of the 3 stapled) in which ASB has arrived, staple them back and place in drawing
folder.
 As-Built of the next project shall utilize the latest master, until the 3 projects are ASB.
RLMU from FCP changes implementation shall be authorized by Asset/Cluster
commissioning engineer to indicates agreement
2.16.3. As-Built Integrity RLMU
When RLMU is generated by the asset operation team where master document/drawing
does not reflect physical installation, the following requirement shall be followed:
 Where discrepancy is observed on reference master drawing/document retrieved from
IM Portal for operation/maintenance activities, a RLMU shall be generated and issued to
UOI2 team for update via “As-Built Integrity Management System”
 Updated ASB as a result of RLMU shall be published and OXO16X shall “replace” in
field.
2.17. Final Information Deliverables Handover
Retention of information shall be consistent with requirement of CP-102 and PR-1692
Refer updated DDR and VDS for IM deliverables to be delivered at the end of engineering
project, SP-1131 for MRB delivery requirement and SP-2122 section 5 for handover and
assurance requirement.
The Contractor shall progress and update the AFC package with changes and red-line mark-
up received at the end of construction, commissioning and start-up
Project revision shall be removed from documents/drawings and master revision created or
increased by 1 for existing documents. Master revision of AFC drawings that did not change
after commissioning shall also step up by 1 and status changed to As-Built (No-Change) or
Certified Final Document (CFD)
Refer to PR-1666: Document, Drawing and Data Control Procedure for detailed information
development and modification requirement and SP-2195 Project Initiation and Close-out for
electronic and Tier hardcopy deliverables closeout for engineering projects.
Drawings and documents delivered at handover are managed and stored electronically in
AIC E&O IM Portal, and become uncontrolled when printed.
Effective: Jun-18
2.17.1. Master Controlled Hardcopy

One master controlled hardcopy of Tier1 Critical documents shall be delivered to the field by
UOI2, and maintained at the central Control Room to support facility Operating Integrity.
Additional hardcopy of documents/drawings required to support field operation shall be
printed by the OI Field Coordinator with watermark (e.g. date and time, purpose of print, who
printed, etc), or stamped “Controlled Hardcopy” and signed to confirm source and validity of
print.
2.17.2. Design Document Handover
The design document handover package (drawings, documents, EDS deliverables, etc) shall
be delivered in both native format and pdf (native file rendition and content/text searchable as
opposed to a scanned pdf) at the following stages of project development:
 End of FEED (all design deliverables including the EDS deliverables)
 End of Detailed Design – (All AFC drawings/documents without hold; and all
approved/ Certified Final (APP/CFD) revision of documents not requiring As-Building).
 As-Built (drawings and approved revision of documents not requiring As-Building).
Document types held in EDS system, that are identified in DDR for handover shall be
extracted in pdf and delivered to AIC with confirmation of EDS seed file delivery to the EDS
team.
2.17.3. Vendor Document Handover

All documentation listed in the VDS shall be produced, collated and authorized prior to the
submission as the MRBs. The MRB deliverables shall be submitted in both native and pdf
made from the rendition of native file (as opposed to pdf made from scanning), and also in
hardcopy of sizes listed in section 2.6. But where deliverables does not exist in native format,
a scanned and legible version of deliverables shall be produced. The MRB shall have a hard
cover and come with a 4-hole pillar ‘post-lock’ mechanism. Documentation should be double-
sided where practical. They should have a clear plastic envelop at the front into which a front
sheet should be inserted, a similar sheet should exist on the spine.
Each section of the MRB shall be labeled with a section title, volume number within section,
and book number within volume. If a document within a volume is so large that additional
binders are required, the additional binders shall carry the same volume number with
additional book numbers to indicate sequence i.e. Volume 1 Book 1, Volume 1 Book 2. The
maximum depth of paper in any binder shall be 40 mm. The Maximum binder depth size shall
be 50 mm (Inner dimension of retaining rings)
Each manual shall have a minimum of 8mm (1/4”) spare capacity to allow for supplementary
documentation to be added at a later date if required. It is advised that the Vendor submits
one hard copy data book for review, before producing for final handover.
Documents marked “With Bid” or “For Review” shall be submitted electronically in pdf format.
Documents marked “As-Built” or “In Record Book” shall be assembled into MRB
electronically in pdf and native file format, following the content structure of SP-1131
appendix 2 with signed or authorization page neatly inserted. The Vendor shall ensure that
prior to IM deliverables submission to Contractor/PDO, that sub-vendor’s documentation is
Effective: Jun-18
contractually and grammatically correct. For those activities provided by a sub-vendor, the
sub-vendor contact data shall be clearly documented and included in the MRB.
MRB delivery scope shall be as contained in the equipment list of appendix 15.
2.18. Check-out and Check-in Requirements
Master Deliverables are checked-out from AIC only for As-Building (not for project duration).
The contractor is required to transfer the content of the project drawings/RLMUs on to the
master and return back to AIC within the checkout timeline of 25 days for EMC/ODC, Well
Completion, Integrity and FCP projects. After this period, the check-out activity is cancelled to
make deliverable available for another project.
The contractor handover will not be accepted by PDO and they will be required to check-out
the master again. Contractor can obtain approval from the Project IM Lead to extend check-
out timeline for some deliverables that could not be delivered within the standard timeline.
2.19. Correspondence Numbering and Control
Formal Correspondence relates to any communication medium containing project
management communication or business information that may be retained for project close-
out, legal, operational, fiscal or other critical business purposes. It is the intention that formal
correspondence shall be managed through PROCON Contract Management System but
where official dispensation has been obtained for PROCON not to be used on a project, and
then each correspondence will be produced containing the following minimum attribute:
o Unique number (showing sender/receiver) in the upper left corner
o the author of the correspondence
o recipients
o if reply is expected and expected reply date
o email address of the originating party
o Maintain Project Correspondence Control Registers, (Incoming / Outgoing)
o Signed original shall be delivered via surface mail to the current address of project
DCC (to be advised separately)
o Maintain hardcopy master files of all correspondence received (clearly stamped
with date-received).
o Expedite all indicated responses for correspondence received and issue
Correspondence Status Reports
Originator of any outgoing correspondence shall be responsible for ensuring that:
 It is processed through the Document Control Center.
 The content of the correspondence is contractually and grammatically correct
Where electronic mail is used to provide instruction to Contractor or Supplier, it shall be
followed-up with a formal writing using minutes of meeting or formal correspondence as
appropriate, and registered in DCC. Until this is done, the instruction shall not be binding.
Such confirmation shall be forwarded within five (5) working days.
2.19.1. Document Exchange in FEED Office
FEED Office is the PDO design team that provides design services for project team (Asset
team and CPD), and often provide document review and approval support on behalf of
Effective: Jun-18
project team when designated. For a project to be executed in FEED Office, the authorized
project IM Plan shall show clearly the document review and approval strategy for project (if
FEED Office will review (IDC/IFR)/approve on behalf of project team or project team (IFR) by
themselves).
Internal document review cycle in FEED Office shall be completed as part of IDC. For
documents that require project team review/approval, the IDC shall be completed before the
document is circulated for review/approval. Where FEED Office is designated to review/
approve on behalf of the project team, IDC/IFR could be combined as part of revision 1.
2.20. Quality Management
Follow the assurance requirements as contained in SP-2122. The Contractor shall confirm
understanding of contract IM scope of work in line with GU-691: Engineering Information
Quality Management Framework.
The Document Controller will ensure that the correct template, document number, revision
status and title are on a document prior to issue or distribution, and will facilitate the timely
document review turnaround.
The responsible Engineer shall ensure that document is developed using the correct
template and that all meta-data are populated on the document.
Effective: Jun-18
3. DOCUMENT NUMBERING STRUCTURE

The following document numbering taxonomy and standard requirement shall be followed to
assign document number to documents generated in project.
3.1. Document Taxonomy
The format of document numbering is shown below:
Process Unit Originator Code Discipline Sequential
Area Code Document Type Sheet No.
Code Code No.
Design: Numeric (4)
Alpha (3) Numeric (2) Alpha/Numeric (6-10) Alpha (2) Numeric (5) Numeric (4)
Vendor: Alpha Numeric (3)
Design: CCCCCC
AAA BB (numeric) DD EEEE GGGGG HHHH
Vendor: CCCCCCCCCC
 Area Code: As defined in Corporate ERP System (SAP FLOC Level 5 Location code).
This code will be derived in line with SP-2152 section 2.3 and supplied by the Asset
Information Centre (AIC) via the “IM Kickoff Form”, see Appendix 2.
 Process (system) Unit Code: As contained in SP-2152: Specification for Tagging and
FLOC Level 5 appendix II. For drawing/document cutting across the whole facility (e.g.
Overall Plot Plan, Operation HSE Case), or drawing of an area in which an equipment
was not installed, the code shall be “00”.
 Originator Code: A 6-10 character code assigned to identify the party generating the
document in relation to the overall project. Every activity undertaken by a contractor or
vendor is governed by the provisions of the contract or purchase order (PO). The contract
and PO number allocated shall be used as originator code for “design” & “vendor” IM
deliverables respectively, to identify and relate a piece of equipment IM deliverable to a
particular project/asset. The code shall apply as follows:
 Even when the same vendor is delivering service to more than one project, the PO
number assigned for each procurement activity would be different. During operation,
each piece of equipment would be associated to the project that delivered it (not
vendor) using the unique PO number.
 When a vendor is engaged directly by PDO, to procure equipment and the equipment
would be allocated to a known ongoing project (e.g. in EMC project), the “originator
code” shall be the 6-10 character contract number of party receiving the equipment for
installation (allottee).
 When a vendor is engaged directly by PDO, to procure equipment and the equipment
would be allocated to a not-yet-known project (e.g. in EMC project), the “originator
code” shall be the 6-10 character PO number issued by PDO to the vendor. As
defined in Corporate ERP System (SAP) for existing organizations/entities registered
as vendors (i.e. SAP vendor list).
 When PDO engage an EPC or EP&C contractor, and the scope includes procurement
of one or more equipment, then the “originator code” for both the design and vendor
deliverables shall be the PDO contract number with the main Contractor. This code
shall be 6 character for design IM deliverables, and 6-10 character (the 6 character
Effective: Jun-18
main contract code + up to 4 character contractor specific code) for vendor IM

deliverables. Note that if the main contractor assigns an internally generated PO
number (as part of their internal procurement process), the “originator code” that shall
be used for numbering shall remain the 6-10 character as described in the previous
statement and not the internal PO number.
 When the document is generated internally by project team, the code is “000000”
 When the document is generated by PDO FEED office, (AFD, AFC and As-Built), the
code “PDFEED” shall be used. However where detailed design is done by a different
contractor, PDFEED shall be updated with detailed design contractor for all new
documents/drawings) generated from project.
 When modifying existing master documents (FEED Office/Contractor) that already
have an originator code, the existing originator code shall be retained.
 Discipline Code: Refers to the technical discipline code to which the document is
related, refer to SP-1131 (PLIP). There are two kinds of discipline code: for design
deliverables and for vendor deliverables:
 The vendor discipline code is “ZV”, used to identify all information deliverables
associated with the manufacturing/procurement of equipment package.
 Design deliverables code, which has different code for each discipline (IN, EA, PX,
etc), see SP-1131. Vendor shall not assign a vendor code to a design deliverable
received (e.g. design PEFS) for review or update unless they created it exclusively for
that equipment.
 Construction deliverables shall be assigned BA - Construction discipline (not ZV -
Vendor), even when the construction contractor was mobilized by the main contractor.
The ZV - discipline code are explicitly used for IM deliverables associated with the
manufacturing and procurement of equipment.
 Document Type: A standard 4-character numeric code denoting the type of design
document based on content, and 3 alpha numeric characters denoting vendor
deliverables. This is the main classification code for deliverables, and is based on the
standard list of allowable document types in PLIP and VDRL.
 Sequential Number: A five digit numeric field starting from 00001, denoting one unique
document in that discipline and document type pattern; however where there are many of
the same document type pattern produced during the life of Project, the next will take
00002, etc.
 Sheet Number: 4-digit number identifying the number of sheets applicable to that
drawing number. It shall start with 0001, and documents with a front sheet shall have
“0000”.
Single sheet documents (e.g. General Arrangement Drawings, Detail drawings,
Schematics, Data Sheets, etc.) shall always be designated as ‘Sheet 0001’. Where
additional information is continued on to subsequent sheets, those sheets shall be
numbered as Sheet 0002, 0003 etc. In this situation the drawing title block shall clearly
identify the sheet number as part of a set (e.g. Sheet 1 of 2).
Effective: Jun-18
For clarification, a sheet is a separate electronic file. Multiple pages could exist within a
single file (such as a line list) and should be noted as pages, not sheets. For the purpose
of project execution activities, dispensation may be applied for the use of document
grouping to facilitate effective document review and approval. However during final
submission, these grouped documents shall be split back to single sheet before delivery
to PDO.
3.2. Issue and Status Code
Review and approval of a project document is a very important aspect of delivering an
engineering project to the right quality. Typically an engineering project document will go
through several reviews and changes by multiple parties until it attains final approval status.
As such, a transparent and systematic method that indicates the status of the content of the
document at any point in time during the document flow is essential.
“Issue” codes (transmittal code) are those codes that are used to identify the purpose for
which a document is issued while “status” codes are used to identify the current state of the
document in the development chain. The following table illustrates how “status” codes are to
be applied in engineering projects:
Master As-Built Drawing Development

Illustrating with a document development during FEED
Rev Title Issue Code Status Code Review Return
Code
01 (first issue) Process Engineering Flow Scheme (PEFS) IFR IFR B
02 Process Engineering Flow Scheme (PEFS) IFA IFR A
03 Process Engineering Flow Scheme (PEFS) IFI AFD
Illustrating the same document development during Detailed Design (DD Returned Code B)
03 Process Engineering Flow Scheme (PEFS) IFR/(IDC/IFR) AFD B
04 Process Engineering Flow Scheme (PEFS) IFA IFR A
05 Process Engineering Flow Scheme (PEFS) IFI AFC
Illustrating the same document development during Detailed Design (DD Returned Code C)
03 Process Engineering Flow Scheme (PEFS) IFR/(IDC/IFR) AFD C
Project revision stops here; new
04 Process Engineering Flow Scheme (PEFS) IFI AFC master revision is created by x+1
Illustrating with the same document development during As-Built Handover
Master Rev created (Rev 01 for
0X Process Engineering Flow Scheme (PEFS) IFI ASB new and x + 1 for existing)
Master As-Built Drawing Modification or Verification

Retrieve AIC master document for ARV Desktop Verification Retagging
Rev Title Issue Code Status Code
0X Process Engineering Flow Scheme (PEFS) IRT ASB
0X+1 Process Engineering Flow Scheme (PEFS) IFI ART
Retrieve AIC master document for OI SG4 Verification
0X Process Engineering Flow Scheme (PEFS) IFV ASB
IM Portal shows status RLM for out of
0X Process Engineering Flow Scheme (PEFS) RLM date As-Built that have field RLMU
When the RLMU is updated and
0X+1 Process Engineering Flow Scheme (PEFS) IFI ASB returned published in IM Portal
Illustrating during Demolition Works

01 Plot Plan IFX ASB/AFC A
02 Plot Plan IFI AFX
Please follow Appendix 5 for the list of document codes descriptions.
Effective: Jun-18
3.3. Revision Convention and Control

Revision and version codes are complementary codes assigned to documents to further
indicate current status. A revision indicates a formal stage in the review and approval
process while a version indicates an informal stage used basically to capture intermediate
updates of working documents between formally issued revisions.
The revision code shall be a 2-digit number representing the number of times that the
document has been formally issued. First issue of a document shall be 01 while subsequent
revisions shall be 02, 03 etc.
As indicated in appendix 14, the project and master drawing/document revision are different.
During project, the revision sequence will continue to increment from 01 to 02, to 03, etc, but
during As-Building the project revision is removed from drawing/document and master
revision is increased by 1.
3.3.1.Review Return Codes
The final point in the document review cycle is confirmed by the assignment of a Return
Code. This is done by the Responsible Engineer after comments from respective reviewing
parties have been received. The following Return Codes shall apply:
Deliverables Return Codes

Code A Final: No Comment, document accepted. Do not re-submit except modified.
Code B Revise and Re-issue: Returned with comment, incorporate comments and issue
for approval. Work may proceed.
Code C Minor Comment: Incorporate comments and proceed with work.
Code D Rejected: Incorporate comments and re-issue, work may NOT proceed. New
document may be required.
Deliverables Return Codes Explanation
Code A Deliverables Returned with Code A from PDO is Approved. Update status of
document to AFD/AFC and issue IFI to PDO. Responsible engineer to ensure
alignment with PDO and get their input (during IFR) so that comment will not be
issued after approval.
Code B Technical comment was provided which changed or adjusted the design.
Originator shall ensure that comments are incorporated or resolved such that it
will receive Code A from the next issue IFA.
Code C Deliverables Returned with Code C from PDO is accepted with minor comment
(typo, grammar, symbols, tag format, metadata update, labeling, etc). Incorporate
comment and update status of document to AFD/AFC and issue IFI to PDO.
Responsible engineer to ensure alignment with PDO and get their input (during
IFR) so that technical comments will not be issued from PDO after approval.
Code D Incorporate comments and re-issue deliverable IFR
3.4. Renumbering of “Old System” Documents

Documents with old numbering system shall be re-numbered at the next update opportunity,
to align with this specification. However to facilitate cross references to older drawings, the
two numbers (old and new) will be displayed in the main title block of document/drawing, with
the old number shown in a separate but prominent position. With the exception of the
Effective: Jun-18
sequence number, which shall be the ORIGINAL sequence number prefaced by 9, the new
number shall be formed by using the taxonomy in this specification. The Originator code is
“000000” and it is constant for all re-numbered document.
HWL-1-4503-008-A
Area Unit/Plant Originator Discipline Document Sequential Sheet Revision

Code Code Code Code Type No. No.
HWL BB 000000 PX EEEE 94503 0008 01
3.5. Vendor Documents Numbering

Numbering of vendor document shall be consistent with the requirement of this document.
Vendor might implement their own numbering system as it suits their internal control and
system but the PDO numbering requirement shall be the main number to be used for all
references and other purposes concerning the Contract scope. Discipline code for all vendor
deliverables shall be “ZV” while document type shall be the VDRL code; refer to Appendix 3.
Each deliverable item created for equipment shall have a unique number; this number shall
be used for all references and purposes regarding the deliverable item.
Document numbers shall remain unique to the original document to which they are applied
once allocated. In the event of a document being cancelled or superseded the document
shall be clearly marked as such on the VDS. Superseded or cancelled document numbers
shall on no account be re-allocated to newly created documentation.
3.6. Project ID and Project Code Administration
The Project ID is a 12-15 character code generated from the “RAMZ” system (SP-2195), and
assigned to a project to identify the project (and sub project) from Assess/Select phase until
Operate phase. As part of project initiation, the Project ID generated shall be appended on
the IM Kickoff form (appendix 2) by the IM Lead before submitting to AIC to request for
existing Asset information or Tag numbers, etc be issued to support project.
The project ID shall be used as follows:
 The existing project and package code system will continue to be used for all projects
that have the code already assigned, but the project description field in ASSAI shall be
updated with the RAMZ generated project ID.
 For new projects, the existing project code field in ASSAI will now be populated with
RAMZ Project ID, replacing the project code and package code (being phased out).
 AIC shall utilize the project ID to allocate requested information in the same way
project code was used
 Project team shall utilize the PDO standard document/drawing template (with
provision for project ID), and append the project ID to document/drawing generated or
updated during project.
 The project ID shall be used for subsequent project document management activities.
 Contractor shall remove the project ID from the document/drawing no before final
handover to PDO.
Effective: Jun-18
4. DOCUMENT EXCHANGE
The following sections defines requirement that ensures that all Engineering Project
documentation sent to PDO is received and returned via formal exchange channels and to
standard and formats that have been agreed between the Project and its contracting
partners. Failure to agree upon a standard approach for the receipt and return of deliverable
will lead to unnecessary delay and possible financial loss among all parties working on the
Project.
4.1. Collaboration Media
PDO maintain a sharing and collaboration area on Livelink extranet site for the purposes of
sending and receiving formally transmitted documentation with external parties. All
documents sent to the project team should be forwarded via this medium. A detailed folder
structure will be set up and agreed with each external party with required access permissions
in place.
Documents sent by the first party should be removed and stored in an appropriate location
once received by the other party. Documentation sent via any other communication medium
will not be accepted unless prior approval has been sought and granted by the project team.
4.2. Exchange of Documents
During the project, all exchange of documentation between PDO and external partner shall
be through the DCC. Internal documents issued within project team shall be under the cover
of an ASSAI internal transmittal. Internal document distribution shall be according to the
distribution matrix. Originator or responsible engineer shall issue an email to DCC requesting
a document to be issued. External documents issued to or from the project team for the
purposes of review, approval or information should be placed on the FTP or Livelink extranet
site under the cover of a transmittal. An E-mail notification should be sent to relevant DCC
personnel notifying them about the placement.
4.2.1. Document Transmittal
Both internal and external transmittals shall contain the following information as a minimum:
 Unique Transmittal Number
 Purpose for Issue
 Transmittal Date
 Expected due date for (return of comments)
 Project Document Number
 Document Title
 Revision Code
 Revision Date
 Document Status Code
 Sender: Address, telephone, fax and e-mail details
 Name of Sender
 Purchase Order or Contract Number (For Vendor or Contractor)
Effective: Jun-18
4.2.2. CSV Files

Contractor shall submit a CSV file with every document submittal, or where document
planning is in place, as a file containing all projected document issues with associated
planned, and actual dates. The CSV file will be used to load document Meta data into the
project document control system. This will save time on manual input and therefore speed up
document processing time. The recommended template for the CSV file is inserted below;
note that the order of data column, should not to be changed. Any subsequent changes to
the document schedule will require submission of updated CSV file for loading purposes
CSV Template.xls
Effective: Jun-18
5. ROLES AND RESPONSIBILITIES

ASSAI ASSAI is a PDO standard tool that provides a Document Control
solution during the project. It is composed of:
 ASSAI PDC - A module used by the DCC Team to create
document numbers, load and distribute documents
 ASSAI Web - A module used by project team to find, access,
review, comment and approve documents.
Document Controller The DCC shall also be responsible for:
 Managing and maintaining the ASSAI/LL set-up, including
user lists and distribution matrices
 Registration of all document in ASSAI and timely distribution
to relevant team members
 Responsible for ensuring that all documentation is correctly
numbered as per the requirements laid out in this specification
 Ensure that comments received outside ASSAI are
delivered/issued to originator
 Ensuring that documentation from Contractors meet this
specification
 Providing support to team members on the document control
system and processes
 Producing relevant reports for Project Management
Contractor(s)  Ensures that information to be delivered to PDO complies with
this specification, and other IM standard for quality
 Ensure that sub-contractors and vendors comply with the
provisions of this specification.
 Where in doubt, the contractor should seek guidance from
Project IM Delivery Lead
Document Originator Individual who either writes a document or creates it by collating the
various inputs from other project team members.
Originator is also responsible for:
 Obtaining a document number from DCC for the document being
produced
 Ensuring that all documentation is correctly numbered as per the
requirements laid out in the relevant sections of this document
 Ensuring documents are produced using the correct project
template.
 Delivering documentation to project DCC by means and formats
as described in this specification in a timely manner to avoid
unnecessary delay to project schedule
 Scan mark-up hardcopy drawing or electronic (tracked comment)
copy of the document and load into ASSAI.
Effective: Jun-18
 Advise distribution list for each document and closeout date for
document review cycle if different from standard.
 Collates, clarify and incorporates review comments. This
includes resolving conflicting opinions and feedback between
reviewers.
 Provides confidentiality requirements (Unclassified, Restricted,
Confidential, Most Confidential) to DCC
 Ensuring that documents are approved to the correct level of
discipline TA prior to issue to the project DCC for distribution.
Document Owner He/She owns document content, responsible for the completion and
(ATA) execution of the document, and ultimately responsible for the
document quality in terms of business relevance and audit ability.
Document Custodian Accountable person in the business area where the document is
applied. In project this role is the PM (or delegate).
Approver or Technical Relevant person identified on the distribution matrix or PCAP to
Authority(TA) approve a document.
In line with section 2.3.1, authorize discipline document that are not
impacted by project scope.
Responsible Engineer  Discipline focal person assigned to provide review input or
support the delivery of discipline scope of the project, package
and equipment.
 He/she reviews DDR, and document schedule from external
parties, and validate the documents that must be submitted “for
discipline review and approval” or “for information”.
 Provides discipline input as part of DDM development
 Ensures that document received for comments are processed
and returned to contractor/vendor within a specified timeframe,
and ultimately delivers the document or work package.
 Delegation of this role shall be officially communicated.
Project Engineer  Ensure that existing documents impacted by project scope are
(Construction Site evaluated for impact in line with section 2.3.1
Representative)  Ensure that information deliverables are duly generated and
delivered in time to support PSUA, commissioning and start-up.
 Ensure that all changes made during the construction phase are
MoC controlled, and that mark-up on the related documents are
returned to Document Originator for As-Building.
Effective: Jun-18
Asset Information UOI2 team where Master Information: As-Built drawings, EDS
Center (AIC) System files and other CFD documents are centrally located and
managed. Other functions of AIC shall include, but not be limited to:
 Receive final handover IM deliverables (design and vendor)
electronically from project as part of structured and scheduled
handover, sign PCC and load in the IM system.
 Issue publish notification to all stakeholders requesting them to
“Replace” any copy in their custody
 Ensure that users have adequate access to view latest
Information in IM Portal
 Issue support information as requested on the IM Kickoff Form:
Master Information required for any Brownfield modification or
asset expansion, Tag number allocation, etc.
 Ensure that current status and true position of information is
clearly indicated in IM systems
 Manage this Information throughout Asset Operations Lifecycle
Sustainability IM Team  Receive the publish notification from AIC and follow-up with OI
Field Coordinator to supersede controlled hardcopy in the
station.
 Process Controlled Hardcopy of Tier 1 Critical Documents and
deliver to the field
 Monitor field IM performance and report compliance against
agreed KPIs
Project IM Delivery  Ensure adequate compliance to the requirement of this
Lead specification
 Ensures that Information to be delivered to AIC is in compliance
with approved IM standard for quality
 Manage the Document Control Center and the Document
Controller
Archive Management Maintains the Projects Documentations in the archive for the
specified retention life of the document
Reviewers Reviews documents and provide comments to the originator or
responsible engineer within the review window.
Document Templates Appendix 9 for document templates for use by the Contractors.
Effective: Jun-18
6. APPENDIXES
6.1. Appendix 1 – User Feedback Form
6.2. Appendix 2 – IM Kickoff Form
6.3. Appendix 3 – Blank VDRL and Equipment List and Customized VDRL
6.4. Appendix 4 – Information Requirement scope for MR/PO
6.5. Appendix 5 - Document Status Code Descriptions
6.6. Appendix 6 – Vendor MRB Document Cover Sheet
6.7. Appendix 7 - Vendor Document Schedule (VDS) Blank template
6.8. Appendix 8 - Vendor Document Requirement Catalogue (VDRC)
6.9. Appendix 9 – Document Templates: Excel, Word and Drawing
6.10. Appendix 10 – Comment Resolution Sheet (CRS)
6.11. Appendix 11 – Vendor Document Requirement Matrix (VDDM)
6.12. Appendix 12 – Document Distribution Matrix
6.13. Appendix 13 – Document Deliverables Register
6.14. Appendix 14 – Master Document/Drawing Revision Conversion
6.15. Appendix 15 - Equipment List and Vendor MRB Delivery

SP-2065 Technical Data Management

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SP-2065 Technical Data Management

Uploaded by

Copyright:

Available Formats

Petroleum Development Oman L.L.C.

Document Management in Engineering and Operations

Document Type Specification

Discipline Technical Data Management

Engineering and Operations Information

Issue Date June 2018

Revision Apr-11 Mike Turberville UEP/1 6. Updated numbering requirements

FR-01 PDO Control Framework (FR-01)

External Document: DEP 82.00.10.30-Gen: Engineering Information Specification (EIS) -

6.2. Appendix 2 – IM Kickoff Form ...................................................................................... 38

1.4. Review and Improvement

1.5. Step-out Approval

ODC etc project, or operation or maintenance of a facility

ASSAI/Livelink Refers to a combination of ASSAI and Livelink to provide a system of

2.2. Project Initiation

2.5. Vendor Information Planning

PDO information scope is grouped into: Engineered/Specified Equipment, Standard

2.5.2. Vendor Document Requirements Listing (VDRL)

2.5.3. Vendor Document Schedule (VDS)

2.5.4. Vendor Document Deliverables Matrix (VDDM)

2.6.3. Document Title - Guideline

 In the event implementation of the comments results in substantial modifications to

 Documents returned with “Code A” or “Code C” is “Approved” and shall be progressed to

2.10. Demolition Works

2.12. Cancelled and Superseded Documents

 Original red-line mark-up to remain in field, with station control room

2.17.1. Master Controlled Hardcopy

2.17.3. Vendor Document Handover

3. DOCUMENT NUMBERING STRUCTURE

main contract code + up to 4 character contractor specific code) for vendor IM

Master As-Built Drawing Development

Master As-Built Drawing Modification or Verification

Illustrating during Demolition Works

3.3. Revision Convention and Control

Deliverables Return Codes

3.4. Renumbering of “Old System” Documents

Area Unit/Plant Originator Discipline Document Sequential Sheet Revision

3.5. Vendor Documents Numbering

4.2.2. CSV Files

5. ROLES AND RESPONSIBILITIES

You might also like