Erd 00 19

ENGINEERING REFERENCE DOCUMENT
ERD-00-19
APR 97
WMS PROCEDURES
Petroleum Development Oman LLC (PDO) have published this Engineering Reference
Document (ERD) for PDO employees and PDO nominated Contractors and Suppliers.
ERD-00-19 WMS PROCEDURES
APR 97
Page 2
REVISION STATUS
Engineering Reference documents shall only be revised in accordance with ERD-00-10

‘Presentation, Content & Issue of ERD’s’
REVISION STATUS
Revision Date Description

0 April 1997 First Issue
Note : Engineering Reference documents shall be revised in accordance with:-
PDO-ERD-00-10 Presentation, Content & Issue of ERD’s.
Do not use this copy of the ERD if the print-out date is before the latest issue date. The print-out date is on the
bottom of every page. You can find the latest issue date for this ERD on the wall-chart ERD-00-01. Check the
PDO-Intranet (DCS pages) for news about temporary amendments. Printout date: 09/22/22
WMS PROCEDURES ERD-00-19
APR 97
Page 3
USER GUIDELINES
Engineering Reference Documents (ERDs) contain information which shall be used for the
development and operation of Company facilities.
The ERD system is intended to:
 Act as vehicle to minimise costs on a life cycle basis.

 Set the Company standards for facilities along the facilities life cycle.
 Disseminate and record facilities related information, experience and procedures.
The objectives of this ERD are:
 To specify the steps required to be executed by the Project Engineer to manage a

Capital project in WMS.
 To specify the steps required to be executed by the Planning Co-ordinators to manage
the data in WMS.
This document is intended for use by Petroleum Development Oman (PDO) and its nominated
Contractors and Suppliers and is intended for use by Capital Project Engineers.
References to DEP’s and International Standards within this ERD are based on the current revision
of those standards at the time of approval of this ERD. It is the responsibility of the user to check that
he is using the latest revision of this document, and to check that the correct revision of referenced
DEP’s and International Standards are used together with this document.
The responsibility for the content of this document rests with the Corporate Functional Discipline
Head (CFDH) indicated below. Copies of this document can be obtained from the Development
Technical Library held by Engineering Services.
Any user of this document who encounters an inaccuracy or ambiguity is requested to notify the
CFDH using the User Feedback page provided at the end of this document.
Author Custodian Functional Manager For

Engineering
Date: Date: Date:
APR 97
Page 4
CONTENTS
REVISION STATUS.................................................................................................2
USER GUIDELINES................................................................................................3
1 INTRODUCTION............................................................................................................ 7
1.1 SCOPE................................................................................................................................... 7
1.2 DEVIATION FROM STANDARD............................................................................................ 7
1.3 LANGUAGE AND UNITS OF MEASUREMENT....................................................................7
1.4 DEFINITIONS........................................................................................................................ 7
1.4.1 General definitions.............................................................................................................. 7
1.4.2 Specific Definitions............................................................................................................. 8
1.4.3 Abbreviations...................................................................................................................... 9
2 OVERVIEW.................................................................................................................. 10
2.1 GENERAL............................................................................................................................ 10
2.2 CREATION OF A PROJECT/BI IN WMS.............................................................................10
2.3 BREAKDOWN OF A BI INTO ACTIVITIES..........................................................................10
2.4 PLANNING A BI IN PS6....................................................................................................... 10
2.5 GENERATION OF PLAN AND PHASINGS IN WMS...........................................................10
2.6 APPROVING THE BUDGET IN WMS..................................................................................10
2.7 GENERATING LEDGER-CODES........................................................................................ 11
2.8 GENERATION OF RFA....................................................................................................... 11
2.9 COMMITMENT CONTROL.................................................................................................. 11
2.10 REPORTING VOWD............................................................................................................ 11
2.11 PROJECT CLOSING........................................................................................................... 11
2.12 SYSTEM INTERFACES....................................................................................................... 11
2.13 MAINTAINING BOARD APPROVED TARGETS.................................................................11
2.14 MONTH-END PROCESSING.............................................................................................. 12
2.15 MANAGEMENT REPORTING............................................................................................. 12
3 PROCEDURES FOR PROJECT ENGINEERS.............................................................13
3.1 CREATION OF A PROJECT/BI IN WMS.............................................................................13
3.1.1 Introduction....................................................................................................................... 13
3.1.2 Procedure......................................................................................................................... 13
3.1.3 Timing............................................................................................................................... 14
3.1.4 Reporting.......................................................................................................................... 14
3.2 BREAKDOWN OF BIS INTO ACTIVITIES...........................................................................15
3.2.1 Introduction....................................................................................................................... 15
3.2.2 Procedure......................................................................................................................... 15
3.2.3 Work Breakdown Structure (WBS)...................................................................................15
3.2.4 Milestone Breakdown Structure........................................................................................ 17
3.2.5 Organisation Breakdown Structure (OBS)........................................................................17
3.2.6 Resource Breakdown Structure (RBS).............................................................................17
3.3 PLANNING OF BIS IN PS6.................................................................................................. 18
3.3.1 Introduction....................................................................................................................... 18
3.3.2 Procedure......................................................................................................................... 18
3.3.3 Configuring PS6 for Export to WMS.................................................................................18
3.4 GENERATION OF PLAN AND PHASINGS IN WMS...........................................................19
3.4.1 Introduction....................................................................................................................... 19
3.4.2 Procedure......................................................................................................................... 19
3.4.3 Timing............................................................................................................................... 19
3.5 APPROVING THE BI IN WMS............................................................................................. 20
3.5.1 Introduction....................................................................................................................... 20
3.5.2 Procedure......................................................................................................................... 20
3.5.3 Reporting.......................................................................................................................... 20
3.5.4 Financial Authorities......................................................................................................... 20
APR 97
Page 5
3.6 GENERATION OF LEDGER-CODES..................................................................................21

3.6.1 Introduction....................................................................................................................... 21
3.6.2 Procedure......................................................................................................................... 21
3.6.3 Reporting.......................................................................................................................... 22
3.7 GENERATION OF RFA....................................................................................................... 22
3.7.1 Introduction....................................................................................................................... 22
3.7.2 Procedure......................................................................................................................... 22
3.7.3 Filing................................................................................................................................. 24
3.8 COMMITMENT CONTROL.................................................................................................. 25
3.8.1 Introduction....................................................................................................................... 25
3.8.2 Procedure......................................................................................................................... 25
3.8.3 Reporting.......................................................................................................................... 25
3.9 VOWD REPORTING............................................................................................................ 26
3.9.1 Introduction....................................................................................................................... 26
3.9.2 Procedure......................................................................................................................... 26
3.9.3 Controls and Reporting Requirement...............................................................................27
3.9.4 Timing............................................................................................................................... 27
3.9.5 Financial Authorities......................................................................................................... 27
3.10 PROJECT CLOSING........................................................................................................... 28
3.10.1 Introduction................................................................................................................... 28
3.10.2 Procedure..................................................................................................................... 28
3.11 SYSTEM INTERFACES....................................................................................................... 30
3.11.1 Introduction................................................................................................................... 30
3.11.2 Procedure..................................................................................................................... 31
3.12.1 Introduction................................................................................................................... 32
3.12.2 Procedure..................................................................................................................... 32
3.12.3 Project Status................................................................................................................ 32
3.12.4 Generation of monthly reports.......................................................................................32
3.12.5 Timing........................................................................................................................... 32
4 PROCEDURES FOR PLANNING CO-ORDINATORS..................................................33
4.1 CREATION OF BUDGET ITEM IN WMS.............................................................................33
4.1.1 Introduction....................................................................................................................... 33
4.1.2 Procedure......................................................................................................................... 33
4.2 MAINTAINING BOARD APPROVED TARGETS.................................................................34
4.2.1 Introduction....................................................................................................................... 34
4.2.2 Procedure......................................................................................................................... 34
4.2.3 Timing............................................................................................................................... 35
4.2.4 Reporting.......................................................................................................................... 35
4.3 MONTH-END PROCESSING.............................................................................................. 35
4.3.1 Introduction....................................................................................................................... 35
4.3.2 Procedure......................................................................................................................... 36
4.3.3 Reports............................................................................................................................. 36
4.4.1 Introduction....................................................................................................................... 37
4.4.2 Procedure......................................................................................................................... 38
4.4.3 Reporting against Board Approved Target.......................................................................38
4.4.4 Year-end........................................................................................................................... 38
5 REFERENCES.............................................................................................................39
5.1 PDO STANDARDS.............................................................................................................. 39
5.2 SHELL STANDARDS........................................................................................................... 39
Figure 1 - Procedure Flowchart..............................................................................40
Figure 2 - Work Breakdown Structure...................................................................41
APR 97
Page 6
APPENDIX 1 – Function Codes.............................................................................42

APPENDIX 2– ANALYSIS CODES........................................................................43
APPENDIX 3– WMS INTERFACES.......................................................................44
USER FEEDBACK PAGE......................................................................................45
APR 97
Page 7
1 INTRODUCTION
1.1 SCOPE
This ERD gives the minimum requirements for managing a Capital project in WMS, and replaces the
existing ‘Procedures relating to the use of EWMS’.
1.2 DEVIATION FROM STANDARD
The user shall obtain written approval from the Project Management CFDH or UFDH.
1.3 LANGUAGE AND UNITS OF MEASUREMENT
The English language and the SI system of units shall be used throughout for all documentation and
drawings. When necessary, for specific applications, alternative units may be indicated in brackets
behind the SI units, however this practice should diminish.
1.4 DEFINITIONS
1.4.1 General definitions
The Contractor is the party which carries out all or part of the design, engineering, procurement,
construction, commissioning or management of a project, or operation or maintenance of a facility.
The Principal may undertake all or part of the duties of the Contractor.
The Manufacturer/Supplier is the party which manufactures or supplies equipment and services to
perform the duties specified by the Contractor.
The Principal is the party which initiates the project and ultimately pays for its design and
construction. The Principal will generally specify the technical requirements. The Principal may also
include an agent or consultant authorized to act for, and on behalf of, the Principal.
The word shall indicates a requirement.
The word should indicates a recommendation.
The word may indicates a possible course of action.
The Company is Petroleum Development Oman LLC.
The User is the Company, Consultant or Contractor designate who uses this document.
SIEP is Shell International Exploration and Production.
An Engineering Reference Document is defined as any document authorized by the Company

