My Project Name

Project Management Plan

Author: PM Name

Version: V1.0

Issue Date: 11/7/2008

DRAFT

Approval
By signing in the sections below, all parties agree to the contents of this document.

Key Stakeholders

Stakeholder Name Date Richard Harris Date

Stakeholder Title OneOx Program Manager

(Stakeholder Position on Project)

Print Date: 9-Dec-21 2:19:24 AM Page : 2 - 22 Commercial In-Confidence

DRAFT

Document Control

Document \\melfps01\depts\finance\ellipse\etc etc etc

Location NB: Use the UNC path here so it may be accessible from all sites. Do not use
G:\finance\ as every site has a different G:\ drive.

Document History

Version Date Author Comments

0.1 24/6/2008 Your Name First draft
1.0 11/7/08 Your Name Accepted Copy

Stakeholder Sign-off

Title Name Sign-Off Date

Received
(Yes / No)
Eg: Project Sponsor Eg: Joe Blogs No Eg: 11/7/08

Glossary

Term Description
All terms and acronyms which may require explanation need to
be included here.

Print Date: 9-Dec-21 2:19:24 AM Page : 3 - 22 Commercial In-Confidence

DRAFT

References and Files:

Project Document Location \\melfps01\depts\finance\ellipse\etc etc etc

NB: Use the UNC path here so it may be accessible from all sites.
Do not use G:\finance\ as every site has a different G:\ drive.
Requirements Register Requirements sheet in XYZ Project - Registers.xls

Risk Register Risk sheet in XYZ Project - Registers.xls

Issue Register Issues sheet in XYZ Project - Registers.xls

Change Register Change sheet in XYZ Project - Registers.xls

Status Reports Weekly sheets in XYZ Project - Registers.xls

Quality (Measurements and Quality sheet in XYZ Project - Registers.xls

indicators)

Stakeholder Contact detail XYZ Project - Contacts.xls

Project Schedule XYZ Project - Schedule.mpp

Print Date: 9-Dec-21 2:19:24 AM Page : 4 - 22 Commercial In-Confidence

DRAFT

Table of Contents

1. Project Scope 1
1.1. Project Purpose 1

1.2. Project Objectives/Deliverables 2

1.2.1. In scope 3

1.2.2. Out of scope (Exclusions) 3

1.2.3. Constraints 3

1.2.4. Assumptions 3

1.2.5. Dependencies 3

1.2.6. Scope Management 4

2. Stakeholders 5
2.1. Primary Stakeholders 5

External Stakeholders 5

3. Schedule 7
3.1. Schedule Management Plan 7

3.2. Work Breakdown Structure 7

4. Cost Management 9
4.1. Project Cost Management 9

5. Quality Management 10
5.1. Quality Management Plan 10

5.2. Quality Measures and Indicators 10

5.3. Requirements Tracking 11

6. Staffing
6.1. Proposed Organisational Structure 12

7. Communications 13
7.1. Communications Plan 13

7.2. Regular Team Meetings 13

7.3. Sponsor Meetings 14

7.4. Steering Committee Meetings 14

7.5. Regular Status Reports 14

7.6. Stakeholder communications 15

Print Date: 9-Dec-21 2:19:24 AM Page : 5 - 22 Commercial In-Confidence

DRAFT

8. Risk
8.1. Project Risks and Management 16

9. Procurement 16
9.1. Procurement Management 16

For enquiries regarding this document please contact:

PM Name
Project Manager
OneOx Program
Oxiana Limited
T : Best Contact Number
E : pmname@oxiana.com.au

Print Date: 9-Dec-21 2:19:24 AM Page : 6 - 22 Commercial In-Confidence

 1. Project Scope
1.1. Project Purpose
A short narrative describing the purpose and benefits of the project as defined by the Project Charter.
DRAFT

1.2. Project Objectives/Deliverables

This project sets out to achieve the following Objectives:
Objective Initial Requirements

1. Your first Objective
2. Your second Objective
3. Your third Objective
1.01 Break objective 1 into specific achievable and measurable
requirements that will form the highest level in your requirements register
1.02 Break objective 1 into specific achievable and measurable
requirements that will form the highest level in your requirements register

1.03 Break objective 1 into specific achievable and measurable

requirements that will form the highest level in your requirements register

2.01 Break objective 2 into specific achievable and measurable

requirements that will form the highest level in your requirements register

2.02 Break objective 2 into specific achievable and measurable

requirements that will form the highest level in your requirements register

