MPDS 00-00-02 Rev 0

MPDS 00-00-02 Explanation and Use of Malaysian Project Design Specifications (MPDS) July 2011

Upstream MPDS 00-00-02 REV 0

of 21

EXXONMOBIL EXPLORATION & PRODUCTION MALAYSIA INC

Note to Third Parties: Copyright (2010) ExxonMobil Exploration & Production Malaysia Inc. All rights reserved. No portion of this work may be reproduced or distributed by any means or technology or otherwise used in any manner without the express written consent of ExxonMobil Exploration & Production Malaysia Inc.

Explanation and Use of Malaysian Project Design Specifications (MPDS)

MPDS 00-00-02

0 July 2011 Initial Publish FF AAR LBW DCS

Rev. Issue Date Description Document Custodian

Endorser System

Administrator System Owner



of 21


Scope

This Malaysian Project Design Practices (MPDS) focuses only on usage and application of MPDS for

EMEPMI projects execution.

Explanation and use of Global Practice and EMEPS are intentionally segregated to be further detailed in

GP 00-00-02. Processes related to the GPs, and EMEPS are intended to meet Operations Integrity

Management System (OIMS) and ExxonMobil Capital Project Management System (EMCAPS)

requirements.

Norbaitie.mutallib

Typewritten Text

Norbaitie.mutallib

Typewritten Text



of 21


Table of Contents

1. Required References ............................................................................................ 4

1.1. Global Practices–ExxonMobil Engineering Practices ................................... 4

1.2. EMEPMI Specific References ...................................................................... 4

2. Definitions.............................................................................................................. 4

3. DPSS Organization................................................................................................ 5

4. MPDS General Information................................................................................... 7

5. MPDS Approval Procedure................................................................................... 8

6. MPDS Updating Procedure................................................................................. 10

7. MPDS Deviation Procedure ................................................................................ 12

8. MPDS Retroactive Application Procedure ........................................................ 15

Record of Change ....................................................................................................... 17

Attachment 1: Purpose Code Definitions................................................................. 18

Attachment 2 : MPDS Roles & Responsibility Matrix............................................... 20

Norbaitie.mutallib

Typewritten Text

Norbaitie.mutallib

Typewritten Text

Norbaitie.mutallib

Typewritten Text

Norbaitie.mutallib

Typewritten Text

Norbaitie.mutallib

Typewritten Text

Norbaitie.mutallib

Typewritten Text



of 21


1. Required References

This Section lists the Practices, codes, standards, specifications, and publications that shall be used with

this document. Unless otherwise specified herein, use the latest edition.

1.1. Global Practices–ExxonMobil Engineering Practices

GP 00-00-02 Explanation and Use of Global Practice

1.2. EMEPMI Specific References

OIMS System 3-2

Shared Services LAN

I:\shdsrvc\Information\OI\EMEPMI SYSTEM MANUALS\Element

03\Sys 3-2, Managing Design Practices

2. Definitions

Design Instruction

Manual (DIM)

Heritage (now retired) EMEPMI primary specifications intended for

use by EMEPMI's design engineers and design consultants.

Global Practice (GP) ExxonMobil’s corporate wide primary specifications which are used as

the basis of MPDS development.

General Specifications

(GS)

Heritage (now retired) EMEPMI primary specifications intended for

use by fabricators, contractors and equipment suppliers.

Malaysian Project

Design Specifications

(MPDS)

Documents developed based on GP with relevant local lessons learned

from DIM / GS incorporated to be used as the basis for project

development.

Shall Indicates a mandatory requirement that must be followed unless

otherwise instructed or approved.

Should Indicates a recommended preference that is good practice but is not

required in order to conform to the GP. An alternative to this

preference is not considered a deviation.

Norbaitie.mutallib

Typewritten Text

Norbaitie.mutallib

Typewritten Text

Norbaitie.mutallib

Typewritten Text

Norbaitie.mutallib

Typewritten Text



of 21


3. DPSS Organization

1. Design Practices Specifications and Standards (DPSS) Organization is established under OIMS

System 3-2 – Managing Design Practices, Standards and Deviations.

2. This organization has the overall responsibility for the specifications used within EMEPMI, e.g.

MPDS.

3. Overall roles and responsibilities of the DPSS Organization members, depicted in the Organization

chart above, are detailed in Table 1.

