Project Plan - Template V1.0

Author: PM Name

Version: V1.0

Issue Date: 11/7/2008

My Project Name

Project Management Plan

DRAFT

Approval

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

Key Stakeholders

Stakeholder Name

Stakeholder Title

(Stakeholder Position on Project)

Date Richard Harris

OneOx Program Manager

Date

Print Date: 9-Apr-23 4:16:31 PM Page : 2 - 22 Commercial In-Confidence

DRAFT

Document Control

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.

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 Received

(Yes / No)

Date

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.


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 indicators)

Quality sheet in XYZ Project - Registers.xls

Stakeholder Contact detail

XYZ Project - Contacts.xls

Project Schedule XYZ Project - Schedule.mpp


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


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 NameProject ManagerOneOx ProgramOxiana LimitedT : Best Contact NumberE : [email protected]


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











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: 4/9/2023 4:16:31 PM 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 Dependency

Name of other project

Impact on this project

Impact on other project

EG: Possible change of base system from Ellipse to SAP

EG: OZ minerals merger / integration activities

Eg: If changed to SAP the 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.

Eg: None.


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.


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 functional and process matters

Technical, functional and OneOx 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 Heaton

GM Martabe

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


Cameron Gault Ausenco Project Controls Manager Contact point at Ausenco


DRAFT


George Kouimanis

Ausenco Procurement and Contracts Group Manager

Sign Off on solution

Ray Walters Ausenco Procurement and Contracts SME

SME

Barry Monteret Ausenco manager Systems Improvement Projects

Ausenco Integration Solution 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


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 deliveredAssess impact on any deliverables and update any earlier requirements as appropriate (requirements 4.01 and 4.02)

5. Ellipse functions requirements documentedDocument requirements for requirements 1.01 to 1.15

6. Initial Ellipse functions designed and implementedImplementation 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 implementedImplement “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 providedProvide appropriate date for Prediction Plus (P+) Project Reporting. (requirements 4.01)

9. Accept output data of Prediction PlusTest and Accept output data (reports) from P+ Project (requirement 4.03)

10. EPCM partner integration “automation” solution implemented


DRAFT

Example Project WBS devolved from requirements

Implement “automated” EPCM partner WBS interface (requirements 3.01)Implement “automated” EPCM partner Suppliers interface (requirements 3.03)Implement “automated” EPCM partner Payments interface (requirements 3.04)

11. Customs Master List solution deliveredCustoms 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) rationalizedInvestigate 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 implementedDefine 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)


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”


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.


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.


http://oxnet/finance/OneOxTeamsite/EllipseInfo/Wiki%20Pages/PM%20Tools.aspx

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 or request via CSS.

As required request via Gareth Davies

Process Lead – Finance/Payroll (Jakarta)

Vonny Wibawa Phil Trussell

LMAP P+ Lead Trevor Bailes (LMAP) Gavan Davies (LMAP)

Ausenco AusDB Technical Resource

? ?

Ausenco Prism Technical Resource

Brad Maclean (AUSENCO) Cameron Gault (AUSENCO)

CSS Representative (post project support of Ellipse)

Eric Sidharta Gareth Davies

IT Support Representative (future support of P+)

Jimmy Jerkovic Michael Whelan


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


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


http://oxnet.oxiana.com.au/finance/fitaprojects/Shared%20Documents/Execution/PM%20Tools%20and%20Methods/Tools%20and%20Templates/Steering%20Committee%20Charter.doc

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.


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.

.