containing information for the purpose of stating required facilities related standards (surface and
subsurface). The document reference will be prefaced ‘ERD’.
The Corporate Functional Discipline Head is the person responsible for the discipline the standard
belongs to (CFDH).
APR 97
Page 8
1.4.2 Specific Definitions
Account Code A 4 character Identifier defined by Corporate finance for gathering costs.
ADP Asset Development Plan.
AN Analysis code: the last two numeric characters of the WBS facilitating more
detailed analysis of projects.
Activity A BI is broken down into different areas of work called Activities, in order to
facilitate an efficient project control.
BOM Bill of materials: the document used for approval of expenditure and the
placing of orders for materials.
BI The last 4 characters of the Project number and an alpha character

indicating the Budget Item.
Commitment The Company’s exposure to third parties calculated as awarded contract

value, BOMs issued, and job orders placed.
Corporate Baseline Summation of all capital project plans fixed at a point of time which is set to
coincide with the Board Meetings at March and October.
EMA Materials recording and tracking system maintained by Supply Department.
ECAR Capex Allocation Register with Engineering BI to Petroleum Engineering

Development Projects links, demonstrating justification for the BIs and for
calculating the UTC.
EPCON The Contract Management System.
EPCRIS The Company’s general ledger.
EZ The Company’s service contract administration system.
FN Function code: the second last two numeric characters of the WBS
facilitating aggregation to ‘function’ level in projects.
HCG Hague classification group: SIEP standard codes for materials.
IBP Internal Budget Proposal (for Projects up to and including $1 M).
LCF Latest cost forecast: The Project Engineer’s latest import of the PS6 plan for
a capital project before he approves the import in WMS.
LACF Latest advised cost forecast: Once the Project Engineer approves the import
of PS6 plan in WMS, the LCF becomes LACF.
Ledger Code A 14 character identifier for gathering costs in the general ledger made up of
account code plus WBS.
Planning Co-ordinator The Focal Point for WMS (ABS/6, BBS/5, TCT/1).
Project A work package with defined scope of work, cost, time and objective.
APR 97
Page 9
Project Close Out When a project is physically complete and formally handed over to
the asset holder with all supporting activities complete.
Project Number A 5 character number generated by CABCARS in which the first

character is the decade, the second is the year and the last three
are randomly generated.
Project Title Summary description of the project.
PS6 Project Scheduler 6: the planning package used by project

engineers which interfaces with WMS to import plans.
System Manager WMS Custodian (BBS/5).
Targets The latest schedule and VOWD phasing, frozen by the Planning Co-
ordinators to represent the Shareholder approvals in March and
October.
UTC Unit Technical Cost of production.
VOWD Value of work done: a measure of the physical work actually

completed including all Long Lead procurement activities on a
project. On Bulk materials, the VOWD is calculated when the
materials are shipped.
Workgroup A group of projects: the grouping of projects, generally within an

area engineering team, allows month end processing activities and
System Manager utility functions to be completed in manageable
sections rather than all users together.
WMS Work Management System: the system for the control and
management of capital projects.
1.4.3 Abbreviations
CABCARS Capital Budget Control, Administration and Reporting System.

CFDH Corporate Functional Discipline Head (BEZ).
CTR Cost, time & resource catalogue.
FAR Fixed Asset Register.
FFP Finance Focal Point (AFG, AFS, BFS, TCF).
JV Journal Voucher.
PCC Project completion certificate.
PO Purchase Order.
RFA Request for Authorisation (for internal use).
UFDH Unit Functional Discipline Head (AEF).
WBS Work breakdown structure.
WIP Work in Progress.
APR 97
Page 10
2 OVERVIEW
2.1 GENERAL
This document contains the procedure for the use of WMS within PDO. It takes the user through the
stages of use of the system in the sequence they are to be done. WMS is the group common system
to enable Project Engineers to plan and control their Projects effectively and efficiently, and to report
to Management the status of their Projects. It provides information on planning, costs and materials
in a Windows based environment. This allows viewing of multiple documents with all the normal
Windows functionally, for example, Cascade, Cut and Paste. Further information can be found from
the WMS User Guide and PS6 User Guide.
The flow chart of procedures for Project Engineers is included in Figure 1.
2.2 CREATION OF A PROJECT/BI IN WMS
Concept Engineers will identify new Projects, and FFP shall input the Project data into CABCARS.
Details on raising a Budget Proposal are available in the Capital Budget Guidelines (Custodian:
FCB). A weekly interface from CABCARS generates the Project and 1 BI for each Project in WMS
with different Engineers responsible for these BIs. Pending, Firm and Long Term Forecast Projects
are all held in WMS which assists in the creation of a corporate programme.
2.3 BREAKDOWN OF A BI INTO ACTIVITIES
The Project Engineer shall break down the BI into manageable activities using the WBS and
Standard Milestones, as explained in Section 3.2. This breakdown will provide a standard structure
to enable interrogation and generation of standardized reports.
2.4 PLANNING A BI IN PS6
The Project Engineer is responsible for creating a plan in PS6 for each of his BIs. Based on the
WBS and Standard Milestones, the Project Engineer shall plan the activities, and assign to the
activities various resources required to execute them. Detailed information on the use of PS6 is
available in the PS6 user manual.
2.5 GENERATION OF PLAN AND PHASINGS IN WMS
After generating the plan in PS6 as in 2.3 above, the Project Engineer will import the plan and
phasings into WMS. The phasing so imported is called Latest Cost Forecast (LCF). The Engineer
will review the plan and phasings in WMS, and if need be he will make necessary modifications in
PS6 and import again. Once the Engineer is satisfied that the data in WMS reflects the current
forecast, he will approve the import. After the approval, the last imported data is known as Latest
Advised Cost Forecast (LACF).
2.6 APPROVING THE BUDGET IN WMS
Once the Shareholders approve the Budget Proposal, the Project Engineer shall approve the Budget
in WMS. Failure to do so will result in blank Approved Budget column in the RFA. Apart from the
approval done so by the Project Engineers, Planning Co-ordinators will maintain the Approved
Budgets as Targets, which are used in the Management reports.
APR 97
Page 11
2.7 GENERATING LEDGER-CODES
After generating the LACF, the Project Engineer shall attach Account Codes to activities to generate
Ledger-codes. The ledger-codes so generated are transferred to EPCRIS electronically on a daily
basis. However, the FFP will have to activate them before the Engineer can make any commitments.
2.8 GENERATION OF RFA
The Project Engineer is responsible for raising the RFA. RFA is a control procedure to allow
monitoring of costs and scope by Management. It is possible to request RFA only for a group of
Activities against the BI. The Engineer should discuss the RFA with the FFP, and FFP shall circulate
the RFA for approval by the Management. Thereafter, the Project Engineer should select the button
issue in WMS. Authorisation of RFA by the Management allows the Project Engineer to spend the
approved funds. As soon as the RFA is approved by the Management, the Engineer should
Authorise the RFA in WMS.
2.9 COMMITMENT CONTROL
The Project Engineer may do commitment control through WMS at the Activity level, which is the
lowest level available in the system. Once the Engineer reports an activity as started, the system
treats the total value of the Activity as committed. The Project Engineer can view the latest
commitment on materials at a lower level of requisition and item. These data are transferred from
EMA to WMS on a daily basis. The Service Contract system EZ can be referred for commitments on
the service contract jobs at a detailed level.
2.10 REPORTING VOWD
Once the Project execution is underway, the Project Engineer shall input the achieved progress and
VOWD into PS6 by the end of each month, and import into WMS. These achieved VOWD are
exported to EPCRIS, to generate necessary accruals electronically.
2.11 PROJECT CLOSING
After physical completion of the Project, the PE shall raise the PCC, in accordance with the
procedures contained in section 3.10. At the end of each year, the Project Engineers shall inform the
FFP the Projects which are to be closed. After ensuring that all the requirements are met, the FFP
will arrange with FCB/1 to change the status of the Project in CABCARS as closed.
2.12 SYSTEM INTERFACES
Since CABCARS contains all the Projects, an interface has been designed from CABCARS for
generating Projects and Budget Items in WMS. Interface has also been developed for generating
ledger codes and creating accruals in EPCRIS and for getting back actual payments from EPCRIS
into WMS. A nightly interface from EMA to WMS updates the materials data. An interface will
transfer all the BIs with their latest phasings from WMS into ECAR in March and July for project
ranking and to produce Financial Planning Book (FPB) and Programmeme Documentation.
2.13 MAINTAINING BOARD APPROVED TARGETS
The Planning Co-ordinators shall check that LACF is in line with the Board Proposed Budget and
phasings, and freeze the schedule and VOWD phasings in January and July as Board Approved
Targets. After the Board meetings in March and October, the Planning Co-ordinators will incorporate
APR 97
Page 12
into these targets any deviations from the proposals frozen in January and July. Thereafter, the
target will represent the latest Board approvals, and the users can compare their latest forecast with
these targets and produce reports.
2.14 MONTH-END PROCESSING
Every month, the Planning Co-ordinators shall do the month-end processing in WMS. At the end of
2nd working day of each month, month-end processing is done for all the Work Groups, and the next
day morning System Manager shall produce exception reports, comparing the VOWD in WMS with
the actuals in EPCRIS. Planning Co-ordinators will distribute these reports to the Project Engineers
and FFP. After the Project Engineers make necessary corrections to the VOWD, the Planning Co-
ordinators shall ‘re-run’ the Month-end processing on the 4 th working day afternoon. This re-run will
generate the necessary accruals in EPCRIS.
2.15 MANAGEMENT REPORTING
After each month-end processing, the Planning Co-ordinators shall generate and store in WMS some
graphical reports comparing the latest forecast as input by the Project Engineer with the last
approved Board targets. Using these graphical reports and some tabular reports, each Department
produces monthly reports for Management reporting.
APR 97
Page 13
3 PROCEDURES FOR PROJECT ENGINEERS
3.1 CREATION OF A PROJECT/BI IN WMS
3.1.1 Introduction
CABCARS is the corporate capital budget control, administration, and reporting system through
which capital budget information is entered, at the Project level. The database is primarily updated,
as part of the two Board exercises each year, with corporate capital budget data for the next five year
period.
WMS is the database for controlling between and reporting of engineering capital budgets, at various
levels viz. Department, Project, BI, etc.
In order to maintain consistency between the two databases and to ensure that all Capital Projects
will continue to be recorded by one Corporate System, an interface has been built from CABCARS to
WMS for the generation of Projects and BIs in WMS. The main mechanism for creating new BIs in
WMS will be through this interface.
3.1.2 Procedure
The Concept Engineer will initiate new Projects, and the FFP shall input the data to CABCARS in
order to create the Project Header and number. There is no change to existing practices for the input
of data, and allocation of Project numbers by CABCARS (see CABCARS User Guide pages 3 to 5
and the Financial Overview – Engineering Projects Report pages 16 to 17). FFP should notify the
Project Engineer of the Project number.
The CABCARS data is transferred electronically to WMS every week. This data transfer will create in
WMS the Project number, and the following associated fields:
Field Description Field Length (in WMS)