2.03 Break objective 2 into specific achievable and measurable

requirements that will form the highest level in your requirements register

Number Key Success Criteria Measure

1 Your first Objective Quantitative measurement(s)
beyond just delivering the listed
requirements. ie: 90% of Invoices
must be generated from
Purchase Orders.
2 Your second Objective Quantitative measurement(s)
beyond just delivering the listed
requirements. ie: 90% of Invoices
must be generated from
Purchase Orders.
3 Your third Objective Quantitative measurement(s)
beyond just delivering the listed
requirements. ie: 90% of Invoices
must be generated from
Purchase Orders.
Please note that business benefits of the objectives are detailed in the Project Initiation Document.

Print Date: 12/9/2021 2:19:24 AM Page : 2 - 22 Commercial In-Confidence

DRAFT

1.2.1. In scope
The scope for the project includes the following:

 This can reiterate the deliverables, however this is where the scope of the project lives.

 This can reiterate the deliverables, however this is where the scope of the project lives.

1.2.2. Out of scope (Exclusions)

The following items are out of scope for this project:

 This is important as there may be implied requirements and by explicitly documents

contentious items as out of scope makes sure they are not confused with implied
requirements.
1.2.3. Constraints
The following are seen as constraints for the project:
 Time – ???

 Resources – ??

 Costs - ????

 etc
1.2.4. Assumptions
Defined Oxiana Processes and standards will be applied. If a process exists then it will be applied or
agreed to be modified outside of the scope of this project. This will be simple in the case of DOA
(Delegation of Authority), but may be more difficult in others such as Supplier Creation.

1.2.5. Dependencies

Description of Name of other project Impact on this project Impact on other project
Dependency
EG: Possible change of EG: OZ minerals Eg: If changed to Eg: None.
base system from merger / integration SAP the activities
Ellipse to SAP activities required for
objective 1 (provide
ERP tools) will
increase.
Appilcation specific
uploads and
extracts would also
need to change.
Affecting some of
the outputs of
objectives 2 and 3.

Print Date: 12/9/2021 2:19:24 AM Page : 3 - 22 Commercial In-Confidence

DRAFT

1.2.6. Scope Management

Requests to change the scope of the project can be raised at any time by the Project Manager.
Changes to the scope of the project will be processed as Change Requests and will be logged in the
Change Register, maintained by the Project Manager. All changes to scope must be approved by the
Sponsor. See the “Change Register” sheet in “XYZ Project - Registers.xls”.

 Changes to the list of requirements in the requirements register represent a change in scope.
Therefore they need a change request.

Print Date: 12/9/2021 2:19:24 AM Page : 4 - 22 Commercial In-Confidence

DRAFT

2. Stakeholders
2.1. Primary Stakeholders

Internal Stakeholders

Who Role Involvement

TBA Project Steering committee Steering Committee

John Nitschke Executive General Manager, Australian ?

Operations
Richard Harris OneOx Program Manager OneOx Program Manager
Peter Albert Executive General Manager Asia Key User
Phillip Trussell PT Agincourt Commercial Manager Sponsor and Key User
Byron Higgins Executive Project Manager Key User
Tim Duffy General Manager Finance Asia
Glen Middleton Projects Controls Finance Super Project team member
David Rambet ? On Project
Andrew Fisher Group IT Manager IT and BAU resources and Support
Michael Whelan IT Infrastructure Manager IT resources
Greg King Supply Chain Manager Asia
OneOx SMEs Subject Matter Experts in OneOx Technical, functional and OneOx
functional and process matters process ERP support.
CSS Team Commercial Systems Support Technical systems support
Vinay Paul Acting IT & Systems Manager - Asia Technical Support and resources
Sue McLean Shared Services Manager Management of Suppliers
Domenic GM Martabe
Heaton
Vonny Wibawa Finance Jakarta
Budi Irawan Tax Jakarta
David Lynn Group Manager Project Services (NB: Onboard mid-August)
Communications Only
Dale Smith Seppon EPM Major communications esp. P+
Mark Freeman HRIS HR tools were cut from scope.. they
are no longer stakeholders

External Stakeholders

Who Role Involvement

Cameron Gault Ausenco Project Controls Manager Contact point at Ausenco

Print Date: 12/9/2021 2:19:24 AM Page : 5 - 22 Commercial In-Confidence

DRAFT

Who Role Involvement

