Petroleum Development Oman L.L.C.

UNRESTRICTED Document ID : SP-1122

February 2000 Filing key : ???

Specification for Design QA Plans

Keywords: Project Engineering, Design, QA plans, TA System

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.
Specification for Design QA Plans Version 1.0

Authorised For Issue 15/02/2000

Signed: ……………………………………………………………
Graham Henley – CFDH Project Engineering

The following is a brief summary of the most recent revisions to this document. Details of all
revisions prior to these are held on file by the issuing department (OTE/2).

Version No. Date Author Scope / Remarks

Version 1.0 Jan’00 Harald Traa, OTE/2 First Issue of Design QA Plan Specification

09/23/22 Page i SP-1122

Specification for Design QA Plans Version 1.0

Contents

1. Introduction...........................................................................................................................1
1.1 Background.......................................................................................................................1
1.2 Purpose..............................................................................................................................1
1.3 Distribution/Target Audience...........................................................................................1

2. Specification for Design QA Plans......................................................................................2

2.1 Scope.................................................................................................................................2
2.2 Criticality of Deliverables.................................................................................................2
2.3 Verification of Deliverables..............................................................................................3
2.4 Process Flowchart.............................................................................................................6
2.5 Related Business control Documents...............................................................................7
2.6 Review and Improvement.................................................................................................7
2.7 Step-out and Approval......................................................................................................7

Appendix A Glossary of Terms, Definitions & Abbreviations.............................................8

Appendix B User Feedback Page.............................................................................................9

Appendix C Design Deliverables Verification Matrix.........................................................10

Appendix D Sample Design Deliverables Verification Matrix...........................................11

09/23/22 Page ii SP-1122

Specification for Design QA Plans Version 1.0

1. Introduction
1.1 Background

The engineering function in PDO operates a Technical Authorities (TA) system to ensure
that important documents and drawings are reviewed and approved by appropriately
qualified and experienced PDO engineers. This competence development and assurance
system is a key element in the management of PDO’s business risks including ‘inadequate
design, ‘late project’ and ‘budget over run’.

The TA system is based upon a combination of engineering discipline competencies

coupled with knowledge of PDO specific design processes and associated documentation.
This specification formally defines the relationship between specific deliverables from the
design process and links this to the TA system via a verification matrix (Appendix C). The
objective is to define the formal PDO approvals required for all engineering deliverables in
use by PDO and to set this out in a clear, transparent and auditable way.

This is a new Specification which has been developed to address the requirement to
develop a project specific design QA for all projects (Project Engineering CoP - CP-117).
It replaces ERD-00-02 (PDO Technical Authority System)

Responsibility for the technical content of this document rests with the CFDH for Project
Engineering.

1.2 Purpose

This document outlines all essential activities required to prepare a proper Design QA Plan
as required by the Project Engineering Code of Practice.

1.3 Distribution/Target Audience

The document is primarily targeted at the Project Engineer and the LDSCs/design
contractors who are responsible for preparing the Design QA plans but it also impact on
the wider engineering community within PDO, especially the CFDHs who will be required
to comment and approve critical deliverables from across the PDO project engineering
community.

The document will be distributed to all PDO project engineers, ETLs, CFDHs and the
LDSCs.

09/23/22 Page 1 SP-1122

Specification for Design QA Plans Version 1.0

2. Specification for Design QA Plans

2.1 Scope

The PDO Project Engineering CoP, CP-117, specifies that the PDO project engineer must
produce a project specific QA plan for each project. This project specific QA plan must list
all the deliverables produced by the design contractor (LDSC or other) under the project .
It must clearly identify which deliverables require PDO review/approval and the required
TA level of the approving PDO engineer to ensure the technical integrity of the design.

The Design Deliverables Verification Matrix is shown in Appendix C. This matrix

specifies the discipline TA approval required for each deliverable depending on the
criticality chosen. To facilitate the preparation of the QA plan the matrix has been
incorporated into an MS access Database which is available on the PDO network (Contact
OTE/213) and also as a stand alone version to the LDSCs. An example of a typical QA
plan is shown in Appendix D.

The PDO project Engineer is responsible for developing the initial QA plan as well as
monitoring compliance against it together with the PDO project engineer.

2.2 Criticality of Deliverables

The Project engineering CoP specifies that the standard level of PDO checking and
authorisation/approval for design deliverables produced by the design contractor will be set
according to the assigned criticality of the deliverables. A default criticality has been
assigned to each deliverable but this can be adjusted based on project specific
circumstances.