Project Number 5
Project Description 30
Budget Item 5
Budget Description 40
Work Type 1 2
Work Type 2 2
Area 2
Field 2
Project Engineer 8
Each new Project will also have a Budget Item created in WMS by the interface. The BI will have the
description of the Project and a number by dropping the first character of the Project number and
adding a suffix ‘A’, for example the CABCARS Project number 96785 will create in WMS BI 6785A.
Project Engineer can break down his Project into more BIs with different Project Engineers
responsible for each of the BIs. An example of when this may be necessary is Project number:
92272 : Yibal Phase II Development Facilities Part 2, which had the following BIs created:
APR 97
Page 14
Budget Item Budget Description

2272B EPC Contract
2272C Remote Manifolds
2272D Flowlines Re-route
2272E Water Injection Manifolds
2272F New Flowlines
2272G Separators and Pumps
2272H Yibal Dehydration System
If the Project Engineer wants to breakdown a Project into more BIs, he should contact the Planning
Co-ordinator to set up the BIs in WMS. There is the capability to have a breakdown of upto 25 BIs
within one Project. The Project Engineer has to provide the Planning Co-ordinator with the Project
number, BI number, PE and title to set-up the Bis. BI title can be a maximum of 40 characters.
Since the title field in CABCARS is of 60 characters long and WMS can have only 40 characters, the
interface truncates the title to 40 characters in WMS. If the truncated title becomes meaningless,
Project Engineer should request the Planning Co-ordinator to change the title in WMS. The titles will
appear on all financial documentation produced. After the title have been changed in WMS, any
subsequent interface will not overwrite the Project and BI title fields.
Should the Project Engineer wish to change the data in any field, other than the title fields, that is,
when the Project is transferred to another Project Engineer or if a different Work Type should be
applied he should contact his FFP to make the changes in CABCARS. Once the interface takes
place the necessary fields will be updated in WMS. Where the Project is broken down into BIs, the
Project Engineer shall contact the Planning Co-ordinator to effect the changes.
The interface programme creates Pending and Long Term Forecast Projects in WMS, with a coding
structure which will allow reports to be generated in the same sort order as those produced from
CABCARS. The coding of these items in WMS is as follows:
Status Project Number Budget Item

Pending Items BPXXX PXXXA
Long Term Forecast Items LTXXX TXXXA
3.1.3 Timing
The interface will be run weekly on every Wednesday evening. If necessary the interface can be run
as and when required, by sending a request to the System Manager.
3.1.4 Reporting
The following reports will be produced for controlling the allocation of Project numbers within WMS
after the interface run:
Report Content Distribution

All Project numbers which have
System Manager who will notify PE via
changed status (that is, Pending to
WMS.
Firm).
All cancelled Projects. System Manager
All closed Projects. System Manager
All new Projects created. System Manager to PE
All Projects in WMS not in CABCARS. System Manager
APR 97
Page 15
3.2 BREAKDOWN OF BIS INTO ACTIVITIES
3.2.1 Introduction
The ability of WMS to aggregate capital budget Project Plans and resources by Section, Department,
Function, or by a particular resource type, location, or work type, depends on all the plans being
expressed in common codes.
This common coding structure has been developed initially for use with Engineering Capex Projects.
The structure could be developed across the entire organisation, facilitating the use of WMS for non-
Engineering Projects also.
3.2.2 Procedure
The procedure is split into the following sections:
 Work Breakdown Structure (WBS).

 Milestone Breakdown Structure.
 Organisational Breakdown Structure (OBS).
 Resource Breakdown Structure (RBS).
The Project Engineer shall break down the BI into manageable activities in accordance with the
WBS, identify the milestones and the resources required to execute these activities. The RBS shall
be used to identify particular activities in the Project plan which utilise key resources and which can
cause delays to over-commitment of such resources, for example, Contracts Section, In House
Design, Service Contracts.
3.2.3 Work Breakdown Structure (WBS)
Work Breakdown Structure (WBS) is a coding for all activities within a plan. The Project Engineer
shall code all the activities in accordance with the WBS which is the lowest level of data held in
WMS. Number of activities should be appropriate for the level of detail required, and should be kept
as small as practicable.
Estimates for Projects are done at the level of HCG. The HCG is directly related to Function Code,
and the Function Code is contained in the WBS as the 6 th and 7th character. Details of how the HCG
is related to Function Code is contained in the Cost Coding Manual. The project shall be broken
down into activities and the correct WBS assigned, so that backtracking to estimates can be done
easily, and when combined with the capex categorisation for the Budget Item, provides a complete
common communication language from Project inception to close-out for all those associated with
the Project as illustrated in Figure 2.
Work breakdown is the process by which the work of a Project is divided and sub-divided for
management and control purposes. WBS is the single most important tool for the engineer (or
anyone else involved with the Project) since it provides a common framework from which:
 The total Project can be described as a summation of subdivided elements.

 Budgets can be established.
 Time, cost and performance can be monitored.
 Projects can be linked to organisational resources.
APR 97
Page 16
The WBS is a 9 character code as shown below:
Project BI Function Code Analysis Code

3136 A 40 30
Project/BI
The first 4 characters refer to the Project number. (This was formerly called BI).
The next character refers to the Budget Item. (This was formerly called Sub-BI). This is a single
letter of the alphabet and is used to indicate the subdivision of a Project. Where a Project is of
sufficient size and/or complexity to warrant further breakdown, any alphabet can be used, except A
since A is used in EPCRIS for summarisation to the Project level. For Projects where the subdivision
is not required, default is A.
Function Code
The next 2 characters give the Function Code (FN).
The major Function Codes are as follows:
Function Code Function Description

00 Design & Engineering : general
10 Procurement : general
20 Construction : general
30 Commissioning : general
40 Engineer Procure & Construct : general
50 Other Charges : general
In the intermediate ranges, for example, 21-29, 31-39, etc., there are ‘specific’ Function Codes for
more detailed analysis. It enables the design data or procurement data to be aggregated for
reporting purposes. A detailed list of Function Codes is available as Appendix 1.
Analysis Code
The last 2 characters give the Analysis Code (AN).
The Project Engineer can use Analysis codes to further breakdown his BI, for example:
 To identify types of work such as Service Contract work.

 To identify in greater detail the elements of the cost estimate for that Activity.
 To monitor the work.
 To identify milestones.
 To identify Unit specific reporting requirements.
In cases where a defined unique Analysis code has been specified, such defined Analysis codes
must be used. The definition of Analysis codes can be Company wide or Unit specific. Details of
company wide unique Analysis codes are given in the Appendix II of this ERD. The codes listed shall
not be used for other purposes.
APR 97
Page 17
Given below is a schematic presentation of the WBS:
PROJECT
(e.g.96342)
Budget Item Budget Item Budget Item

(e.g. 6342A)
Function Code Function Code Function Code

(e.g.6342/A00)
Analysis Analysis
(e.g. 6342A0001)
3.2.4 Milestone Breakdown Structure
Milestone ‘activities’ have zero duration and zero resource. These milestone are used by the
Management to identify any slippage to the Project and to assess the impact on the Budget, and
production forecast. A different coding system is therefore applied to milestone in order to import
them into WMS, as follows:
Year Project BI Function Code Analysis Code