George Ausenco Procurement and Contracts Sign Off on solution
Kouimanis Group Manager
Ray Walters Ausenco Procurement and Contracts SME
SME
Barry Monteret Ausenco manager Systems Ausenco Integration Solution
Improvement Projects implementation
Brad Maclean Ausenco PRISM SME SME
Mark Cornwall Ausenco Engineering Project Manager
Claire Borbas P+ Support
Gavan Davis P+ Sales
Trevor Bailes P+ Support
TBA Oxiana Integration outsource providers

Print Date: 12/9/2021 2:19:24 AM Page : 6 - 22 Commercial In-Confidence

DRAFT

3. Schedule
3.1. Schedule Management Plan
Changes to the schedule will be made and recorded in MS Project schedule “XYZ Project -
Schedule.mpj”

Near term milestones and any changes to the schedule at milestone level will be communicated as
part of the Sponsor progress meetings and also reported as part of regular team meetings.

Changes to the scheduled completion date of the project will be processed as Change Requests and
will be logged in the Change Register, maintained by the Project Manager. All changes to scheduled
completion date must be approved by the Sponsor. See the “Change Register” sheet in “ XYZ Project -
Registers.xls”

3.2. Work Breakdown Structure

This WBS looks at Milestones derived from the requirements. The specifics of the schedule, timing
and duration is held in the Schedule “XYZ - Schedule.mpj”

Example Project WBS devolved from requirements

1. Planning Complete
2. Ausenco WBS to Oxiana Project Number mapping complete
3. EPCM partner integration processes and requirements documented (and signed off)
Agree and document EPCM partner WBS interface (requirements 3.01)
Agree on PO and T&C format applicable for both Ausenco and PT AGC's systems (requirements 3.02)
Agree and document EPCM partner Suppliers interface (requirements 3.03)
Agree and document EPCM partner Payments interface (requirements 3.04)
Agree and document EPCM partner early month end close (requirements 3.05)
4. Approved Prediction Plus requirements delivered
Assess impact on any deliverables and update any earlier requirements as appropriate (requirements 4.01 and
4.02)
5. Ellipse functions requirements documented
Document requirements for requirements 1.01 to 1.15
6. Initial Ellipse functions designed and implemented
Implementation of Martabe Construction Project WBS (requirements 1.01)
Implementation of Ellipse Projects for operational reporting. (requirements 1.02)
Procurement via Purchase Requisitions and Direct Purchase Orders (requirements 1.04)
Finance Fixed Assets Implementation for Tax (requirements 1.05)
FEX management solution. (requirements 1.08)
Supplier management (requirements 1.11)
Logistics and Freight management. (requirements 1.12)
System to manage the Bonded Warehouse for receipt of stock (requirements 1.13)
Remittance advice system. (requirements 1.15)
7. EPCM partner integration “manual input” solution implemented
Implement “manual” EPCM partner WBS interface (requirements 3.01)
Confirm identical PO and T&C for both Ausenco and PT AGC's systems (requirements 3.02)
Implement “manual” EPCM partner Suppliers interface (requirements 3.03)
Implement “manual” EPCM partner Payments interface (requirements 3.04)
8. Prediction Plus data provided
Provide appropriate date for Prediction Plus (P+) Project Reporting. (requirements 4.01)
9. Accept output data of Prediction Plus
Test and Accept output data (reports) from P+ Project (requirement 4.03)
10. EPCM partner integration “automation” solution implemented
Implement “automated” EPCM partner WBS interface (requirements 3.01)

Print Date: 12/9/2021 2:19:24 AM Page : 7 - 22 Commercial In-Confidence

DRAFT

Example Project WBS devolved from requirements

Implement “automated” EPCM partner Suppliers interface (requirements 3.03)
Implement “automated” EPCM partner Payments interface (requirements 3.04)
11. Customs Master List solution delivered
Customs Master List implementation possibly within or without Ellipse. (requirements 1.07)
12. Additional Ellipse reporting delivered (Cash Forecast etc)
Cash forecasting is required. Reports would need to be developed. (requirements 1.06)
13. Payroll systems (Ellipse IPR) rationalized
Investigate and implement an ongoing payroll systems and support that will sustain PT AR until at least
December 2009 (requirements 2.01)
Interface between PT AGC payroll financials and Ellipse (requirements 2.02)
Interface between PT AGC Payroll HR/Employees and Ellipse (requirements 2.03)
14. Remaining Ellipse functions implemented
Define and implement full Hierarchy and Employees and Financial Authorities as per DOA. (requirements 1.03)
Maintenance Equipment Register Implementation (requirements 1.09)
Maintenance Ad-hoc Work Order Implementation. (requirements 1.10)
Improved email Authorisation system (requirements 1.14)
AR system for sales and employee advances (requirements 1.15)