The following table gives some guidance on how to assign the appropriate criticality for
each deliverable.

Table 1: Deliverable Criticality Rating Guidelines

This table is not exhaustive and the process of assigning criticalities will to a large extent
depend on the engineering experience of both the PDO project engineer and the ETL.

The verification matrix in Appendix C also shows the range of criticality’s allowed for each
deliverable and defines the default criticality for each deliverable. The default criticality is
shown in ‘yellow’ whereas the ‘non-allowable criticalities’ are shown as ‘hatched’ areas.

09/23/22 Page 2 SP-1122

Specification for Design QA Plans Version 1.0

The default has generally been set at a level typical for that deliverables but this is meant
for guidance only and the PDO project engineer is free to change this if a different
criticality is considered more appropriate. The ‘non-allowable criticalities’ have been set to
a)safeguard a minimum level of verification for a given type of deliverable and b)limit he
verification for certain types of low impact deliverables. The default and allowable bands
were developed by the relevant discipline CFDH.

The reviewer will be requested to undertake different levels of review depending their
discipline and the type of deliverable under review. These actions are described in more
detail below together with their impact on the overall design process.

DELIVERABLE REVIEW LEVELS

I - Issued for Information

The deliverable should still be reviewed but few if any comments are expected from the
reviewer. Documents issued for Information have in many cases been issued to assist with
the review of other documents. The design process in the LDSC will not stop while the
review is ongoing.

 No Response = No comment

C - Issued for Comment

This is one step up the review ladder and the reviewer is expected to take the time to
thoroughly review the deliverable as per section 2.3. The design process will be on hold for
the comment period. Project engineer collates all the comments at the end and returns
them to the design contractor.

 No Response Within the comment Period = DESIGN PROCESS CONTINUES

A - Issued for Approval

This is the highest level of review reserved for high impact deliverables or those which
may result in financial commitment (e.g. requisitions, workscope etc.). At this level the
reviewer must take great care to ensure that the deliverable is indeed correct. Only one
person will actually approve a Deliverable and by signing it off the reviewer will be
accountable for the technical content of the deliverable. The design process will be on hold
until approval is granted. The PDO Project engineer collates all the comments and returns
them to the LDSC

 No approval = DESIGN STAYS ON HOLD

Approval by the PDO engineer does not remove the design consultant responsibility for the
preparation of a technically correct, fit for purpose design. Errors or omissions highlighted
subsequent to PDO approval must be corrected without escalation to the design cost. In the
event however, that the PDO engineer requests further optimisation of the design
subsequent to the approvals process this may, depending on the nature of the design
contract, result in a variation to the design cost.

2.3 Verification of Deliverables

The design contractor produces and verifies the deliverables according to its own ISO 9001
approved QA system before issuing to the PDO engineer. The deliverable(s) is then issued
to the PDO engineer who is responsible for obtaining the correct level of review and
approval in accordance with the approved Design QA plan. The PDO engineer has the
option of routing the deliverable(s) to the relevant PDO discipline engineer in series or
parallel. The design contractor shall include a approval signature box on the deliverable as

09/23/22 Page 3 SP-1122

Specification for Design QA Plans Version 1.0

per the design QA plan. Once the necessary approvals have been obtained the PDO
engineer returns the deliverable(s) back to the design contractor.

The following pointers are of particular importance during the PDO review process:

- Compliance with key drawings from earlier project phase (e.g. PEFS consistent with
PFS)
- Compliance with relevant PDO policy (e.g. Halon, flaring etc), procedures,
specifications and other standards. Has any variances been properly applied
for and documented
- Is the input data (e.g. process data) still valid
- Is there a lower cost, fit for purpose, alternative. Has it been considered.
- Can the design be constructed safely
- Have interfaces with other projects been taken into account
- Am I sure this will work
- Why has it been designed in such a way
- Operational issues such as sparing philosophy, maintenance access
- Commercial issues i.e. equipment standardisation, Total Cost of Ownership

The reviewer should ask these questions to both strengthen his/her knowledge of the project
and to uncover possible design errors and even more importantly to discover ‘best practice’
for lateral learning across PDO.
The comments made should always be of a constructive nature and the reviewer should
avoid making comments unless they can be justified based on:

- HSE
- Technical integrity
- Cost savings
- lack of compliance with policy, procedures etc
- Key interface issues
The reviewer is free to make suggestions on the design but it should be made clear to the
PDO project engineer what the reviewer considers mandatory requirements and what if any
are suggestions to be followed at the discretion of the PDO project engineer. The reviewer
should bear in mind that good suggestion made early in the design phase is much more like
to be followed than one made towards the end of the design phase.

