PROJECT GOVERNANCE OFFICE

Project Management Plan

[PROJECT NAME]
Document Purpose
The Project Management Plan is the outcome of detailed project planning and documents the
approach to project control, deliverables, implementation and transition to business as usual.

Project Name: [Name] Project Governance Office Doc Version: 1.0 Project Code: ###### Page 1 of 20
Revision History
Version Revision Date Summary of Changes Amended By
V0.1 Initial draft
V0.2
V0.3
V1.0 First release

Document Owners
This document requires the following owners to be accountable for its contents.

Project Role Name Position Signature

Project Sponsor
Project Owner
Project Manager

Approvals
This document requires the following approvals. A signed copy must be placed within the Project Site of
Project Online.

Name Title Signature Date of issue Version

Distribution
Name Title Date of issue Version

Project Name: [Name] Project Governance Office Doc Version: 1.0 Project Code: ###### Page 2 of 20
Scaling the Project Management Plan
To ensure the Project Management Plan has sufficient detail appropriate to the project size, assess and map
and highlight the project against the criteria below:

1. Enterprise Risk Level: An initiatives risk should be assessed against UQ’s Enterprise Risk Matrix1.
2. Business Unit Involvement: Representation of the different business units across UQ that will
support the role of implementation partner.
3. Project Duration: The estimated duration of the project.
4. Complexity: Technical complexity has been identified as a known hindrance to the successful
delivery of a project. The considerations are listed below:
a. The team/vendor have had no/limited previous implementation experience.
b. Number of technologies involved. (IT only)
c. Number of interfaces, business processes involved (IT only)
d. The product/release is a first for higher education being piloted in UQ.
e. Rollback requires significant effort and/or is not possible. (IT only)
f. Solution is complex with multiple dependencies.
5. Scope Impact: Scope of the proposed solution should be assessed not only in terms of complexity,
but the change impact to the University.
6. Project Budget: Estimated budget of the initiative.

Criteria Minor Medium Major

Enterprise Risk Low Medium High/Extreme
Level
Business Unit Simple and contained within Spans two (2) business Spans multiple business
Involvement a business. units. units.
Project < 3 months 4 – 12 months > 12 months
Duration
Complexity Low technical and business Moderate technical and High technical and business
complexity. business complexity. complexity.
Scope Impact Only within originating Only the Information Outside of IT community at
business unit. Technology (IT) UQ.
community within UQ.
Project Less than 100K 100k – 500K >500K
Budget

Examples:

1. A project with low enterprise risk will not need a detailed risk assessment, as part of this PMP and a
statement on how risk is to be managed should suffice. Should the risk level be High/Extreme
however, a statement will not be sufficient and a separate Risk Management Plan may be required.

2. A project that has a minor scope (Change) impact should not need a detailed Change Management
Plan and a statement on how Change is to be managed in this PMP should suffice. If however the
Scope Impact stretches from internal stakeholders to the IT community externally, then a separate
Change Management Plan would probably be required.

Use this approach to guide the level of detail required for each section across the PMP.

1
Enterprise Risk Management Framework
<https://governance-risk.uq.edu.au/files/392/Enterprise_Risk_Management_Framework_Policy_20171012.pdf >