Table 1 : DPSS Organization Member Roles & Responsibility

Role Responsibility

DPSS /

System 3-2 Owner

• Has overall responsibility for the DPSS and its management.

• Approves changes to DPSS procedures.

DPSS /

System 3-2 Administrator

• Develops DPSS procedures and assists DPSS Owner in ensuring

procedures are communicated and implemented.

• Approves changes to DPSS forms.

• Approves personnel changes in SMC List.

• Establishes frequency of reporting on DPSS measurement

parameters.

DPSS Steering Committee

• Provide management oversight

• Ensure the DPSS is staffed with knowledgeable individuals.

DPSS / System 3-2 Owner

(Project Executive)

DPSS Steering Committee Project Executive

Surface Technical Manager

Design Engineering Manager

Production Proj. (Brownfield) Manager

SHEQ Manager

MPDS Technologist

DPSS Coordinator (s)

EMEPMI SMCs

DPSS / System 3-2 Administrator

(Design Engineering Manager)



of 21


Role Responsibility

DPSS Coordinator (s)

• Provides support to DPSS Administrator in DPSS management.

• Establishes DPSS procedures

• Establishes format of DPSS forms

• Conduct performance verification on MPDS usage

• Interprets verification results and advise DPSS Administrator and

Owner as appropriate.

• Conducts DPSS training as required.

SMC Leads • Act as overall contact for any queries on the assigned MPDS

• Assign/maintain MPDS custodianships to team members

• Coordinate review of MPDS updates with respective SMC team

members

SMCs • Primary contact for technical queries related to the assigned MPDS

• Review the drivers of MPDS updates

1. Determine if updates are safety or integrity critical items. For

such items, prepare MPDS Bulletin for System 3-2

Administrator approval.

2. Update MPDS document – during scheduled maintenance

(every 3 years) or as deemed required

• Ensure a copy of approved MPDS and all supporting documents are

sent to MPDS Technologist for record and LAN update

• Ensure applicable local regulatory requirements are incorporated

into the assigned MPDS

• Act as a contact with GP SME

• Determine involvement of SMC(s) or personnel from other

discipline to develop and review the assigned MPDS

MPDS Technologist • Maintains the MPDS Repository List

• Maintains electronic and hard copies (if applicable) of MPDS

• Maintains a master file of all DPSS forms

• Maintains records/logs of approved PCNs (deviations to MPDS /

DIM / GS only) and MPDS Bulletins

4. The roles and responsibility of all involved parties during the MPDS Approval, Update and

Deviation phases can be seen in Attachment 2 – MPDS Consolidated Roles & Responsibility Matrix.



of 21


4. MPDS General Information

1. MPDS are largely developed based on ExxonMobil’s Global Practice (GP) with relevant information

from DIM/GS incorporated. The MPDS numbering corresponds to the GP number that the MPDS is

developed from, e.g. MPDS 70-01-05 is based on GP 70-01-05.

2. When there is no applicable GP for a specific topic, GS is used as the base document to develop the

MPDS. They are numbered with “MPDS XX-99-XX”, e.g. MPDS 00-99-04 Precommisioning and

Testing is based on GS 0-5-20.

3. The lists of GP and GS used to create these MPDS can be found in MPDS Repository File on OIMS

System 3-2 Shared Services LAN.

4. MPDS publish date and revision numbers along with the GP revisions which the MPDS is based on

are shown in the header and footer of MPDS respectively.

5. Purpose codes, extracted from GP, e.g. [S], [E], are intended to highlight specific requirements and

their implications (Refer to Section 4.3 of GP 00-00-02). The [X], [Y], [Z] purpose codes, applicable

only to MPDS, are there to identify the changes made when a GP is modified into an MPDS. Refer to

Attachment 1: Purpose Code for detailed definition.

6. The MPDS cover would display the following information:

a) Document Custodian = Subject Matter Contacts

b) Endorser = SMC Lead

c) System Administrator = Projects Department’s Design Engineering Manager

d) System Owner = Project Executive

7. Refer to GP 00-00-02 for detailed explanation on GP and EMEPS



of 21


5. MPDS Approval Procedure

5. Appropriate management approval is required before any new or updated MPDS can be officially

used. The MPDS will be endorsed and approved via a memorandum / routing slip.