3 136 A 00 M2
List of standard milestones is available as a standard module on I:\PS6\STDNET.
3.2.5 Organisation Breakdown Structure (OBS)
This records the reference indicator of the Project Engineer with single point overall responsibility for
the BI. Summary reports based on OBS filters are possible at different levels of Dept., Unit, etc. from
WMS. Project plans need not contain the OBS for Activities, since the OBS of the BI is automatically
assigned to all the activities in WMS, while importing the plan from PS6.
3.2.6 Resource Breakdown Structure (RBS)
The RBS code consists of a maximum of 5 characters and is stored within PS6 and WMS in the
Resource Table. In order to make the use of RBS more effective, it is proposed to keep the
Resource Table as small as possible.
Resource constraint was identified as a reason for Project slippage. It was therefore decided to code
certain resources to ensure that potential bottlenecks within the business process are flagged and
appropriate action taken to avoid them. The resources available to the Company fall into two
categories, internal resources such as Project Engineers and Contracts Engineers, and external
resources such as design services and construction services. The coding will enable the workload of
an individual, a section or a complete department to be forecast. An up to date listing of the
resources is available as Resource Table in PS6.
APR 97
Page 18
The above resources will not have a value against them. They will only be utilised to forecast the
workload and reschedule activities to fit the available resources. Money will be input into PS6 and
imported into WMS for cost forecasting and financial monitoring of Projects through the resource
VOWD in units of US $ 1,000.
3.3 PLANNING OF BIS IN PS6
3.3.1 Introduction
After creating the BI, the only way to generate Activity plans and cashflow forecast in WMS is by way
of importing a PS6 plan. A plan in PS6 can be generated either by adding activities individually, or by
using the standard networks available on I:\PS6\STDNET. A detailed list of the standard networks is
available as Appendix I of PS6 Guide for Project Engineers.
3.3.2 Procedure
The Project Engineer is responsible for generating a PS6 plan for his BI in accordance with the
breakdown as explained in 3.2, and to identify the resources required to execute those activities.
3.3.2.1 Use of Standard Networks
The standard networks have been generated to reduce the input required from the Project Engineer,
and also to ensure standard coding of activities. The Project Engineer can easily generate a plan by
selecting the required modules from the standard networks available through PS6. These standard
networks contain the required WBS coding, but Project Engineer must assign the necessary
resources to the activities.
Details of the standard network modules and instructions on how to generate the plan are contained
in the PS6 User Guide.
3.3.2.2 Adding Activities
The Project Engineer may also generate a PS6 plan by adding activities. Each Activity has to have a
WBS code, and the resources required to execute the Activity should also be assigned in PS6. A
detailed information on how to generate a plan is available in the PS6 User Guide. The plan should
be stored on H:\ps6plan, since WMS is configured to look for the files on this directory.
3.3.3 Configuring PS6 for Export to WMS
The Project Engineer shall configure his PS6 plan for exporting data to WMS. The configuration
details are available in the PS6 User Guide. In summary,
1. In the Project list, input the BI No. (for example, 2394A) in the BI No. column.
2. Create the Import/Export Scenario
This will export the data automatically while saving the PS6 Project, making the plan available for
import into WMS.
APR 97
Page 19
3.4 GENERATION OF PLAN AND PHASINGS IN WMS
3.4.1 Introduction
After planning the BI in PS6, the plan must be imported to WMS to reflect the Activity schedule and
cost phasing in the system. When the data is imported into WMS, the data is known as Latest Cost
Forecast, and after the Project Engineer approves the import, the data is renamed as Latest Advised
Cost Forecast.
3.4.2 Procedure
The Project Engineer shall import the plan from PS6 to generate the plan and phasings in WMS. The
imported data is called LCF in WMS. Project Engineer should review the data in WMS, and modify
the PS6 plan and re-import until the data in WMS reflects his current forecast. Once he is satisfied
that the data in WMS is correct, he should approve the import. After the Project Engineer approves
the import, the LCF is known as LACF. LCF is available only for the Project Engineer to view, and
LACF can be viewed by any WMS user.
To import a BI into WMS, the Project Engineer will select the Open for Update option from the File
pull-down menu. After opening the BI for update, the Import is done by selecting the option Import
from the File pull-down menu. More details on the Import function is available in the WMS User
Manual. He will approve the Import by selecting the Update option from the Utilities pull-down menu.
3.4.3 Timing
The Project Engineer must update and import the PS6 plan at least once in a month for live BIs, to
incorporate any schedule changes, and to record the achieved VOWD. The import to WMS can be
done any number of times, but the import should be nearer the month-end, since the achieved
VOWD can more accurately be calculated at that time. For pending and long term budgets, the
Project Engineer may import the plan only when there is a change in the schedule or cost forecast.
APR 97
Page 20
3.5 APPROVING THE BI IN WMS
3.5.1 Introduction
Capital Project plans need to be aggregated at the Corporate level for presentation to Management
and Shareholders. This presentation to Shareholders, which is finalized at the Board Meeting in
October, is the process for obtaining approval of the Corporate Objectives which ultimately
determines the capital expenditure ceiling and profile for the planning period which extends five
years.
A Board meeting also takes place during March each year. This is the opportunity for pending
Projects, supplementary BIs or budget revisions to be presented for approval, hence the number of
items for approval is smaller than those in October.
Whenever a new budget or a revision to the existing budget is approved, the Project Engineer must
approve the BI in WMS, so that the system reflects the correct approved budget and expenditure
profile.
3.5.2 Procedure
The Project Engineer will carry out planning of all capital Projects via PS6. He will update WMS by
importing these plans from PS6. Capital Project expenditure phasing is derived, during the file import
function, from the resource profile, the start and end dates of the Activity and the data held on the
resource table in WMS.
Once the Project is approved by the Shareholders, the Project Engineer will approve the BI in WMS
to reflect the latest approved budget. When approving the BI in WMS, the start and end dates, the
expenditure profile, commitment profile and LACF will be frozen in WMS for each Activity. Although
latest Board approved budgets overview is maintained by the Planning Co-ordinators separately as
Targets, this budget approval shall be done by the Project Engineers so that RFA reflects the latest
Board approved budget.
3.5.3 Reporting
The Project Engineer has the facility to report his LACF against any of the ‘snapshots’ (original
approved budget, latest approved budget, etc.) using the presentation formats available in the View
or Table options in WMS. Using the Format – Target option the Project Engineer selects the
‘snapshot’ against which he wishes to report. In addition the Filter and Format functionality allows
the Project Engineer to select and summarise the data at different levels.
3.5.4 Financial Authorities
As the Project Engineer progresses his Project, changes may occur in the phasing and approved
total Project expenditure. If a change in Project phasing occurs the Project Engineer shall have his
revised Project plan approved by Management. Then it should be submitted to one of the Board
reviews mentioned above but may also be considered by Management upon the submission of an
RFA.
When changes to the total Project expenditure occur the Project Engineer should take the following
steps:
a. If two consecutive months, change to the LACF is less than $300,000 a budget proposal shall be
submitted for approval during the third month.
APR 97
Page 21
b. If the change in LACF is greater than $300,000 it must be approved by Management immediately
and submitted to the Shareholders for approval at the next Board review or as an Urgent
Decision request.
The System Custodian shall update CABCARS for budget revisions when approved by the
Shareholders and communicate to the FFP. The FFP will in turn advise the Project Engineer and
Planning Co-ordinator, and the Project Engineer will update PS6 and WMS with the latest approved
budget. The Planning Co-ordinator shall be responsible for updating the relevant snapshots in WMS.
3.6 GENERATION OF LEDGER-CODES
3.6.1 Introduction
During the execution of the Project, ledger-codes have to be generated by the Project Engineers,
since commitments can be made only against ledger-codes. The ledger-codes will be generated in
EPCRIS through WMS. Once the ledger-code is activated by the FFP in EPCRIS, the Project
Engineer can start to raise Requisitions, issue IWRs, etc.
Ledger-code is a 14 character code, and is created by attaching the account code to the WBS.
3.6.2 Procedure
After importing the PS6 plan into WMS, the Project Engineer shall create the ledger-code in WMS by
selecting the Activity from the Table, Activity, and choosing the CTR and attaching the account code.
Details on creating the ledger-codes is described in the WMS User Manual. Since the interface to
EPCRIS is run every day, the new ledger-code gets transferred to EPCRIS the same day. These
ledger-codes are created in EPCRIS with the status ‘Closed’, and FFP will change the status to
‘Open’ against an approved RFA. Project Engineers can start making Commitments only against the
ledger-codes which have the status ‘Open’.
The Project Engineer shall not create ledger-code against contingency, since any contingency will be
used only after re-allocating against the activities where money is required.
3.6.2.1 Generation of Additional Ledger-codes
When additional ledger-codes are required, the Project Engineer will create a new Activity in PS6,
import the data to WMS, and complete the process described in Section 3.6.2. If the new ledger-
code is created by breaking down an Activity against which RFA is already approved, the Project
Engineer can send to the FFP the CTR sheet for the new Activity indicating the reason for ledger
code activation. The FFP shall activate the ledger code if satisfied with the justification.
3.6.2.2 Change of Account-codes
Since the account-codes depend on the type of job and the contractor, it is possible that an existing
account code has to be changed. When such a change is required, the Project Engineer will agree
with the FFP and request the Planning Co-ordinator to effect the change. Upon generation of the
ledger-code in EPCRIS, the FFP shall close the old ledger-code and open the new ledger-code. FFP
shall also raise a Journal Voucher to transfer any costs to the new ledger code in EPCRIS.
APR 97
Page 22
3.6.3 Reporting
A user can customize a table by selecting Define Table option under Table to list all ledger-codes in
WMS for the data opened by the user. Base table should be Activity Table, and the fields Account
Number, Code and Short Title should be assigned.
3.7 GENERATION OF RFA
3.7.1 Introduction
During the Project, RFAs have to be raised by the Project Engineer and approved by Management
as and when funds are required for commitment. Purpose of the RFA is to present the latest scope,
structure and financial phasings of the Project to allow Management a final review before
commitments are made. It is also the mechanism for the FFP to activate ledger codes.
The Project Engineer should raise the RFA against a BI only after the budget proposal is approved.
RFA will present the data derived from the detailed Activity plan prepared in PS6, and imported to
WMS. The Project Engineer shall add the relevant text to the standard template, print out the RFA
and obtain approval from his Team Leader. He should then send it to the FFP for circulation and
authorisation as per the Manual of Authorities. When the RFA is circulated by FFP, the Project
Engineer will issue the RFA in WMS.
Once the RFA has been approved, the FFP shall input the RFA values and set the ledger code
status to open in EPCRIS. Only then can the Project Engineer make commitments against his BI.
The FFP informs the Project Engineer that RFA has been approved and the ledger codes are open.
The Project Engineer shall then authorize the RFA in WMS.
The Project Engineer should not include contingency Activity in the RFA. If the contingency is to be
used, the Project Engineer must reallocate the contingency against the activities where money is
required, and then raise the RFA.
3.7.2 Procedure
3.7.2.1 Generating the Project Phasings
The expenditure phasings are derived by WMS during the File Import function, from the VOWD
resource profile and start and end dates from the PS6 plan. These phasings are summarised and
presented on the RFA annually.
3.7.2.2 Creating the RFA
The Project Engineer is responsible for raising the RFA from WMS. Following are general guidelines
for raising an RFA.
a. For Projects with a value less than the Director’s Authority level (currently US$ 1 Million), only
one RFA shall be prepared covering all activities.
b. For Projects with a value more than the Director’s Authority level, one RFA shall be raised with
Revisions, following the general principles as below:
Revision A – Design and Long Lead Items.