Project Name: [Name] Project Governance Office Doc Version: 1.0 Project Code: ###### Page 3 of 20
Contents
1. Project Overview............................................................................................................................. 6
1.1 Project Synopsis................................................................................................................................ 6
1.2 Objectives.......................................................................................................................................... 6
1.3 Lessons Incorporated........................................................................................................................ 6
2. Scope................................................................................................................................................ 6
2.1 Project Outputs.................................................................................................................................. 6
2.2 Approach........................................................................................................................................... 6
2.3 Assumptions...................................................................................................................................... 6
2.4 Constraints........................................................................................................................................ 6
2.5 Dependencies.................................................................................................................................... 7
2.6 Related Initiatives.............................................................................................................................. 7
2.7 Exclusions......................................................................................................................................... 7
3. Governance...................................................................................................................................... 8
3.1 Steering Committee........................................................................................................................... 8
3.2 Project Reporting............................................................................................................................... 8
4. Project Organisation....................................................................................................................... 8
4.1 Project Resources............................................................................................................................. 8
4.2 Stakeholders...................................................................................................................................... 9
4.3 Roles and Responsibilities................................................................................................................. 9
5. Financial Management Plan............................................................................................................ 9
5.1 Financial Management Approach...................................................................................................... 9
5.2 Budget............................................................................................................................................... 9
5.3 Expenditure Estimate......................................................................................................................... 9
5.4 Expenditure Control......................................................................................................................... 10
6. Procurement/ Vendor Management Plan.....................................................................................11
7. Project Schedule............................................................................................................................ 11
7.1 Schedule.......................................................................................................................................... 11
7.2 Key Project Milestones.................................................................................................................... 11
8. Issue Management Plan................................................................................................................ 12
8.1 Managing Issues............................................................................................................................. 12
8.2 Issues Register................................................................................................................................ 12
9. Risk Management Plan.................................................................................................................. 12
9.1 Managing Risks............................................................................................................................... 12
9.2 Risk Register................................................................................................................................... 13
10. Quality Management Plan............................................................................................................. 13
10.1 Quality Expectations........................................................................................................................ 14
10.2 Compliance...................................................................................................................................... 14
11. Organisational Change and Communications Plan....................................................................14
11.1 Organisational Change.................................................................................................................... 14
12. Communication Strategy.............................................................................................................. 15

Project Name: [Name] Project Governance Office Doc Version: 1.0 Project Code: ###### Page 4 of 20
13. Benefits Realisation Plan.............................................................................................................. 15
13.1 Benefits Profile................................................................................................................................ 15
14. Transition to operations................................................................................................................ 15
14.1 Acceptance Criteria......................................................................................................................... 15
14.2 Hand Over....................................................................................................................................... 15
14.3 Post Implementation Support.......................................................................................................... 16
14.4 Business as Usual Support.............................................................................................................. 16
15. Project Closure.............................................................................................................................. 16
15.1 Post Implementation Review........................................................................................................... 16
15.2 Formalising Closure......................................................................................................................... 16
16. Project Controls............................................................................................................................. 16
16.1 Document Management.................................................................................................................. 16
16.2 Tolerances....................................................................................................................................... 16
16.3 Project Variation Requests and Escalation......................................................................................17
Change & Communication........................................................................................................................... 18
A-1 Stakeholder Map............................................................................................................................. 18
A-2 Communication Strategy................................................................................................................. 18
Tolerance Thresholds and Performance Indicators..................................................................................19

Project Name: [Name] Project Governance Office Doc Version: 1.0 Project Code: ###### Page 5 of 20
1. Project Overview

1.1 Project Synopsis

Source project synopsis from the Executive Summary of the approved Business Case.

1.2 Objectives
Source objectives from the approved Business Case. Note any assumptions that may have changed.

1.3 Lessons Incorporated

Provide details of relevant lessons from previous similar projects/change initiatives which have been
reviewed and resulted in a reasonable adjustment to this plan.

2. Scope

2.1 Project Outputs

Clearly articulate the tangible outputs in scope the project plans to deliver. These outputs will enable the
desired outcomes and associated benefits to be realised. Finance are to be engaged for guidance on
capitalisation and inclusion on the asset register.

2.2 Approach
The approach is a high-level statement indicating the framework to be adopted for delivery how it will support
successful execution.

2.3 Assumptions
If an assumption breaks down or becomes invalid, it will need to be reviewed against the project to ensure
the project’s key deliverables are not put at risk. Some of these assumptions may need to be recognised as
a risk in the project risk register and a cost applied when they are assessed in the estimate. A ‘project
variation request’ will be required to be submitted to the project Steering Committee. List any assumptions
that have been made when planning the project. If there are no assumptions, please state this.

The following assumptions have been made during the planning of this project:

Function Description

2.4 Constraints
List any constraints that have been placed on the project. If there are no constraints, please state this. Some
of these constraints may need to be recognised as a risk in the project risk register and a cost applied when