6. The required approval level of each MPDS varies, as summarized in Table 2.

Table 2 : Summarized Approval Level for New and Updated MPDS

Updated MPDS

New MPDS (no SHE impact) (SHE impact)

EMEPMI SMC Endorse Review Review

EMEPMI SMC Lead Approve Endorse Review

System 3-2 Administrator Note 1* Approve Endorse

System 3-2 Owner Note 1* Approve

*Note 1 - Approval authority delegated to SMC Lead

7. A “Draft” MPDS is an MPDS which has not received the appropriate level of endorsement due to

several reasons e.g. MPDS is still under development, pending SMC lead endorsement, and pending

updates endorsement by System 3-2 Administrator / Owner.

e) In the event that these “Draft” MPDS are required to be used, endorsement and approval from

System Administrator and System Owner is required.

f) Users are required to perform a Risk Assessment to ensure that no Safety, Health and/or

Environmental implications are associated with releasing these “Draft” specifications.

g) Users need to refer to the MPDS Repository List to identify whether the MPDS are in “Draft”

status.

8. Refer to Figure 1 for MPDS Approval Procedure chart



of 21



Figure 1- MPDS Approval Procedure



of 21



6. MPDS Updating Procedure

1. MPDS could be updated for the following reasons (Drivers of MPDS updates):

a) Revision, addition or deletion of GP, where GPs are maintained by the Corporation

b) Project Change Notice (PCN)

c) Incident Reports

d) Lessons Learned

e) Others e.g. Contractor’s Feedback

2. These drivers will be received by the MPDS Technologist, who will notify the respective SMCs.

3. MPDS are scheduled to be updated every 3 years to incorporate new GP revisions, PCN, MPDS

Bulletin and other drivers. However, SMC, with the recommendation of the System 3-2

Administrator, has the flexibility to update the MPDS on as need basis.

4. MPDS Bulletin will be used to share any SHE critical information.

5. There is a possibility of MPDS being in-between revisions. If there are any update drivers that have

not been incorporated into the current MPDS, it would be parked under the same folder as the MPDS

itself. Users would have to work with the SMC / SMC Lead to decide whether to implement these

updates, bearing in mind that these might be incorporated into the next MPDS revision.

6. Approval level required for updated MPDS is discussed in Table 2, Section 5.

7. Refer to Figure 2 for MPDS Updating Procedure.



of 21



Figure 2 - MPDS Update Procedure



of 21



7. MPDS Deviation Procedure

1. This procedure outlines the process to request for project specific deviations to the requirements in

MPDS.

2. “Shall” indicates a mandatory requirement that must be followed unless otherwise instructed or

approved. Alternative to this is a deviation to MPDS.

3. “Should” indicates a recommended preference that is good practice but is not required in order to

conform to the MPDS. An alternative to this is not a deviation to MPDS.

4. The Project Change Notice (PCN) form shall be used to document the review and approval of

exceptions/deviations to requirements in MPDS.

5. Detailed procedure on how to use the PCN form, which is also used for documenting deviations /

changes from Project specific documents e.g. Project Design Basis, can be found in Project

Management Manual Section 9.

6. For each type of exceptions/deviations, users must assess the following implications and its

mitigation/prevention measures:

a) Regulatory compliance

b) Safety/health/

c) Environmental impact

d) Operability impact

e) Cost impact

f) Schedule impact

g) Weight impact

7. Approved project specific deviations shall not be automatically adopted for general use on all

projects.

8. For approved PCNs that are recommended for permanent change to the MPDS, the MPDS

Technologist will keep a copy of the PCN at associated MPDS folder. This will be incorporated into

the MPDS at the next update interval

9. The required approval level of each deviation varies as summarized below. Refer to PCN for the

details of required approval level



of 21


Table 3 : Approval Level for MPDS Deviation

MPDS Deviation

Non [S] and [E] deviations [S] and [E] deviations

GP’s Subject Matter Expert

(SME)

Endorse EMDC/EMPC SDR

form

EMEPMI SMC Review

- ensure no local contradiction

- review permanent change to MPDS

- review retroactive application on existing facitilies

EMEPMI SMC Lead Endorse Review

Projects Department SHE

Manager

Review (to ensure no local

contradiction)

System 3-2 Administrator Approve Endorse

System 3-2 Owner Approve