Revision B – Bulk Materials and Construction.
Revision C – Commissioning and Reallocation of Funds.
APR 97
Page 23
These are general guidelines and if more or less than 3 revisions are required, they should be
generated accordingly.
The RFA No. to be used is always 1, since new RFA will not include any activities included in the
previous RFA, whereas the RFAs are expected to show the full status of the BI. Therefore, when
additional funds are required, a new Revision must be raised, and not a new RFA.
3.7.2.3 Assigning Activities
The Project Engineer shall input the text fields and indicate the signatories before assigning activities
for which he wants to release funds. Activities can be assigned only once and funds should be
released for the total value of the Activity. If funds are to be released for the Long Lead Items and
not the total procurement budget, the Project Engineer should have at least two separate activities on
his plan. After assigning activities, the Project Engineer will print out the RFA, obtain the Team
Leader’s approval and hand over the RFA alongwith the VOWD report and PS6 Gantt Chart to the
FFP for circulation.
3.7.2.4 Circulating the RFA
The FFP should check that the latest approved budget is correctly reported on the RFA and agrees
with CABCARS. If LACF is different from the approved budget, the FFP shall ensure that the
differences are explained in the text. The FFP should contact the Project Engineer to determine if a
budget revision is necessary. The FFP shall ensure that the list of signatories is in line with the
Manual of Authorities.
The FFP shall retain a copy of the RFA while the RFA is under circulation and it shall be recorded in
the RFA Control Register.
3.7.2.5 Issuing the RFA
Once the FFP circulates the RFA for Management approval, the Project Engineer will choose the
button Issue from the RFA screen. This is to freeze the RFA so that any further change to the LACF
will not alter the RFA figures in the system. If the RFA is returned by the Management for any
alteration, the RFA can be modified by choosing the button Revise from the RFA screen.
3.7.2.6 Authorising the RFA
After the Management approval, FFP will send a copy of the RFA to the Project Engineer. The
Project Engineer should then input into the RFA screen the date of approval and choose the button
Authorize. If this authorization is not done, the next revision of the RFA will now show the previously
released funds.
APR 97
Page 24
3.7.2.7 Signatories to the RFA
Following is the list of signatories for approving the RFAs based on the current levels of authority:
Dept.
RFA Amount Manager Director OGD MD
Head
Upto $ 100,000 X
Upto $ 500,000 X X
Upto $ 1,000,000 X X X
Upto $ 20,000,000 X X X X
Unlimited X X X X X
Note: The authority levels mentioned above is correct at the time of printing this ERD – Consult latest
Manual of Authorities available with FFP for any revision to the authority levels.
3.7.2.8 Activation of ledger-codes
After authorisation, the RFA is returned to the FFP who shall check that the signatures are in
accordance with the Manual of Authorities. Once the FFP is satisfied that the RFA has been properly
authorised, he will input RFA values to EPCRIS and activate the ledger-code.
3.7.3 Filing
The FFP should send a copy of the RFA to the Project Engineer, and retain the original authorised
RFA with attachments in the Project file. The Project Engineer shall file his copy of the RFA for
future reference. WMS also retains a history in alphabetical sequence on the approval of RFAs.
APR 97
Page 25
3.8 COMMITMENT CONTROL
3.8.1 Introduction
Commitments are primarily required as part of the budgetary control process to provide Management
and Budget Holders with information to assist them in containing expenditure within approved limits
and in estimating the Latest Advised Cost Forecast (LACF). There is no Statutory or Group reporting
requirement to maintain commitment data as a Project progress measure.
WMS will report both planned and actual commitment values based on the assumptions the engineer
has included in his detailed plan in PS6.
Planned commitments are calculated in WMS when the File Import function is selected. The total
value of the VOWD resource will be recorded as the commitment on the start date of the Activity.
When the Board Plan has been approved by the shareholders the commitment data in WMS is saved
and stored as Target Plans by the Planning Co-ordinators, for comparisons against actual progress.
Actual commitments can be recorded by the Project Engineer on an on-going basis. Two options are
available to the Project Engineer for recording actual commitments:
a. automatic update from the import of the progressed plan.

b. Select the manual input option and update by recording commitments in the commitment log.
To assist the Project Engineer in determining actual commitments, data from EMA is available in
WMS for reference purposes. EPCON can be queried for lumpsum contracts commitments, and EZ
for Service contract commitments.
3.8.2 Procedure
The Project Engineer may control commitments in WMS at Activity level, which is the lowest level in
WMS. Without any additional effort from the Project Engineer, WMS calculates the forecast
commitment and actual commitment from the data imported from PS6. Total value for the Activity is
forecast for commitment on the start date of the Activity. When activity is progressed, the total value
is recorded as actually committed on the actual start date of the Activity. This is the automatic
update option mentioned in 3.8.1 above, and the minimum requirement expected of the Project
Engineer.
If the Project Engineer desires, he can control commitments in WMS at a detailed level. By selecting
the manual commitment option, he can record the commitments when contract is awarded, when
there is a call off on Service Contractor resources or when procurement activities commence.
Commitment data from the nightly interface with EMA is available for view to assist the Project
Engineer with the update of actual commitments. In addition the actual payments from the monthly
interface with EPCRIS are also available for view to the Project Engineer.
3.8.3 Reporting
When the month end process has been completed the Project Engineer should run his cumulative
tracking report from WMS and investigate significant variances between plan and actual
commitments. In addition the FFP should produce a monthly report to compare latest approved
budget, funds released, value committed and VOWD.
APR 97
Page 26
3.9 VOWD REPORTING
3.9.1 Introduction
Users of the financial statements (example Shareholders, Management, Budget Holders) require that
these statements reflect the cost of actual work done whether or not the related charges have been
processed. For this purpose, the Project Engineer reports the achieved VOWD in PS6 and import to
WMS. The VOWD reported in WMS is compared with the actual payments in EPCRIS, and accruals
are made in EPCRIS for the difference.
As a result, VOWD is the one common measure of progress applied to all Projects in WMS.
Planning the value of work done and later monitoring actual VOWD against this plan is one of the
main tools for a Project Engineer to report progress on his Project.
For these reasons it is essential that VOWD is correctly planned and later reported by all Project
Engineers.
In-house activities like Project development and management activities, commissioning etc. Are not
costed and so do not contribute to measured VOWD. Project Engineers salaries and other overhead
charges will be charged to the Asset directly at the year-end by the FFP. In view of the importance of
VOWD it is recommended that the Project be broken down into sufficient detail in accordance with
the coding procedure mentioned in Section 3.2
WMS will transfer the VOWD input by the Project Engineer to EPCRIS every month. A matching
process of actuals to-date in EPCRIS and VOWD in WMS will generate necessary accruals in
EPCRIS. It should be noted that this accrual will be generated only if the VOWD is greater than
actuals to-date in EPCRIS.
3.9.2 Procedure
As stated in the introduction, monitoring and reporting of VOWD is one of the key activities for a
Project Engineer.
Estimating VOWD at any time will never be a precise mathematical exercise, however it must be
based on some auditable measurement. The technique of applying a simple percentage based on
contract duration. Example a contract has been running 3 months out of 9 months therefore the work
is 33% complete, is unacceptable. It may be the case but this needs to be demonstrated.
Some acceptable methods to estimate VOWD are:-
a) A review and estimate, by the Project Engineer or his representative, for Projects where there
are many short duration activities and where scope for error is minimal.
b) A report produced by the consultant or contractor based on accurately defined weighted progress
measuring the schedule of man hours, requisitions, drawings delivered, length of pipe installed,
etc.
c) The Project Engineers own accurately defined and weighted progress measuring schedule
based on deliverables as above.
d) The value of materials delivered, from the materials tracking sheet.
The Project Engineer should retain in the Project file all supporting documentation used to determine
VOWD as a suitable audit trail, should any follow-up or query need to be answered.
APR 97
Page 27
3.9.2.1 LACF
At every up-date of VOWD, the Project Engineer should estimate the value of work which still
requires to be done and add this to the VOWD to give the LACF. The first indication of increases will
be:
a) if actual commitments are greater than the approved planned commitments