Project Name: [Name] Project Governance Office Doc Version: 1.0 Project Code: ###### Page 6 of 20
they are assessed in the estimate. If a constraint is having an effect on the project’s key deliverables, a
‘project variation request’ will be required to be submitted to the project Steering Committee.

The following constraints have been placed on this project:

Function Description

2.5 Dependencies
List any dependencies that relate to this project, these may be where other divisions are relying on the
output of this project (upstream) before they can commence their project, or where this project is relying on
the output of another (downstream) before this project can commence. If there are no dependencies, please
state this. Some of these dependencies may need to be recognised as a risk in the project risk register and a
cost applied when they are assessed in the estimate. If a dependency is having an effect on the project’s key
deliverables, a ‘project variation request’ will be required to be submitted to the project Steering Committee.
The following dependencies have been placed on this project:

Function Description

2.6 Related Initiatives

List any projects or programs that relate to this project in terms of them being dependent on the outcome of
this project or vice-versa.

The projects and other initiatives shown in the table below have a bearing, or are in some way dependent on
this project:

Function Related program/project Nature of the relationship

2.7 Exclusions
Refer to Out of Scope detail within the Business Case. These exclusions are listed to assist with clearly
defining the boundaries of the scope, and ensure all key deliverables are mutually agreed and understood.
The following items have been agreed by the Steering Committee as out of scope:

Function Description

Project Name: [Name] Project Governance Office Doc Version: 1.0 Project Code: ###### Page 7 of 20
3. Governance

3.1 Steering Committee

List the members of the project Steering Committee and their associated roles and responsibilities. A project
organisation chart may be attached as an appendix. A Steering Committee Terms of Reference is required
to be completed including the frequency of project health checks and other assurance activities.

Role Name Responsibilities

Project Sponsor Name

Project Owner Name

Project Manager Name

Steering Committee Terms of Reference: [Path location]

3.2 Project Reporting

Status reports provide information to the relevant governance committees and groups on project
performance against original plans. At a minimum, Project Managers are to report on budget, scope,
schedule, risk and issues at each Steering Committee.

List the project reports, frequency and distribution method required throughout the project lifecycle.

The following status reports will be developed:

Report Name Frequency Distribution

Project Status Report Fortnightly Project Portfolio Management
System
Steering Committee Status [frequency of reporting] [name/role/committee]
Reports [name/role/committee]

4. Project Organisation

4.1 Project Resources

List the project resources, their role and engagement type e.g. Contractor, Fixed Term, Secondment. A team
structure may be attached as appendix. Insert proposed resource plan as per approved business case. The
plan should include the tasks and resources (internal and external) required to successfully deliver the
project. Resource plan can be attached as an appendix.

Name Role(s) Engagement Type

Project Name: [Name] Project Governance Office Doc Version: 1.0 Project Code: ###### Page 8 of 20
In the table above, highlight any significant labour recruitment that may need to be undertaken to support
delivery of the project. The approach should be determined in consultation with Human Resources

4.2 Stakeholders
Articulate the key partnerships required for the successful delivery of the project. A stakeholder map may be
attached as an appendix.

4.3 Roles and Responsibilities

Provide a RASCI matrix to summarise the project artefacts and involvement for each role in the creation and
maintenance of those listed. The RASCI can be provided as an appendix.

5. Financial Management Plan

5.1 Financial Management Approach

Provide an overview on the approach intended to capture, track and report on project financials. Ensure
reporting frequency and audience is included.

5.2 Budget
Insert approved budget details and funding source, as per approved business case.

5.3 Expenditure Estimate

As the initial project budget is approved based on a high-level estimate, it is responsible and good practice to
re-estimate the anticipated project expenditure after the project schedule and resource profile have been
refined. Any change should be submitted to the project Steering Committee for approval. Management
Accounts will then record this the Finance Financial Workbook and represent it as the approved budget for
expenditure reporting purposes.

Provide a breakdown of project expenditure using the Project Budget Management Plan.