Print Date: 12/9/2021 2:19:24 AM Page : 8 - 22 Commercial In-Confidence

DRAFT

4. Cost Management
4.1. Project Cost Management
The project costs and budget will be managed during the project by the PM. The project budget and
forecasts will be regularly reported to the sponsor via the Sponsor status update meetings. At a
minimum, budget expenditure against current Forecast plus Estimate at Completion, and Estimate to
Completion will be shown.

The complete list of budget reporting follows;

 Current forecast vs budget baseline by Milestone

 Estimate at completion

 Estimate to completion

 Expenditure by Milestone by individual (or external organisation)

 Budget summary into External vs Internal costs (nb: internal refers to cross charges, payroll
staff or contract staff, external refers to purchases of equipment or services specifically for the
project)

This project also stipulates several rules for cost management;

 EG: While changes to budget follow the company delegation of authority manual, any
changes to this project that will bring the budget over $200K USD must be reviewed approved
by the Executive Director of Projects. This threshold is laid out in the project charter along with
risk thresholds.

 EG: All project financial reporting to be done in USD$

Changes to the budget (as a whole) of the project will be processed as Change Requests and will be
logged in the Change Register, maintained by the Project Manager. All changes to budget must be
approved by the Sponsor. See the “Change Register” sheet in “XYZ Project - Registers.xls”

Print Date: 12/9/2021 2:19:24 AM Page : 9 - 22 Commercial In-Confidence

DRAFT

5. Quality Management
5.1. Quality Management Plan
Quality on a project is about meeting the customers defined and implied needs. Unfortunately on
projects, quality is difficult to measure. Often, key stakeholders cannot measure the true quality of the
results until delivery, and then it is too late or expensive to resolve the gaps. A good example of this is
one of the key success criteria of this project: “Company XYZ Purchase Orders make the target mark
of 90% of total Invoices (ie: POI / POI + NOI)”. This measurement will be hard to undertake until very
late in the project. At that late stage, any changes related to this measurement will be difficult and
costly.

The goal of the Quality Management Plan for this project is to attempt to have an indicator of whether
our customer’s needs are being met as soon as possible in the project. In addition to measurements,
several indicators will be used including the process of requirements tracking. The use of quality
measurements, indicators and requirements tracking are detailed in the sections below. The overall
components of the quality plan are;

 Use quantifiable quality measurements for all objectives

 Use other quality measurements when possible to assess quality early in the project, when
this is not possible use quality indicators.

 The use of simple requirements tracking is one of the core quality indicators.

5.2. Quality Measures and Indicators

The first tool in managing project quality is to agree and monitor several quality measures. If
quantitative measurements are not available early enough in a project then quality indicators will be
tracked. Quality indicators are used in attempt to ensure the project is using proper inputs and quality
processes to help create appropriate quality outputs. By monitoring appropriate inputs and process,
we hope to gain a much earlier indication of the quality of the outputs.

 Ensuring “Proper Inputs” may mean the creation and review of appropriate test cases.

 “Quality processes” refers to processes to assist in producing quality such as multiple solution
reviews, or even requirements tracking. If these are explicitly listed and monitored as a Quality
Indicator then they are more likely to undertaken.

All quality measurements and indicators will be listed and monitored in the “Quality” sheet in “ XYZ
Project - Registers.xls”. Changes to this sheet do not require an approved change request.

Print Date: 12/9/2021 2:19:24 AM Page : 10 - 22 Commercial In-Confidence

DRAFT

5.3. Requirements Tracking

One mandatory quality indicator is the use of a requirements register to monitor and help
communicate requirements. Each stated requirement will need to be listed in sufficient detail, and
continuously monitored for delivery throughout the project. This information will be stored in the
“Requirements Register” sheet in “XYZ Project - Registers.xls”.

Several guidelines need to be followed when tracking requirements.

 At a minimum, each requirement will need to be listed in the register and the status tracked.

 Each requirement will need to be tracked in three stages; “Requirements Defined”,

“Appropriate Solution Defined” and “Solution Delivered”.

 Each requirement needs to be assessed to see if a more detailed requirement statement is