b) if a significant scope increase is made
c) if expenditure reported from materials is greater than planned, without compensating
decreases elsewhere.
If the LACF is higher than the approved budget, the Project Engineer should report this to the Team
Leader who will determine if budget adjustments should be requested, that is are over-forecasts
significant or firm enough or if potential Project economies should be pursued. It should be
remembered that historically at around 60% of Project progress the LACF is often estimated higher
than the final Project cost eventually turns out to be.
3.9.3 Controls and Reporting Requirement
As VOWD is a fundamental accounting concept, controls need to be in place to ensure the integrity
of the figures in EPCRIS. To achieve control over the accruals, the following reports will be
generated from WMS/EPCRIS interface:
a) An exception report which shows current month accruals per Project (users FFPs, PEs, Planning
Co-ordinators).
b) A report showing invalidated accounts. The FFPs will open the accounts and follow up entries
during the month for appropriate action.
c) An exception report of activities where EPCRIS is higher than the VOWD. The Planning
Co-ordinator will provide a copy of this report to the Project Engineers. The Project Engineer will
be responsible for reporting the correct VOWD.
Planning Co-ordinator should distribute the reports. The reports will be distributed in the morning of
3rd working day of the month, and FFPs and Project Engineers will have a full day to review the
exception reports and take appropriate action, as follows:
a) The Project Engineer shall update PS6 and import to correct all exceptions where VOWD
reported by Project Engineer is lower than Actuals.
b) The Project Engineer shall review the accruals report and where the accrual is incorrect, he
should modify PS6 and import to reflect the correct VOWD.
3.9.4 Timing
Project Engineers will update WMS before the end of the 2nd working day in each month, and the first
month end processing will be done at the end of the 2 nd working day. The Planning Co-ordinators will
distribute the reports in the morning of the 3rd working day to the Project Engineers and FFP to take
appropriate action. After the Project Engineers update the WMS, the Planning Co-ordinators will do
the final month end processing on the 4th working day of the month by 13.00 hrs.
3.9.5 Financial Authorities
As the Project Engineer progresses his Project, deviations may occur from the approved phasing and
total approved budget. Financial authorities require that Project Engineers submit this change to one
APR 97
Page 28
of the two Board reviews for approval. If a change in Project phasing occurs the Project Engineers
must have his revised plan approved by Management.
3.10 PROJECT CLOSING
3.10.1 Introduction
Within a maximum period of 3 months from physical completion of the Project, the Project Engineer
has to ensure that all costs such as final service contract charges and late costs on materials are
charged and As-Built Drawings are complete so that the PCC can be raised.
Project surplus materials may either be transferred to the Project Surplus stock or to another Project.
Since SIEP invoices can be received three to six months in arrears, the Project Engineer shall
confirm any outstanding charges (a copy of the reply from SIEP shall be attached to the PCC). In
exceptional circumstances there may be claims outstanding against the Project in which case this
should be reported on the PCC. The FFP shall only approve the PCC when satisfied that these are
the only costs outstanding. If any other charges are still being processed the Project is deemed not
complete.
At the end of the year the FFP shall notify the Assistant Accountant Capital Budgets and the System
Manager the Projects which are to be closed in CABCARS and WMS. The closed Projects will
appear as Work in Progress in the FAR. The Fixed and Moveable Assets Accountant shall transfer
the WIP to completed Projects in the FAR after receiving the PCC.
3.10.2 Procedure
When a Project is physically complete the Project Engineer shall ensure that the financial close out of
the Project is also complete before a PCC is raised. Physical completion of the Project includes the
delivery of As-built Drawings and return to Project stock of any company materials in Contractor
custody. A Project should not be closed where there are any outstanding activities to be carried out
since it is difficult to forecast the outstanding charges and the Project completion date.
The FFP is responsible for communicating to the Assistant Accountant Capital budgets and the
System Manager the list of closed BIs to close them in both CABCARS and WMS at year end.
Unless the Project Engineer needs them for future reference, he will agree with FFP and request the
System Manager to delete the closed BI from WMS. Under any circumstances, the Projects will not
be retained in WMS after they are deleted from CABCARS.
3.10.2.1 Treatment of outstanding costs.
The PCC will incorporate details of SIEP service charges as per the telex, and any probability of
claims. It is the Project Engineer responsibility to ensure there are sufficient funds in his budget to
cater for these late costs. After the PCC is approved, FFP will close in EPCRIS all ledger codes, with
the exception of ledger codes for the outstanding charges and CAR Insurance which shall be closed
after the year-end exercise. If the settlement of a claim is expected to take some time the Project
Engineer shall inform the FFP who shall inactivate the ledger codes and only when the claim is
settled shall the FFP open the ledger codes. Immediately after the costs have been booked FFP
shall close the ledger codes.
3.10.2.2 Treatment of surplus Project materials
When a Project Engineer has identified surplus Project materials, which can be utilised on another
Project, the Project Engineer shall transfer these materials to the receiving Project at the original
APR 97
Page 29
cost. The FFP will pass a credit to the originating Project, and charge the receiving Project for the
same amount.
For the materials which are deemed to be surplus at completion of a Project, stock items will be
returned to the general stock at the cost price. For non-stock items, the cost up to a maximum of 5%
of the total Project cost will remain with the Project for which the materials were procured. The
materials shall be transferred to Surplus Project Stock zero value and any subsequent transfers to
other Projects would also be at zero value.
Surplus Project Materials in excess of 5% of total Project cost shall follow the write-off procedure.
Only the incremental cost is considered for write-off, that is, the cost up to 5% remains with the
Project for which the materials were purchased. When the write-off has been authorized by the Write
Off committee the materials shall be transferred at zero value to Project surplus material stock.
Before Surplus Project Materials will be accepted in Supply Department they must be accepted by
the relevant CFDH. The Project Engineer shall obtain on the PCC signature of the CFDH as
agreement to take the materials into Project Surplus stores and ascribe a technical ‘use by date’.
The value of surplus materials whether within or outwith the 5% limit shall be clearly documented on
the PCC by the Project Engineer and presented to the relevant Unit Development Manager for
approval. It shall be the Unit Development Manager’s responsibility to challenge the reason for and
the amount of surplus materials.
3.10.2.3 Project to Project transfers
For Project Surplus Materials that will be transferred between Projects, there must be an authorised
budget with funds released and available for commitment on the receiving Project. The surplus
materials shall be transferred at Original Cost to the receiving Project. The originating Project
Engineer should raise a memo to Supply Department, and copy to FFP, with the details of the
transfer.
3.10.2.4 Write off proposal
When material identified as surplus to the Project has not been accepted as surplus by the CFDH or
when the value is greater than 5% of the total material value in the Project, such material should be
written off. A Write Off Committee will assess and authorise the recommendations presented on the
write off proposal.
The Project Engineer shall present the write off proposal, and distribute the proposal to the fixed
Moveable Assets Accountant for update of the FAR.
3.10.2.5 Project performance indicator
The Project Engineer shall also report in the PCC the original Budget, the Project value at close out,
the target completion date on the ADP and the actual completion date. These statistics must be
provided as they are used by Unit Planning & Economics to report performance indicators to
Management.
3.10.2.6 Fixed Asset Register
The Project Engineer shall also complete the Asset Acquired section on the PCC. The information
required is detailed below and will subsequently be used by the Fixed and Moveable Assets
Accountant for updating the FAR.
APR 97
Page 30
Field Requirements
New, replacements, modification, or an addition to existing
Type of Assets Acquired
asset.
Location The exact geographical location.
The use of codes to classify an asset based on its function,
Asset Class
that is, oil and gas pipelines (08).
Asset Description Based on the description of work in the budget proposal.
3.10.2.7 Project archive
When the Project is physically complete, and necessary arrangements have been made to accrue for
outstanding financial commitments, the Project Engineer will raise necessary PCC. At the year end
the FFP shall notify the System Manager and the Assistant Accountant Capital Budgets on all
Projects to be closed. The FFP will ensure that the PCC has been raised and approved for those
Projects to be closed. If the PCC has not been received the Project shall not be closed.
In WMS there is no provision to archive the data for any future reference. Therefore, the Project
Engineer may choose either of the following 2 options:
a) If the Project is required for any future reference, the Project will be transferred to the FFP’s
Work Group. This is done in order to avoid any further update by the Project Engineer, and
thereby generation of accruals.
b) If the Project is required for any future reference, System Manager will be requested to delete the
Project from WMS, to avoid any future accruals and exception reports.
Concurrent with the closure in WMS the Assistant Accountant Capital Budgets shall close them in
CABCARS. Subsequent interface from CABCARS will change the status in EPCRIS to closed. FFP
shall be responsible to change the status of ledger-codes to ‘closed’.
3.10.2.8 Movement on closed Projects
When costs are incurred on a closed Project an explanation has to be reported to Management. The
FFP shall liaise with the Project Engineer to establish why the costs have been incurred and to
determine if the ledger codes can be closed. The costs incurred on a closed Project should be small
since the majority of costs should have been processed before closure of the Project.
3.11 SYSTEM INTERFACES
3.11.1 Introduction
In order to maintain consistency of data, to avoid duplication in data entry, and with the aim of giving
all the Project related information from WMS, some interfaces have been designed with various
systems. Depending on the requirements, these interfaces are run daily, weekly or monthly.
There are standard interface reports to highlight any discrepancies, and the System Manager shall
be responsible to take appropriate action on these reports. Nevertheless, if any data irregularity is
noticed by the users, it should be brought to the notice of the System Manager so that he may
investigate and either explain the reasons thereof, or get the interface programme fixed to remove
such errors.
A schematic presentation of these interfaces is available in Appendix 3 of this ERD.
APR 97
Page 31
3.11.2 Procedure
As explained above, the interfaces are designed for the convenience of users and to maintain data
consistency. Following are the details of interfaces with WMS.
3.11.2.1 BI interface
FFP generates necessary Projects in CABCARS. Instead of creating them manually in WMS, an
interface is designed from CABCARS to generate new BIs and to update any existing BIs in WMS.
This interface is scheduled to run weekly.
3.11.2.2 Ledger-code interface
Project Engineer plans his Project in PS6, indicating the WBS for each of the activities. The plan is
then imported into WMS, and Account Codes are attached to the required activities, to generate
ledger-codes. Instead of creating these ledger-codes manually in EPCRIS, an interface has been
designed to run daily, which will transfer the ledger-codes electronically to EPCRIS.
3.11.2.3 VOWD Interface
At the end of each month, the Project Engineer shall update PS6 and WMS and the Planning Co-
ordinator shall carry out the month-end processing. This will generate a file of all the ledger-codes
with the achieved VOWD, as reported by the Project Engineer. This VOWD is then compared with
ledger actuals in EPCRIS, and accrual generated for the difference between VOWD and ledger
actuals where VOWD is higher. Exceptions of VOWD lower than ledger actuals is reported to the
Project Engineer. This process takes place normally on the 4th working day.
3.11.2.4 Ledger Actuals Interface
The VOWD interface, as explained in 3.11.2.3 will generate accruals in EPCRIS. Soon after the
month-end reporting in EPCRIS is finished, these accruals will be removed from EPCRIS, to start the
next book-month. Immediately after removal of accruals, a file will be generated from EPCRIS of all
Engineering ledger-codes and payments to-date. This file is then run into WMS. This interface is
scheduled for the 3rd week of the month.
3.11.2.5 Materials interface
Data related to the ordering and delivery of materials, along with the financial information, is captured
in EMA. In order to make this data easily available to the Project Engineers, an interface has been
designed from EMA to WMS to run daily. The daily interface will update the existing data in WMS,
and the weekly interface will create any new requisitions in WMS.
3.11.2.6 Capex phasing
In order to update ECAR with the latest forecasted phasing of Engineering BIs, an interface has been
designed from WMS to run ad-hoc, at the request of ECAR Custodian. This interface will create any
new BIs, and existing BIs in ECAR.
APR 97
Page 32
3.12.1 Introduction
WMS is the system to manage Engineering Projects of Capital Expenditure. The system contains all
the planning and financial data related to these Projects. Therefore, some reports have been
designed in the system to assist in Management reporting.
WMS is an on-line system, and the system is accessible by the Management for query. There is
considerable flexibility in designing new reports. However, in order to maintain standard in reporting,
and to help general users to view these reports quickly, Planning Co-ordinators shall generate some
reports and freeze them in WMS immediately after the month-end processing.
3.12.2 Procedure
WMS is capable of producing Graphical and Tabular reports, with the flexibility for the users to
choose different data in various formats. Additionally, the system stores the last Board approved
Budget and phasing data. Therefore, some standard reports have been identified and included in the
system. The Planning Co-ordinator shall produce and freeze these reports in WMS. Any user can
view these reports, without opening any data in WMS. These reports are printed by the Departments
and, along with some additional tabular reports from WMS and additional descriptive information, are
complied into a Monthly Report for distribution to the Management.
3.12.3 Project Status
During the monthly update, the Project Engineer should input into WMS any concerns and status of
the Project. These texts should be input in Table, Work Catalogue, Budget Item screen against
‘Status’.
3.12.4 Generation of monthly reports
Each area team has nominated a focal point to produce their monthly reports. These focal points
shall print out the graphical reports generated by the Planning Co-ordinators, print the following
additional tabular reports from WMS and include in their monthly reports :
a) Activity table at BI level, sorted on Project Engineer.