[Project Name]
(Sponsor); (Project Manager) Year 1 Year 2 Year 3 Year 4 Year 5
20xx 20xx 20xx 20xx 20xx
Approved Funding sources
Source1
Source 2
Total Funding 0 0 0 0 0

Project Implementation Costs

Salaries
Consultants
Equipment

Project Name: [Name] Project Governance Office Doc Version: 1.0 Project Code: ###### Page 9 of 20
 Other
sub -total Implementation Costs 0 0 0 0 0

Ongoing Costs (if applicable post implementation)

Salaries
Consultants
Equipment
Other
sub-total ongoing costs 0 0 0 0 0

Total Costs 0 0 0 0 0

Financial Savings (Benefits)

Salaries
Consultants
Equipment
Other

Total Financial (Savings) Benefits 0 0 0 0 0

Net Cost/Benefit 0 0 0 0 0

Shortfall in funding 0 0 0 0 0

Financial Assumptions
1.
2.
3.
4.
5.
6.

5.4 Expenditure Control

All expenditure shall be captured initially in UQ’s Financial Management System (UniFi) and subsequently
entered into the Project Online (PPM) at the commencement of each month. The Project Manager will
undertake a monthly reconciliation in collaboration with their Management Accountant to capture any
discrepancies or errors.

Forecasting: Monthly forecasts by phase are to be undertaken. These are to be consolidated and reported to
the Management Accountant at the start of each month.

Variations and contingency: The management and approval of project variations and contingency will be in
accordance with Steering Committee’s delegation. Please refer to the Delegations Policy on the PPL for
guidance. Contingency is the amount of money and time which are included in the estimate and schedule,

Page 10 of
Project Name: [Name] Project Governance Office Doc Version: 1.0 Project Code: ######
20
and provides for uncertainties in quality, pricing, productivity, activity duration and timing which are within the
defined scope of the Project. The Steering Committee will determine the usage of these funds.

Escalation: Refer to “Project Controls” for guidance on when and how to escalate financial matters.

6. Procurement/ Vendor Management Plan

If procurement activities are to be undertaken, consult with Enterprise Procurement/ICT Procurement for
assistance with a procurement plan and document the agreed approach.

7. Project Schedule

7.1 Schedule
Insert the project schedule diagram that summarises the key timeline and phases / work streams from the
project schedule. The schedule can be exported from your Project Online site, and included as an appendix.
To support reporting to different stakeholders, the following views of the schedule should be available:

 Level 1 - Management Level Schedule/Roadmap: provide an overview for senior management and
include key KPIs, Major Milestones and high-level summary activities

 Level 2 - Project Level Schedule: Traditional project schedule listing key tasks and activities.

 Level 3 - Control Level Schedule: View showing all the relationships between the various disciplines
and related projects/interdependencies.

7.2 Key Project Milestones

Insert key project milestones in the table below. This may also include required approval gates. Define the
acceptance criteria for the achievement of the milestone as agreed with the Project Sponsor/Owner.

Phase Milestone Acceptance Criteria Owner Estimated

Due Date

Page 11 of
Project Name: [Name] Project Governance Office Doc Version: 1.0 Project Code: ######
20
8. Issue Management Plan

8.1 Managing Issues

An issue is defined as an event/problem/matter that HAS occurred or a risk that has materialised and IS
affecting the project. The issues management process requires early identification, regular review and
management and escalation where required. The project team will take following approach to managing
issues that arise throughout the project lifecycle:
 All issues will be captured and monitored using the Project Issues Register, which will be located
within Project Online or equivalent.
 Any team member may log issues within their respective area of the project.
 New issues are to be entered in the Issues Register and assigned a severity level according to the
UQ’s Risk Standards.
 The initial severity rating of an issue will be determined by the person raising the issue.
 The Issues Register will be reviewed during the [insert appropriate governance forums e.g.
weekly Project Working Group/Team Meeting] meetings to assign owners, discuss resolution
actions, set target dates for resolution and update resolution progress.
 Issues with potential for material impact to project scope, interdependencies, benefits, budgets,