required. If so, the requirement as a whole still resides in the register, however a Business
Requirements Statement would need to be produced and used. An example of such a
document is on OneOx Team site BRS. This need for detailed BRS will be decided by the
project team considering risk, issues, estimated costs and the complexity of the requirement.

 Requirements can’t always be marked as “Solution Delivered” and then ignored. Since new
solutions may affect “solved” requirements a continual review of the requirements will need to
be undertaken by the PM. (this is in fact a quality indicator)

 A change to the list of requirements is likely to effect scope. Therefore changes to the
requirements must be monitored and approved by the sponsor via an approved change
request and an entry in the Change Register.

 A clarification of requirements doesn’t necessarily mean a change in scope. So clarifications

won’t require change management. However they should be entered in the requirements
register and monitored by the PM.

Print Date: 12/9/2021 2:19:24 AM Page : 11 - 22 Commercial In-Confidence

DRAFT

6. Staffing
6.1. Proposed Organisational Structure
The below list represents the proposed team. Due to Oxiana being a Matrix organisation each
manager of a proposed team member will need to explicitly authorised their involvement. These
authorisations must be recorded by the PM against each team member.

Role Person Responsible Authorised by

Project Sponsor Phil Trussell NA
Project Manager Mark Nold Richard Harris
Finance / Projects Lead Glen Middleton Phil Trussell
CML Lead David Rambet Phil Trussell
Technical Resource - Ellipse Made on a task by task basis, either purchase As required
or request via CSS. request via
Gareth Davies
Process Lead – Finance/Payroll Vonny Wibawa Phil Trussell
(Jakarta)
LMAP P+ Lead Trevor Bailes (LMAP) Gavan Davies
(LMAP)
Ausenco AusDB Technical ? ?
Resource
Ausenco Prism Technical Brad Maclean (AUSENCO) Cameron
Resource Gault
(AUSENCO)
CSS Representative (post Eric Sidharta Gareth Davies
project support of Ellipse)
IT Support Representative Jimmy Jerkovic Michael
(future support of P+) Whelan

Print Date: 12/9/2021 2:19:24 AM Page : 12 - 22 Commercial In-Confidence

DRAFT

7. Communications
7.1. Communications Plan
Due to the geographically dispersed nature of the project and the global community of Ellipse users,
communications is vital to the success of the project. Several communication tools will be used
throughout the project to make sure stakeholders have the appropriate input to the project, and all
stakeholders are aware of changes before they happen and what to do when something unexpected
happens.

The communication tools are;

 Weekly team meetings (weekly)

 Regular sponsor meetings (weekly)

 Regular steering committee meetings (undefined at present)

 Status Reports (used for the sponsor meetings)

 Stakeholder Communications (a list of tools to use throughout the project)

These items are detailed in the following sections;

7.2. Regular Team Meetings

Once the project has started the team will meet regularly (weekly) via phone or video conference.
Additional meetings may be called as required. Each meeting will last a maximum of an hour and
require an agenda created by the PM. The agenda will be updated to form the minutes of the meeting
and then sent to team members and stored on the central file location. At a minimum the agenda will
include;

An agenda for the meetings will be used including a list of relevant issues. The complete list of issues
will exist in the Issues Register (see “Issues Register” sheet in “XYZ Project - Registers.xls”). This will
form an input and output of the meetings but will not be used to run the meeting (ie: no meetings by
spreadsheets).

 Status review of near term milestones (typically next 4-7). This is a tool to discuss the current
forecast date, and any possible changes. The team will need to agree on the current status
(using the green, amber, red notation) of the forecast dates so the PM may report accurately.

 Agenda items for relevant issues and risks. To avoid the management by large lists of issues /
risks the PM will bring relevant issues and risks to each meeting.

 Agenda item for the addition of new issues and risks

 The location and file names of relevant documents to the meeting.

 Questions on upcoming holidays or changes to availabilities

 Functional agenda items such as time, place, meeting attendees and any conference call
details

Print Date: 12/9/2021 2:19:24 AM Page : 13 - 22 Commercial In-Confidence

DRAFT

7.3. Sponsor Meetings

During the execution of the project the PM and the project sponsor will meet regularly (weekly) to
discuss the project status. This discussion will address all the items in the Status Report (see below in
section “Regular Status Reports”) plus will also be used to authorise any changes in the project (that
impact scope, schedule or cost).

7.4. Steering Committee Meetings