Apart for ensuring the integrity of design process through proper application of PDO
standards, procedures and established work practice, the reviewer should also aim to add
value by focussing on ways to reduce the overall cost of the project through innovative use
of technology and by applying lateral learning across both PDO and the Shell Group as a
whole.

The PDO engineer will be presented by a wide range of deliverables issued at various
stages of the design cycle. It is important for the PDO engineer to realise the relative
impact of the comments made during each stage of the process.

DESIGN PROCESS

The PDO design process is explained in detail in the Project Engineering CoP.

Study/concept/ADP Report

09/23/22 Page 4 SP-1122

Specification for Design QA Plans Version 1.0

At this stage comments can easily be incorporated without cost or schedule impact. The
verification matrix reflects this and calls for wide ranging reviews and approvals at this
stage. The PDO project engineer should take care not to deviate too much from this. Any
errors carried forward to subsequent phases phase will require more and more effort to
resolve.

Note: A number of ADPs are produced in-house by PDO but these should still considered
as deliverables and be subject to the same verification requirements as a deliverable
produced by the LDSC/design contractor.

Front End Design (FED)

The relevant PDO engineer(s) is expected to review/comment on the design deliverable(s)

against all relevant standards, CoP’s and contributing documents. At this stage in the
process it is particularly import to ensure that the objectives set out in the ADP has indeed
been and that all the recommendations from both the Design Review, HAZOP and IPF
reviews have been incorporated into the design. The PDO project engineer must make these
document available to the reviewer on request.

Detail Design (DD)

This stage mainly consists of turning the FED into a detailed set of instruction for the
construction contractor. Any new deliverables introduced at this stage is generally of low
criticality e.g. fabrication isometrics and instrument hook-up drawings. At this stage the
reviewer should concentrate on the issues such as constructability, shutdown requirements
and operational issues.

As-Building

The design QA plan is not applicable at this stage. As-building is a clerical exercise and
there is no value to be added by applying the QA Plan at this stage. The FTR procedure
(PR-1247) is adequate to cover any changes arising between AFC issue and construction
completion.

09/23/22 Page 5 SP-1122

Specification for Design QA Plans Version 1.0

2.4 Process Flowchart

09/23/22 Page 6 SP-1122

Specification for Design QA Plans Version 1.0

An Access 97 database has been developed specifically to support this specification by

allowing fast and efficient production of Design QA plan. The system will mainly be
operated by the PDO Project Engineer but will also be available for use within the Design
Contractor.

2.5 Related Business Control Documents

ERD-00-02 is being superceded by this document, CP-117 and GU-272. This specification
is the final element in the use of the TA system within PDO.

Code of Practice
CP-117 Project Engineering Code of Practice June-1999

Procedure

PR-1247 Project Change Control & Standards Aug-1999

Variance Procedure (FTR Procedure)

Specification
DEP 82.00.10.10- Gen Project Quality Assurance Dec-1995

Guideline
Guidance for the Granting of Engineering April-1998
GU-272 Technical Authorities

2.6 Review and Improvement

CFDH for Project Engineering will ensure review and re-verification of this procedure
every 3 years.

2.7 Step-out and Approval

The PDO project engineer in conjunction with the ETL can elect to develop a project
specific Design QA plan which is not based on the verification matrix given in Appendix C
but this plan will require endorsement by the CFDH Project Engineering and a clear
justification must be as to why the specification is not being followed.

09/23/22 Page 7 SP-1122

Specification for Design QA Plans Version 1.0

Appendix A Glossary of Terms, Definitions & Abbreviations

ETL Engineering Team Leader

CFDH Corporate functional discipline Head

QA Quality Assurance

LDSC Local Design Service Contract

09/23/22 Page 8 SP-1122

Specification for Design QA Plans Version 1.0

APPENDIX B: User Feedback Page

From :

To : UEJ

Any user who identifies an inaccuracy, error or ambiguity is requested to notify the custodian so that
appropriate action can be taken. The user is requested to return this page fully completed, indicating
precisely the amendment(s) recommended.

USER DATE REMARKS

09/23/22 Page 9 SP-1122

Specification for Design QA Plans Version 1.0

Appendix C Design Deliverables Verification Matrix

09/23/22 Page 10 SP-1122

Specification for Design QA Plans Version 1.0

Appendix D Sample Design Deliverables Verification Matrix

09/23/22 Page 11 SP-1122