and / or timelines will be escalated to the Sponsor and/or Steering Committee, respectively for
visibility and to assist with resolution.
 All Critical and Significant issues are to be stored within the Issues Register on Project Online
(PPM).
Discuss the project’s approach to managing issues in consideration with the above requirements.

8.2 Issues Register

A Project Issues Register shall be used to capture all issues identified by the Project Team.

Issues Register location: [Location Path]

9. Risk Management Plan

9.1 Managing Risks

The Risk Management Plan identifies the risks and the mitigation strategies required to reduce or eliminate
this project’s risks. All risk management activities are to be in alignment with the Enterprise Risk
Management Framework.
The project team will take following approach to managing risks that arise throughout the project lifecycle:
 The project will develop a Risk Register to document and monitor all identified risks.
 The Project Manager is accountable for risk identification in consultation with the Project Team,
SME’s advice, external and internal stakeholders, and the Project Sponsor/Owner.

Page 12 of
Project Name: [Name] Project Governance Office Doc Version: 1.0 Project Code: ######
20
  Risks will be classified according to the UQ’s Enterprise Risk Management Framework and will
include identification and assessment of risks (Enterprise, Program & Project) and mitigation
strategies/plans to eliminate or address each risk. Mitigations for each risk will be documented and
regularly reviewed by project management and relevant stakeholders in the [governance body e.g.
Project Steering Committee.
 Risks rated as “Extreme” and “High” will be escalated to the Steering Committee to expedite their
management / resolution.
 The Risks Register will be reviewed during the [insert appropriate governance forums e.g.
weekly Project Working Group/Team Meeting] meetings to assign owners, discuss resolution
actions, set target dates for resolution and update resolution progress.
 Realised risks will be documented as a corrective action and the treatment strategy implemented.
 Risks that are realised that have not been captured in the risk register and no mitigation strategy
exists will have mitigation strategies developed and implemented.
 Risks that are realised and / or treated are captured in the project’s lessons learnt file.
 Risks are classified as either open, closed, or realised risk. If a risk is realised, it may be necessary
to submit a project variation as per the agreed change management/variation process.
 Risks under active management will be regularly reviewed and reported on the Status Report to the
[role / governance body receiving status report.

Discuss the project’s approach to managing risk in consideration with the above requirements.

9.2 Risk Register

A Project Risk Register shall be used to capture all risks identified by the Project Team. It includes the risks
identified and mitigation strategies.

Risk Register Location: [Path]

10. Quality Management Plan

To ensure the highest quality of deliverables, the Project team will ensure:
 Sufficient involvement of appropriate stakeholders to ensure that requirements are understood and
subsequently reflected in the work products;
 The consistent application of the Capital Investment Management Framework (CIMF) and industry
leading practice project management processes and techniques and regular review to ensure proper
application.
 Application of standard methodologies which include proven techniques to produce defined work
products and deliverables.
 The development and agreement of acceptance criteria for each deliverable to be produced so that
quality assurance processes can be applied to result in deliverables that meet these criteria and
hence the expectations of Project Owner and per discipline for each delivery partner e.g.IT, HR,
P&F).

Page 13 of
Project Name: [Name] Project Governance Office Doc Version: 1.0 Project Code: ######
20
  The development and enforcement of consistent and formal procedures with embedded checkpoints
for the review of work products and final deliverables produced by each team member – measured
against the agreed acceptance criteria.
 The development and continuous improvement of engagement team skills through training and skills
and knowledge transfer.
Provide detail on the project’s approach to quality management.

10.1 Quality Expectations

The project must meet the following quality expectations to gain acceptance:

Quality expectations What is the quality expected of the project’s product and what standards and
(Project Owner, processes will need to be applied to achieve that quality e.g. Project Owner,
Information Technology, Information Technology and Property and Facilities expectations? Where
Property & Facilities) possible, expectations should be prioritised.
Acceptance criteria What is the prioritised list of criteria that the project’s product must meet
before the customer will accept it – i.e. measurable definitions of the
attributes that must apply to the set of products to be acceptable to key
stakeholders (and, in particular, the users and the operational, maintenance
and support areas). Examples are: ease of use, ease of support, ease of
maintenance, appearance, major functions, development costs, operational
and support costs, capacity, availability, reliability, security, accuracy or
performance.
Project-level quality What are the tolerances that may apply for the acceptance criteria? Ideally,
tolerances these should be prioritised.
Acceptance method What is the means by which acceptance will be confirmed? This may simply
be a case of confirming that all the project’s products have been approved, or
may involve describing complex handover arrangements for the project’s
products, including any phased handover of the project’s products.
Acceptance Who will be responsible for confirming acceptance?
responsibilities

10.2 Compliance
Identify all quality standards associated with the project’s area of impact e.g. IT, P&F, HR.

11. Organisational Change and Communications Plan

11.1 Organisational Change

Provide details of how the organisational change aspects of the implementation phase will be covered. For
more complex projects, this section may reference a separate organisational change plan. Large initiatives
may require a Change and Communication Management Strategy.

Page 14 of
Project Name: [Name] Project Governance Office Doc Version: 1.0 Project Code: ######
20
12. Communication Strategy

Provide details of the communications activities that will be delivered to support the execution phase. For
more complex projects, this section may reference a separate communications plan. See appendix 1 for
guidance on minimum requirements if a separate plan is not required.

13. Benefits Realisation Plan

13.1 Benefits Profile

Source from approved Business Case. List the expected benefits and dis-benefits of the project. These
statements form the heart of the business case and need to be carefully presented and phrased in terms of
outcomes, not outputs. A supporting Benefits Management Plan and profile for each benefit will be required
to be developed. Benefits definitions can be found on the ITS Project Management webpage.

The planned benefits for this project are detailed in the following table:

Benefit Benefit Description Beneficiaries Benefit Priority

Classification Owner

Choose an item. Choose an

item.

Choose an item. Choose an

item.

Choose an item. Choose an

item.

Choose an item. Choose an

item.

Benefits Realisation Plan: [Path]

14. Transition to operations

14.1 Acceptance Criteria

Define specific acceptance criteria that will be required to be met, in order for the project deliverables to be
transitioned into operations. These should be agreed with key stakeholders, including the business owner
and support functions.

14.2 Hand Over

Describe items, information or knowledge that will be provided upon, who will provide it, and who it will be
provided to e.g. System Operating Model, Support Manual, Support Process, User guides, copy of all project
documentation, completed Project Implementation Review, etc.).