b) VOWD period table at BI level, with the latest target, sorted on Project Engineer
c) Milestone report, with the latest target.
3.12.5 Timing
The Planning Co-ordinators shall generate the graphical reports on the 5 th working day, that is, the
day after the month-end processing is done.
APR 97
Page 33
4 PROCEDURES FOR PLANNING CO-ORDINATORS
4.1 CREATION OF BUDGET ITEM IN WMS
4.1.1 Introduction
CABCARS is the corporate capital budget control, administration, and reporting system through
which capital budget information is entered, at the Project level, validated and updated interactively
on-line. The database is primarily updated, as part of the two Board exercises each year, with
corporate capital budget data for the next five year period.
WMS is the database for controlling and reporting of engineering capital budgets, at the BI level.
In order to maintain consistency between the two databases and to ensure that all Capital Projects
will continue to be recorded by one Corporate System an interface has been built between
CABCARS and WMS for the generation of BIs into WMS. The main mechanism for creating new
Projects in WMS will be through this interface with CABCARS.
Each new Project will also have Budget Item created in WMS by the interface. The BI will have the
description of the Project and a number by dropping the first character of the Project number and
adding suffix ‘A’, for example the CABCARS Project number 96785 will create in WMS BI 6785A.
Project Engineer can break down his Project into more BIs with different Project Engineers
responsible for each of BIs. The Project Engineer has to provide the Planning Co-ordinator with the
Project number, BI number, PE and title to set-up the BIs. BI title can be a maximum of 40
characters.
4.1.2 Procedure
If the Project is broken down into more than 1 BI, the letter A should not be used for any BI, since
EPCRIS uses the letter A for Project summarisation. When the Project Engineer identifies the need
for breaking down the Project, the Planning Co-ordinator shall generate the new BIs in WMS at the
request of the Project Engineer. The planning Co-ordinator would require the following information:
Project number
BI number
BI title
Project Engineer
Business Unit
Work Group
Work Type 1
Work Type 2
Area
Field
4.1.2.1 Data requirement
While data for the first 4 fields will be provided by the Project Engineer, the Planning Co-ordinator will
derive the 1st character of the PE to be the Business Unit, and the first 3 characters of the PE to be
the Work Group. The Planning Co-ordinator shall query WMS for the last 4 codes from the Table,
Work Catalogue, Budget Item, Details screen for the BI A.
APR 97
Page 34
4.1.2.2 Creation of the BI in WMS
After creating the BIs as required, the Planning Co-ordinator shall confirm to the Project Engineer.
Once the Project Engineer imports the PS6 plan, he will request the Planning Co-ordinator to set the
target. The Planning Co-ordinator should verify that the total of all the BIs under that particular
Project agrees with the Approved budget and phasing, and then set the target. For details on setting
the target, please refer to Section 4.2 - Management Board Approved Targets.
4.2 MAINTAINING BOARD APPROVED TARGETS
4.2.1 Introduction
Capital Project plans need to be aggregated at the Corporate level for presentation to Management
and Shareholders. This presentation to Shareholders, which takes place in October at a Board
meeting, in the process for obtaining approval of the Corporate Objectives which ultimately determine
the capital expenditure ceiling and profile for the planning period which extends five years.
A Board meeting also takes place during March each year. This is the opportunity for pending
Projects, supplementary BIs or budget revisions to be presented for approval, hence the number of
items for approval is smaller than those in October.
For the reviews at these meetings, capital Projects need to be aggregated at a Corporate level to
ensure that the Company is meeting its Objectives. The Project plan data therefore has to be a
frozen so that comparisons can be made between the Project Engineers LACF and budgets
approved at the last Shareholder meeting.
4.2.2 Procedure
The Project Engineer will carry out planning of all capital Projects via PS6. He will update WMS by
importing these plans from PS6. Capital Project expenditure phasing is derived, during the file import
function, from the resource profile, the start and end dates of the Activity and the data held on the
resource table in WMS. Planning Co-ordinator is responsible to maintain the Board approved targets
in WMS. When freezing target data in WMS, the start and end dates, the expenditure profile,
commitment profile and LACF will be held for each Activity.
4.2.2.1 Board Plan
When a capital Project is first raised it will be presented to one of the Board Meetings for approval
and hence form part of the Corporate Baseline. The Concept Engineer is responsible for creating the
initial plan and writing the budget proposal. When the plan has been created in PS6 and the data
imported to WMS the expenditure phasing for the Project will be derived automatically.
In addition to the new capital expenditure Projects proposed by the Concept Engineers it may be
necessary for the Project Engineer to submit a revision to existing Projects. The Project Engineer is
responsible in this case for revising the Project plan, importing to WMS and preparing the Budget
Proposal. Planning Co-ordinator shall coordinate with FFP and freeze the targets during the planning
cycle so that the new Projected Corporate expenditure can be derived and presented for approval by
Management and Shareholders.
When approval has been received from both parties the data will be saved as a “snapshot” in WMS
and referred to as either the October Board Plan or the March Board Plan.
APR 97
Page 35
4.2.2.2 Freezing the data
The Planning Co-ordinator shall be responsible for ensuring that the Project Engineer is aware of the
various reporting deadlines set by Management, and that the Project Engineer has imported,
reviewed and approved his submission to WMS.
Once the BIs are created in WMS by the interface, the PS6 plans will be imported by the Project
Engineer. When the Planning Co-ordinator is satisfied that all Projects have been updated in line
with the outcome of the Directors review, the Planning Co-ordinator will freeze and save the data
using the correct description that is 96March Board Plan, etc. When the data has been frozen the
FFP will run reports detailing the expenditure phasing so that CABCARS can be updated.
Any changes requested by Management or the Shareholders after the data has been frozen shall be
communicated by the FFP to the Planning Co-ordinator. The Project Engineer shall update the plan
in WMS, and the Planning Co-ordinator shall re-set the snapshot. Once the data has been approved
by the Management and the Shareholders, no changes to the data shall be incorporated.
4.2.3 Timing
Immediately after the Team Leaders review, the FFPs will generate the Project in CABCARS. Once
the BIs are created in WMS by the interface, the Project Engineer shall import the PS6 plans into
WMS. The Planning Co-ordinator shall verify that the imported data is in line with the approval and
freeze and save the data into the Board Plan. Timing for the initial freezing of target is as follows:
March Board in January, after the December month-end processing

October Board in July, after the June month-end processing.
4.2.4 Reporting
The Project Engineer has the facility to report his LACF against any of the “snapshots” mentioned in
4.2.2.1, using the presentation formats available in the View or Table options in WMS. Using the
Format - target option the Project Engineer selects the “snapshot” against which he wishes to report.
In addition the Filter and Format functionality allows the Project Engineer to select and summarize
the data at different levels.
4.3 MONTH-END PROCESSING
4.3.1 Introduction
Users of the financial statements (example Shareholders, Management, Budget Holders) require that
these statements reflect the cost of actual work done whether or not the related charges have been
processed. For this purpose, the Project Engineer reports the achieved VOWD in PS6 and import to
WMS. The VOWD reported in WMS is compared with the actual payments in EPCRIS, and accruals
are made in EPCRIS for the difference.
As a result, VOWD is the one common measures of progress applied to all Projects in WMS.
Planning the value of work done and later monitoring actual VOWD against this plan is one of the
main tools for a Project Engineer to report progress on his Project.
WMS will transfer the VOWD input by the Project Engineer to EPCRIS every month. A matching
process of actual to-date in EPCRIS and VOWD in WMS will generate necessary accruals in
EPCRIS. It should be noted that this accrual will be generated only if the VOWD is greater than
actuals to-date in EPCRIS.
APR 97
Page 36
4.3.2 Procedure
As stated in the introduction, the VOWD reported by the Project Engineer is transferred to EPCRIS to
create necessary accruals.
4.3.2.1 First Month-end processing
On the 2nd working day of the month, System Manager will confirm from the EPCRIS custodian and
advise the Planning Co-ordinator that EPCRIS is ready with all the actuals. The Planning Co-
ordinator will identify any BIs that are not updated by the Project Engineers, and inform the Project
Engineers and Team Leaders. Before the end of 2 nd working day, the Planning Co-ordinator will
carry out the Month-end processing for the Work Groups under his responsibility.
On the 3rd working day at 0700 hrs., the System Manager will run the EWMSVOW1 job, which will
produce various reports.
The first month-end processing does not generate the accruals in EPCRIS, but only reports all
accruals that will be generated. This gives the Project Engineer a final chance to review his VOWD
and make any corrections.
4.3.2.2 Responsibilities
The FFP will review these reports, and investigate the reasons for accruals, with special focus on
accruals above $500,000. FFP will discuss with the Project Engineer any accruals on inactive
ledger-codes, and either request the Project Engineer to remove the VOWD, or activate the ledger-
code.
The Planning Co-ordinator will modify the Time Now for all the BIs under his Work Groups to 1 month
back, so that the Project Engineers may import his updated plans into the current month. Failure to
do this will either reject the import or post the updates into the next month.
The Project Engineer will review the accruals reported, and make any corrections before 1200 hrs.
On the 4th working day. On a monthly basis, any instance where VOWD is under-reported must be
corrected by the Project Engineer. Any such exceptions during the year-end will result in the budget
and/or phasing to be incorrect in WMS.
4.3.2.3 Final Month-end processing
On the 4th working day of the month, Planning Co-ordinator shall ‘Re-run’ the month-end processing
in WMS at 13.00 hrs. Extreme care should be taken to ensure that he selects ‘Re-run’ option, as
otherwise wrong VOWD will be interfaced to EPCRIS. Since the files must be transferred to IBM at
14.00 hrs., and the Unix clock may not reflect the correct time, ‘Re-run’ must be finished latest by
13.45 hrs.
On the 4th working day at 14.15 hrs., the System Manager will run the EWMSVOW2 job, which will
produce accrual file for EPCRIS, and some reports.
4.3.3 Reports
Both the above jobs will produce various reports. System Manager will verify that the correct files
have been picked up by the jobs, and hand over these reports to the Planning Co-ordinators.
APR 97
Page 37
4.3.3.1 Reports from First Month-end processing
The Planning Co-ordinator will distribute the reports from the first month-end processing as follows:
Planning
Project
Reports FFP Co-
Engineer
ordinator
WMS cost lower than EPCRIS
X X X
cost
Overview of all generated
X X X
accruals
Accruals above $500,000 X X
4.3.3.2 Reports from Final Month-end processing
Following is the list of recipients of the reports from the final run:
Planning
Project
Reports FFP Co-
Engineer
ordinator
WMS cost lower than EPCRIS
X X
cost
Overview of all generated
X X
accruals
Accruals above $500,000 X X
Summary of Accruals X
The Planning Co-ordinator should hand over the reports from the final run to the FFPs, since these
reports are only for information. FFPs will distribute them to the Project Engineers along with the
monthly reports from EPCRIS.
The System Manager shall inform the EPCRIS Custodian the number of accruals and total amount of
accrual, latest by 14.30 hrs.
4.4.1 Introduction
WMS is the system to manage Engineering Projects of Capital Expenditure. The system contains all
the planning and financial data related to these Projects. Therefore, some reports have been
designed in the system to assist in Management reporting.
WMS is an on-line system, and the system is accessible by the Management for query. There is
considerable flexibility in designing new reports. However, in order to maintain standard in reporting,
and to help general users to view these reports quickly, Planning Co-ordinators shall generate some
reports and freeze them in WMS immediately after the month-end processing.
APR 97
Page 38
4.4.2 Procedure
WMS is capable of producing Graphical and Tabular reports, with the flexibility for the users to
choose different data in various formats. Additionally, the system stores the last board approved
budget and phasing data. Therefore, some standard reports have been identified and included in the
system. These reports will be produced by Planning Co-ordinators and frozen in WMS.
As soon as the final month-end processing is finished on the 4th working day, the Planning Co-
ordinators for each Unit will update these standard graphical reports. These reports are printed by
the Departments and, along with some additional tabular reports from WMS and additional
descriptive information, are complied into a Monthly Report for distribution to the Management.
4.4.3 Reporting against Board Approved Target
After the Shareholder’s meeting in March and October, the Planning Co-ordinator shall modify the
Stored Reports to change the target, to report against the latest approved budgets.
4.4.4 Year-end
After the December month-end reports are produced, the Planning Co-ordinator shall modify the
Stored Reports to change the ‘Date From’ to start from 1 st of January of the calendar year.
APR 97
Page 39
5 REFERENCES
In this ERD, reference is made to the following publications:
Note: Unless specially designated by date, the latest edition of each publication shall be used, together with any
amendments, supplements, revisions thereto.
5.1 PDO STANDARDS
PS6 User Guide: Available from Planning Co-ordinators