During the execution of the project the Project Sponsor and Steering Committee will meet regularly
(????) to discuss the project status. The PM may or may not be included in the discussions. The
committee is responsible for approving budgetary strategy, defining and realising benefits, and
monitoring risks, quality and timeliness, plus assisting in removing barriers to the project’s success.
For further details please see the document Steering Committee Charter on Oxnet.

Due to the dispersed nature of this project, communications will be undertaken via phone conferences,
some video conferences (not available outside of Perth, Melbourne, GG and PH) as well as email.

7.5. Regular Status Reports

Status reporting forms an integral part of the project control framework. Using a one page status report
the goal is to give the Sponsor and Steering committee an overview of the projects status. Specifically
it will cover;

 Overall Progress narrative plus a qualitative assessment as Green, Amber, Red (No issues
unmanaged, Some issues outstanding, Severe issues)

 Status of associated Risks, Resources and Costs. Plus a colour coded status (see above)

 Historical progress over the last 11 weeks

 Key Achievements and Objectives (in the past and next four weeks)

 Top 5 Hotspots. This is designed to address the top five unmanaged risks and issues with the
project or dependencies.

 Schedule dates of next seven uncompleted milestones (including Baseline and current
Forecast dates) plus narratives on near term milestones (next four milestones)

 Budget expenditure against current Forecast. Includes Estimate at Completion, and Estimate
to Completion

Print Date: 12/9/2021 2:19:24 AM Page : 14 - 22 Commercial In-Confidence

DRAFT

7.6. Stakeholder communications

In addition to the above meetings, several communications will take place during the project

 Project Kick Off communication to all stakeholders via a one page PDF communiqué.

 Update of intranet (Oxnet) profiles to include all team members and a short amount of
personal information and picture if possible.

 All implementations or changes during the project require a “Pre Go Live” communication to all
stakeholders with information on what will change and how it will affect the various
stakeholder groups. This should include details on down time, and detail support processes
during the change. This will be done via a “one page PDF communiqué”.

 The maintenance of an up to date “Stakeholder list” (kept as part of the Project Management
Plan)

 The maintenance of an up to date “Contact List” including phone numbers and emails (kept
separately in document “XYZ Project - Contacts.xls”)

 At project close or after the go live of large changes a one page communiqué will be sent out
to all stakeholder describing the change made, the ongoing effects of the change and any
work explicitly not undertaken. Possibly a narrative will be included on the performance of the
people involved in the change / project.
During the project, all documentation mentioned in this plan will be held in;
\\melfps01\depts\finance\ellipse\etc etc etc
This is a working area and the information held here is not for public consumption, but for the Project
Team and sponsors. All public facing documents will be sent via email, and possibly also published on
Oxnet. At completion these project documentation will be cleaned up and archived using the OneOx
standard.

Print Date: 12/9/2021 2:19:24 AM Page : 15 - 22 Commercial In-Confidence

DRAFT

8. Risk
8.1. Project Risks and Management
A Risk Register will be created and will be updated during the project by the PM. See the “Risk
Register” sheet in “XYZ Project - Registers.xls”. Risks will be assessed in a qualitative fashion and will
be communicated as required through team meetings, sponsor status reports and possibly steering
committee meetings.

NB: The risk management plan should meet the Oxims standards for Risks Management.

9. Procurement
9.1. Procurement Management
This project’s need for external procurement may be broken up into three areas;
 Incidental costs such as travel, taxis, meals and accommodation

 Purchase of external labour

 Purchase of equipment

All of the first items will be handled by Oxiana’s internal travel officers and Oxiana reimbursement
policies. As outlined in the Cost Management section no project team expenditure may be undertaken
without the PM’s prior approval. The PM’s travel and accommodation will be approved by the project
sponsor or direct manager.
External labour is to first go through an assessment of internal vs external (ie: make or buy) using CSS
or other departments. Once made a single quote is to be obtained from an appropriate supplier and
approved by the sponsor. Further requests for quote may be made if required by the project sponsor.
Each request for quote must include a list of requirements and specific and measurable success
criteria.
Equipment purchases for commodity items such as PC hardware will go through Oxiana’s applicable
purchasing process and approved by the sponsor.
For travel and accommodation, all monitoring and costing beyond initial approval is the responsibility
of the travelling team member.
For the second and third type of procurement, all monitoring of the procurement cycle is the
responsibility of the PM. The final close of purchase orders and the storage of a copy of the related
documentation of the purchases is the responsibility of the PM.
.

Print Date: 12/9/2021 2:19:24 AM Page : 16 - 22 Commercial In-Confidence