Page 15 of
Project Name: [Name] Project Governance Office Doc Version: 1.0 Project Code: ######
20
14.3 Post Implementation Support
Provide an overview on how support will be handled and deployed during the transition to operations.
Include resourcing and timing

14.4 Business as Usual Support

Provide information about how support will be provided to the system/product/process beyond the
transitional period.

15. Project Closure

15.1 Post Implementation Review

Articulate the Post Implementation Review approach and timing.

15.2 Formalising Closure

Describe what measures will be taken to formally close the project. This should include a formal project
review, checklist and confirmation of agreed project outputs, lessons learned sessions with the project team,
archiving of project documentation, etc.
Project Closure report shall be prepared by the Project Manager and submitted to the Steering Committee
and relevant governance committees at UQ. This occurs when the PMP documents are completed and
authorisation to close this project is received from the Project Sponsor.

Acceptance Criteria Verification Stakeholder Action/Key Approval

Document Deliverable Channel

16. Project Controls

16.1 Document Management

Describe how documentation will be managed, stored, etc. for the project’s duration. Approved project
artefacts are to be stored within UQ’s Records Management System. It is recommended a copy of all
approved core project artefacts are stored within Project Online.

16.2 Tolerances
Articulate the project tolerances as agreed with the project Steering Committee. The Steering Committee
and Project Manager should be familiar with the Financial Delegations Policy on the PPL and manage
expenditure as appropriate.

See Appendix 3 for Project Thresholds and Performance Indicators.

Page 16 of
Project Name: [Name] Project Governance Office Doc Version: 1.0 Project Code: ######
20
The following tolerances have been established to provide guidance on permitted deviations to project
parameters.