Capital Budget Guidelines: Available from FCB1
Cost Coding for Budgeting,
Estimating and Cost Control: ERD PDO-ES-PC-00-11
Asset Breakdown: DEP 01.00.09.10-Gen.
Coding System for the administration
and Control of Capital projects: DEP 40.10.01.11-Gen
5.2 SHELL STANDARDS
WMS User Manual: Available from Planning Co-ordinators

Project Management Guidelines: SIEP 96-3000
APR 97
Page 40
Figure 1 - Procedure Flowchart
Concept Engr.Engr.
Cconcept identifies
Identifies
new project
Project Ranking
Exercise
Engineer breaks down FFP inputs Projects and budget

Project into Activities into CABCARS
CABCARS interface
Project Engineer
generates BI in WMS
plans in PS6
Project Engineer imports PS6

plan into WMS
Project Engineer approves Planning Co-ordinator

BI in WMS freezes target in WMS
Project Engineer generates Interface transfers

ledger-codes in WMS ledger-codes to EPCRIS
Project Engineer generates

and circulates RFA
NO
Project Engineer revises Approved ?
and circulates RFA
YES
FFP activates ledger-codes

in EPCRIS
Project Engineer
starts commitments
Project Engineer
reports VOWD
YES
LACF different ?
NO
When Projects finished

Project Engineer raises PCC
APR 97
Page 41
Figure 2 - Work Breakdown Structure
Concept Eng. INPUT DATA
Budgets
Cost Estimates
WBS Resource Usage
WBS
Schedules
Project Eng. Progress
Approvals Contractors
Finance
OUTPUT INFORMATION
Programme
Materials
Baseline Estimates
Baseline Schedules
Government &
Forecasts Private
Management
Shareholders
Progress
Exception Reports
WBS
WBS
APR 97
Page 42
APPENDIX 1 – Function Codes
FUNCTION
DESCRIPTION
CODE
00 DESIGN & ENGINEERING: General
01 Conceptual Design
02 Front End Design
03 Detailed Design
04 Soil Investigation
05 Studies
06 Field Trials
07 HAZOPS / Design Reviews
08 Drawings / Documentation
10 PROCUREMENT: General
11 Mech Process / Main Equipment
12 Piping & Pipelines
13 Electrical
14 Instrumentation
15 Telecommunication
16 Civil Materials
17 Utilities
18 Moveables
19 Miscellaneous Materials
20 CONSTRUCTION: General
21 Mobilisation
22 Civil Construction
23 ME&I Construction
24 CME&I Construction
25 Turnkey
26 Construction Shutdowns
27 Pre-Commissioning / Testing
30 COMMISSIONING: General
31 Commissioning
32 Inspection Services
33 Specialist Services
34 Commissioning Shutdowns
40 ENG. PROC. & CONSTR.: General
41 Preliminaries
42 Design
43 Procurement
44 Construction
45 Commissioning
50 OTHER CHARGES: General
51 SIPM Services
52 Management Adjustment
53 Misc. & Co. Generated Charges
54 Estimating Contingency
55 Project Risk Contingency
56 Insurance
57 Government Gas Overheads
58 Government Gas Fees
59 Govt. Gas Manage. & Consult.
60 DRILLING: General
61 Govt. Gas Development Drilling
APR 97
Page 43
APPENDIX 2– ANALYSIS CODES
ANALYSIS
DESCRIPTION
CODES
TENDERING & CONTRACTING ACTIVITIES
Prepare Tender 71
Circulate and Approve Tender 72
Evaluate Tender 73
Tender Board / Shareholder Approval 74
Contract Signature / Fax of award 75
Prepare and Issue Tender 76
CONTRACT & WORK TYPES
Service Contract 81
Stand Alone Reimbursable Contract 82
Stand Alone Lump Sum Contract 83
Stand Alone BOQ Contract 84
As Built Drawings 85
Manuals 86
Vendor Documents 87
QUALITY / SAFETY ACTIVITIES
Quality Audits 91
Third Party Inspection 92
Expediting 93
Vehicle Inspection 94
Safety Training 96
COMPANY CHARGES
Capex Contract Supervision 97
Project Engineers’ Salaries 98
Service Contract Overhead Re-allocation 99
APR 97
Page 44
APPENDIX 3– WMS INTERFACES
1. SYSTEM OVERVIEW
Engineer’s
PS6 Plan
Interfaces Interfaces
From To
CABCARS
Proj./BI No. &
WMS EPCRIS
Value of Work
Header Done (VOWD)
Central
EPCRIS Database EPCRIS
Ledger Actuals Ledger Codes
EMA (Multi-User Access) ECAR

Materials Data Yearly Phasings
2. DATA TRANSFERRED IN THE INTERFACE:
INTERFACES SCHEDULE DATA TRANSFERRED

PS6 To WMS Adhoc WBS No. & Title
Start & Finish Date
Resources
VOWD
CABCARS To WMS Weekly Project No. & Title
BI No. & Title
Project Engineer
Work Type 1 & 2
EPCRIS To WMS Monthly Actual payments
EMA To WMS Daily Requisition / Item No. & Title

Schedule details
Commitment & VOWD
Materials Status
WMS To EPCRIS Monthly VOWD
WMS To EPCRIS Daily Ledger Codes
WMS To ECAR Adhoc BI No. & Title

Yearly Phasings
APR 97
Page 45
USER FEEDBACK PAGE
From :
To : Engineering Projects EPN-EPZ

PETROLEUM DEVELOPMENT OMAN
PO Box 81, MUSCAT, SULTANATE OF OMAN
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 to indicate
precisely the amendment(s) recommended.
USER DATE REMARKS

Erd 00 19

Uploaded by

Document Information

Original Description:

Original Title

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

Erd 00 19

Uploaded by

Copyright:

Available Formats

ENGINEERING REFERENCE DOCUMENT

Engineering Reference documents shall only be revised in accordance with ERD-00-10

Revision Date Description

Note : Engineering Reference documents shall be revised in accordance with:-

PDO-ERD-00-10 Presentation, Content & Issue of ERD’s.

The ERD system is intended to:

 Act as vehicle to minimise costs on a life cycle basis.

The objectives of this ERD are:

 To specify the steps required to be executed by the Project Engineer to manage a

Author Custodian Functional Manager For

Date: Date: Date:

3.6 GENERATION OF LEDGER-CODES..................................................................................21

APPENDIX 1 – Function Codes.............................................................................42

1.2 DEVIATION FROM STANDARD

1.3 LANGUAGE AND UNITS OF MEASUREMENT

1.4.1 General definitions

The word shall indicates a requirement.

The word should indicates a recommendation.

The word may indicates a possible course of action.

The Company is Petroleum Development Oman LLC.

SIEP is Shell International Exploration and Production.

An Engineering Reference Document is defined as any document authorized by the Company

1.4.2 Specific Definitions

ADP Asset Development Plan.

BI The last 4 characters of the Project number and an alpha character

Commitment The Company’s exposure to third parties calculated as awarded contract

EMA Materials recording and tracking system maintained by Supply Department.

ECAR Capex Allocation Register with Engineering BI to Petroleum Engineering

EPCON The Contract Management System.

EPCRIS The Company’s general ledger.

EZ The Company’s service contract administration system.

HCG Hague classification group: SIEP standard codes for materials.

IBP Internal Budget Proposal (for Projects up to and including $1 M).

Project Number A 5 character number generated by CABCARS in which the first

Project Title Summary description of the project.

PS6 Project Scheduler 6: the planning package used by project

System Manager WMS Custodian (BBS/5).

UTC Unit Technical Cost of production.

VOWD Value of work done: a measure of the physical work actually

Workgroup A group of projects: the grouping of projects, generally within an

CABCARS Capital Budget Control, Administration and Reporting System.

The flow chart of procedures for Project Engineers is included in Figure 1.

2.2 CREATION OF A PROJECT/BI IN WMS

2.3 BREAKDOWN OF A BI INTO ACTIVITIES

2.4 PLANNING A BI IN PS6

2.5 GENERATION OF PLAN AND PHASINGS IN WMS

2.6 APPROVING THE BUDGET IN WMS

2.7 GENERATING LEDGER-CODES

2.8 GENERATION OF RFA

2.9 COMMITMENT CONTROL

2.10 REPORTING VOWD

2.11 PROJECT CLOSING

2.12 SYSTEM INTERFACES

2.13 MAINTAINING BOARD APPROVED TARGETS

2.14 MONTH-END PROCESSING

2.15 MANAGEMENT REPORTING

3 PROCEDURES FOR PROJECT ENGINEERS

3.1 CREATION OF A PROJECT/BI IN WMS

Field Description Field Length (in WMS)

Budget Item Budget Description

Status Project Number Budget Item

Report Content Distribution