10. Refer to Figure 3 for Updating Procedure chart and the required level of approval.



of 21



Figure 3 - MPDS Deviation Procedure



of 21



8. MPDS Retroactive Application Procedure

1. Figure 4 below outlines the process for identifying and advising Surface Technical of changes that

should be considered for retroactive application on existing facilities.

2. Potential retroactive application areas are identified from Project Change Notice (PCN), MPDS

Bulletin, Corporate’s Technical Alert, updated MPDS or the periodic Risk Assessments done on

existing facilities.

3. Changes that should be considered for retroactive application are those that:

a) involve major safety and/or environmental issues.

b) result in significant OPEX savings

c) will achieve economics savings (present value) in the order of USD250K.

4. DPSS / System 3-2 Owner will endorse the release of items proposed for retroactive application to

Operations Technical Surface Manager

5. Operations Technical Surface Department confirms whether the recommended item(s) are beneficial

to be implemented, based on the working knowledge of existing facilities and prepares a technical

proposal containing detailed cost, schedule and operations impact to implement the items.

6. Production Operations Management (Operations Managers and Deputy Production Manager) makes

the final decision on whether to proceed with retroactive application, approves the schedule and

funding plan, and assigns project ownership.



of 21



Figure 4 - MPDS Retroactive Application



of 21



Record of Change

Rev 0 Date: Jul

2011

Location Action Description

Initial Publish.

Instituted Purpose Codes [X], [Y], [Z] to identify those paragraphs that

have been deleted ( [X] ), modified ( [Y] ), or added ( [Z] ) as a result of

the Gap Analysis undertaken to identify items in heritage Company

design documentation (DIM and GS) and other sources relevant to

Company operations (i.e. Regulatory requirements) that should be

included into the MPDS.

Those paragraphs with Purpose Codes [X], [Y], [Z] shall be compared

against subsequent revisions of the GPs as they are accepted into

Company.



of 21


Attachment 1: Purpose Code Definitions

Code Description

* Assigned to paragraphs that require the Company Representative to provide additional

information or make a decision.

A Assigned to paragraphs that require approval from the Company Representative before the

work may proceed or the design is finalized.

C Assigned to paragraphs whose primary purpose is reduced costs. Reduced cost in this context

refers to initial investment cost and does not include life cycle cost considerations. Life cycle

cost considerations are captured under reliability, maintainability, or operability purpose codes.

E Assigned to paragraphs whose primary purpose is driven by environmental considerations.

Environmental considerations typically include specifications intended to protect against

emissions/leakage to the air, water, and/or soil. Deviations from the specifications contained

in such paragraphs require formal review and approval according to local environmental

policy.

I Assigned to paragraphs that provide only clarifying information, such as Scope statements,

definitions of terms, etc.

M Assigned to paragraphs whose primary purpose is to provide for maintainability of equipment

or systems. Maintainability provisions are those that facilitate the performance of maintenance

on equipment/systems either during downtimes or during onstream operations.

O Assigned to paragraphs whose primary purpose is to assure operability of equipment or

systems. Operability is the ability of the equipment/system to perform satisfactorily even

though conditions are off-design, such as during start-ups, process swings, subcomponent

malfunction, etc.

R Assigned to paragraphs whose primary purpose is to improve or assure the reliability of

equipment or systems. Reliability is a measure of the ability of equipment/systems to operate

without malfunction or failure between planned maintenance interventions.

S Assigned to paragraphs containing specifications/guidance where the primary purpose is the

avoidance of incidents impacting personnel safety, process safety, and the public in general

and/or involving responses to emergency situations. Any deviation from the specifications

contained in such designated paragraphs requires formal review and approval according to

local safety policy.

Personnel Safety: Refers to the prevention of incident-related personnel injuries or illness,

e.g., burns, cuts, abrasions, inhalation of or exposure to dangerous

substances, etc., that could result in medical treatment, restricted work,

lost-time incidents, or fatalities.

Process Safety: Refers to the prevention and control of process releases, fires, and/or

explosions that could result in damage to equipment, process disruption,

or personnel injury or illness.



of 21


Code Description

X Assigned to paragraphs that have been deleted in their entirety from the GP base-

document, and not replaced when developing the MPDS. The associated Rationale

content has been deleted as appropriate. The statement “Intentionally Deleted” has been

added to the original GP item number to retain the GP base-document structure.

