Spec For Design QA Plans Sp-1122a
Spec For Design QA Plans Sp-1122a
Spec For Design QA Plans Sp-1122a
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
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 1.0 Jan’00 Harald Traa, OTE/2 First Issue of Design QA Plan Specification
Contents
1. Introduction...........................................................................................................................1
1.1 Background.......................................................................................................................1
1.2 Purpose..............................................................................................................................1
1.3 Distribution/Target Audience...........................................................................................1
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’.
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.
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.
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 PDO project Engineer is responsible for developing the initial QA plan as well as
monitoring compliance against it together with the PDO project engineer.
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.
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.
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.
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
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.
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
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.
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
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
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.
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.
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
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
CFDH for Project Engineering will ensure review and re-verification of this procedure
every 3 years.
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.
QA Quality Assurance
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.