The project manager will report exceptions to the project board if at any time:
a) the forecast schedule tolerance of +/- # weeks ( or #%) on the target project end date of <date> will not
be met, or
b) the financial expenditure target of $#####, is likely to vary by +/- #/%, or
c) scope changes may erode business benefits anticipated; and
d) risks and issues (as per Risk and Issue Management Plan).

16.3 Project Variation Requests and Escalation

Variations required because of exceeded tolerances will be managed through the formal project variation
request procedure, detailed below:

 The variation request is documented within the Variation Request Template.

 The project manager will present the variation request to the appropriate governance committee
(Steering Committee, Capital Management Group) for consideration. If the tolerance has been
exceed, an out of session communication should be undertaken.
 The project manager will inform the relevant parties of the outcome and, if necessary, the Schedule,
Scope and/or Budget will be updated to reflect the change.

Page 17 of
Project Name: [Name] Project Governance Office Doc Version: 1.0 Project Code: ######
20
Appendix A
Change & Communication
A-1 Stakeholder Map

Stakeholder Position Title Impact

A-2 Communication Strategy

Activit Description of Audience/ Channe Coordinat Approv Frequen

y Activity/Informati Stakeholder l or er cy
on Required (Metho
d)

Project Management Plan 18

 Appendix B
Tolerance Thresholds and Performance Indicators
Tolerance Thresholds and Performance Indicators
Tolerance Tolerance Within Tolerance - Within Tolerance
Areas2/Performance Exceeded Requires Attention
Schedule >= 10% >= 6 – 9% >= 1 – 5%
+/- amounts of time on target
milestone dates
Budget >= 20% >= 10 – 19% >= 1 – 9%
+/- amount of
estimated/approved budget
Scope The scope has Minor changes to original Scope is in line with
significantly changed scope from baseline. approved Business Case.
from the approved
Business Case and
won’t support benefits
identified.
Risks3 Where Likelihood is Very Where Likelihood is Where Likelihood is
Open Risks High/High/Medium and High/Medium/Low and Medium/Low and
Consequence is Major or Consequence is Consequence is Minor or
Critical. Moderate or Minor Insignificant.
Issues4 Where Priority for one or Where Priority for two or Where Priority is Low or
Open Issues more is Critical or High. more is Medium. Priority for one is Medium.
Quality High likelihood Moderate likelihood that Quality meets defined
deliverables are not fit deliverables are not fit for quality criteria. Low
(Awareness only and not for purpose; issues purpose; issues and/or likelihood that deliverables
considered part of overall and/or potential defects potential defects may are not fit for purpose;
health as will be captured in will cause significant cause delays and/or potential defects and/or
risks and/or issues) delays and/or cost. cost. issues will not cause
delays.
Resources Resources unavailable. Known gaps in No gaps in resourcing with
Allocation/availability of Roles and resourcing to satisfy all roles and responsibilities
resources responsibilities unclear. roles and responsibilities satisfied.
currently being
(Awareness only and not addressed.
considered part of overall
health as will be captured in
risks and/or issues)

Stakeholder engagement Key stakeholders are not There is some Key stakeholders are
and communication engaged. Little visibility engagement with key engaged and participating
of project provided to stakeholders but positively. Communications
(Awareness only and not key stakeholders and participation is limited. are undertaken according
considered part of overall UQ community. Lack of visibility of to agreed communications
health as will be captured in Communications plan project to key plan.
risks and/or issues) activities unsatisfactory. stakeholders and UQ
community.
Overall Health5 Total >=2 points and at Total >=2 points and no Total <= 1 point
Red = 2 points least one category is categories are red.
Yellow = 1 point red.
Green = 0 point

2
Modelled on Prince2 Best Management Practice.
3
Enterprise Risk Matrix
https://governance-risk.uq.edu.au/files/392/Enterprise_Risk_Management_Framework_Policy_20171012.pdf
4
Criteria established in Issues table.
5
Overall Health is calculated by Schedule, Budget, Scope, Risks & Issues only.

Project Management Plan 19