The GP base-document and revision are listed on the front page of this MPDS as well as all

page footers.

The deleted paragraphs and requirements therein were not applicable to the MPDS at the

time of MPDS development. Subsequent revisions of the GP shall be compared against this

MPDS to ensure that GP updates are properly incorporated into the next revision of the

MPDS, including a review of deleted paragraphs to ensure the deletion is still valid.

Y Assigned to paragraphs that have been modified from the GP base-document when

developing the MPDS. These modifications may include partial deletion of text from a

specific requirement. The changes identified are of a technical nature, affecting the

clause of the MPDS (compared to the GP base-document). Clerical changes, such as

replacement of "GP" with "MPDS" or "Company" with "EMEPMI" are not identified.


page footers.

Specific project requirements have been written into the GP base-document paragraph.

Subsequent revisions of the GP shall be compared against this MPDS to ensure that GP

updates are properly incorporated into the next revision of the MPDS. The specific project

requirements embedded in the GP base-document paragraphs shall be retained in subsequent

revisions of the MPDS unless otherwise superseded by requirements in the GP. Alternately,

they may be removed via the appropriate deviation process.

Z Assigned to paragraphs that have been added to the GP base-document.


page footers.

The paragraph numbers assigned shall add onto the GP base-document structure. Therefore,

subsequent revisions of the GP shall be compared against this MPDS to ensure that GP

updates are properly incorporated into the next revision of the MPDS. All additional

paragraphs in this MPDS shall be included in subsequent revisions of the MPDS unless

otherwise superseded by requirements in the GP. Alternately, they may be removed via the

appropriate deviation process.



of 21


Attachment 2 : MPDS Consolidated Roles & Responsibility Matrix



of 21



Approval Deviation MPDS Updates

New MPDS no SHE

impact SHE

impact

Update non [S] and

[E] items [S] and [E] items

Retroactive Application

End User / Project Team

1) Aware that MPDS files and MPDS Repository File can be found at OIMS System 3-2 LAN 2) Ensure that the latest and approved revision of MPDS are used 3) Obtain approval from System 3-2 Owner for “Draft” MPDS

Obtain SMC endorsement

(via PCN form)

1) Obtain GP SME endorsement (via EMDC or EMPC Special Provision / Specification Deviation Request form) 2) Obtain SMC endorsement (via PCN attaching endorsed SP / SDR form)

MPDS Technologist

1) Track MPDS Approval Status 2) Create and distribute approval

memorandum

1) Distribute drivers for MPDS updates to relevant SMC 2) Distribute Technical Alerts or MPDS Bulletin to EMEPMI 3) Update MPDS folder with GP updates, PCN, MPDS Bulletin etc 4) Perform quarterly analysis on the number of drivers pending incorporation for each MPDS 5) Track MPDS Bulletin approval

1) File PCN recommended for permanent change under associated MPDS folder 2) File PCN recommended for retroactive application – send to SMC for review

Track Retroactive Application close out

GP SME Endorse SP or SDR form

EMEPMI SMC Endorse Review Review

1) Review drivers of MPDS updates within 2 weeks (focusing on items potentially contradicting with local practice, recognizing GP has been reviewed by SME) 2) Prepare MPDS Bulletin (SHE/ integrity critical updates within 4 weeks) 3) Update MPDS during scheduled maintenance or as required

Review PCN: a) ensure no local contradiction b) review permanent change to MPDS c) review retroactive application on existing facilities

Review and recommend retroactive application (in PCN, Technical Alerts /

MPDS Bulletins, Updated MPDS)

EMEPMI SMC Lead

Approve Endorse Review Review / endorse updates (refer MPDS approval procedure)

Endorse Review Review recommendation

to OTS

Projects Dept SHE Manager

Review PCN - ensure no local

contradiction

System 3-2 Administrator

Note 1 Approve Endorse

1) Propose MPDS update based on quarterly analysis 2) Endorse / approve updates (refer MPDS approval procedure)

Approve Endorse Review recommendation

to OTS

System 3-2 Owner

Note 1 Approve Approve updates (refer MPDS approval procedure)

Approve Endorse recommendation

to OTS

Note 1 – Approval authority delegated to SMC Lead

MPDS 00-00-02 Rev 0

Documents

Transcript of MPDS 00-00-02 Rev 0