PMFv4 3wtemplates2010v3

Project Management Framework
Project Management Framework Guide
The framework comprises this guide and a set of project management

templates, as referenced within this guide.
Updated by Michele Berrie and Robyn Warren

Project Portfolio Office
Version 4.3
December 2008
CRICOS Institution Code 00213J

PROJECT MANAGEMENT FRAMEWORK
PROJECT MANAGEMENT FRAMEWORK GUIDE
Version Control
Version Number Date Reason/Comments

1.0 14 March 2003 Additions and edits to document
1.1 1 April 2003 Additions and edits
1.4 12 May 2003 Additions and edits
1.5 19 May 2003 Additions and edits for SC, deletion of forms
category information
2.0 26 May 2003 Final edits and changes – to go to SC
2.1 30 May 2003 SC edits and changes
2.2 24 February 2004 Revision of PMF Guide for 2004, including
BCF and Internal Audit changes
3.0 1 May 2005 Post Implementation Review Report with
change in process for PIR and Activity
Completion Report, plus continuous
improvement changes to templates and PMF
Guide
4.0 19 May 2006 Revised version of the Risk Management
Plan to adhere to changes in the University
Risk Management Framework.
Revised version of the Project Proposal to
strengthen benefits realisation, more closely
aligned costings tables to reports from the
finance system and deliverables in time
frames.
Change Project Proposal to allow use for
Feasibility Study and Project Specifications
document, etc, also PMF Guide.
Workflow Approval Diagrams added to PMF
Guide.
Incorporation of a new Feasibility Study
Report to capture findings and encourage
PM’s to use this option to make the best use
of AMP (IT) funds.
Communication Plan revamped.
More generic PMF Guide, breaking out AMP
(IT) specifics
Plus continuous improvement changes to
templates and the PMF Guide
4.1 21 July 2006 Removal of the Business Case Framework
section
4.2 8 January 2008 Updated references to IT Governance groups
and process for project status reporting. Also
updated all project templates. See Key
Changes document for full details.
4.3 23 December 2008 New link to Risk Management Framework
Example of Project Registry with new colour
coding
Updated html links for QUT web sites
Table Of Contents
PART A – PROJECT MANAGEMENT FRAMEWORK INFORMATION ..................................................... 1
1 Introduction ...................................................................................................................... 1
2 Purpose ............................................................................................................................ 1
3 Following the PMF Guidelines ....................................................................................... 2
The PMF Guide and the Templates ............................................................................. 2
Rigour and Length of Project Documentation ........................................................... 2
Document Version Control ........................................................................................... 2
4 The Project Selection Process ....................................................................................... 3
AMP (IT) Information ..................................................................................................... 3
Approval Workflow Diagrams ...................................................................................... 3
Release of Funding for Projects .................................................................................. 4
5 Project Registry ............................................................................................................... 4
Project Stages in the Registry ..................................................................................... 4
6 Project Kill and Halt Points ............................................................................................ 5
7 Project Managers at QUT ................................................................................................ 6
8 Steering Committee Composition ................................................................................. 6
9 Additional Project Areas for Consideration ................................................................. 7
PART B – PROJECT PHASES AND TEMPLATES .............................................................................. 9
10 PMF Project Phases ...................................................................................................... 9
11 Project Phases and PMF Templates Diagram .......................................................... 10
12 Initiating Phase ............................................................................................................ 11
Project Notification ..................................................................................................... 11
Project Proposal .......................................................................................................... 11
Project Specifications Request.................................................................................. 12
Feasibility Study Request........................................................................................... 12
Feasibility Study Report ............................................................................................. 13
Streamlining with a Project Proposal into the Executing Phase............................ 13
13 Planning Phase ............................................................................................................ 13
Project Plan .................................................................................................................. 14
Work Breakdown Structure ........................................................................................ 14
Risk Management Plan ............................................................................................... 14
Quality Plan .................................................................................................................. 15
Communication Plan ................................................................................................... 16
14 Executing Phase .......................................................................................................... 16
15 Controlling Phase ........................................................................................................ 17
Project Monitoring ....................................................................................................... 17
Project Status Report.................................................................................................. 18
Project Change Requests ........................................................................................... 18

Integrated Change Control ......................................................................................... 18
Scope Change Control................................................................................................ 18
Time Control ................................................................................................................ 19
Cost Control ................................................................................................................. 19
Quality Control ............................................................................................................ 19
Risk ............................................................................................................................... 19
Communication ........................................................................................................... 19
16 Closing Phase .............................................................................................................. 20
Project Closure ............................................................................................................ 20
Post Implementation Review...................................................................................... 20
17 Future of the PMF ........................................................................................................ 21
18 Appendix A – Project Registry ................................................................................... 22
19 Appendix B – Key Players in a QUT Project ............................................................. 23
Primary Sponsor responsibilities .............................................................................. 23
Client Leader ................................................................................................................ 23
Steering Committee responsibilities ......................................................................... 23
Deputy Vice-Chancellor (TILS) – or nominee ........................................................... 23
Expert/Specialist responsibilities .............................................................................. 24
Internal Audit responsibilities .................................................................................... 24
Project manager responsibilities ............................................................................... 24
Project Reference Group ............................................................................................ 24
20 Appendix C – Communication Plan Checklists ....................................................... 26
Marketing and Communication Checklist................................................................. 26
Training Checklist ....................................................................................................... 26
Part A – Project Management Framework

Information
1 INTRODUCTION
This document contains a Project Management Framework (PMF) for QUT. The PMF
follows best practice project management guidelines with templates and completed
examples. Therefore, the PMF can be used as a standard, but flexible, methodology
for a wide range of projects across the University. The PMF is a mandatory standard
for Asset Management Program Information Technology (AMP (IT)), projects and
other IT projects at QUT. Projects in special disciplines like building construction and
those that follow ISO 9001 are generally exempt from the PMF.
This PMF Guide contains many details for AMP (IT) projects, which must follow the
processes closely, but the PMF can be applied generically to other types of projects.
Projects outside the AMP (IT) follow the PMF with the following differences:
 Funding sources
 Governance/approval body
 Project Portfolio Office interaction not essential, depending on circumstances
The PMF is composed of 2 parts:
 Part A with general information about projects at QUT.
 Part B with details of five standard overlapping phases through the life of a
project: initiating, planning, executing, controlling and closing. Activities and
project templates used within each phase are explained. The PMF templates
and examples for each are provided separately.
The Project Portfolio Office provides a focus for:
 Continuous improvement and maturity in project management at QUT
 Advice on this document and the PMF templates
 Connection to other, experienced project managers for guidance and
possible mentoring
 Direction for training in the PMF and project management more generally
 Applicability of the PMF
 Feedback on the PMF
The Project Portfolio Office email address is project_portfolio@qut.edu.au
2 PURPOSE
Systems and services at QUT have become increasingly more interdependent and
complex over time. This environment means that a standard, consistent and
comprehensive means to manage projects well at QUT is essential. The decision was
made several years ago to develop a custom project management framework that
would evolve as the project management community and the organisation matured.
The PMF would follow best practice guidelines from the Project Management Institute
(PMI) and its Project Management Body of Knowledge (PMBOK), which is an ANSI
standard. Certain project management practices already being followed in limited
areas at the University were also incorporated.
PMF_GUIDE_V4.3 PAGE 1 23 DECEMBER 2008

CRICOS INSTITUTION CODE 00213J
This approach has been highly successful. PMF V1.0 was released in July 2003 with
several later releases. The revisions introduced improvements over time
accompanied by an educative program from the Project Portfolio Office as
reinforcement. As a result the PMF is embedded in IT project management at QUT
and uptake is expanding into other types of projects.
3 FOLLOWING THE PMF GUIDELINES

Overall considerations for using the PMF are:
The PMF Guide and the Templates
The PMF Guide is a reference for the framework while separate PMF project
templates provide specific project documentation. Part B of this document provides
direction on when to use the templates within standard project phases.
Each template has guidance boxes for each of its categories/heading providing
specific information on the details to be included. Flexible changes in the templates
may be made where appropriate.
MS Project is the recommended support tool for PMF projects. However, the basic
PMF templates use Word tables. Calculations for costs and resources may benefit
from the use of an Excel spreadsheet.
Rigour and Length of Project Documentation
In general terms the length of project documents will be contingent on the scope and
complexity of the project. Documents should be as concise as possible with enough
information for monitoring, tracking and auditing purposes. Focused documents that
are referred to and used should be the goal, no matter what the size of the project. A
common complaint is that overly long documents may appear first-rate, but are never
read or referred to.
The project manager should perform a risk analysis when determining the rigour with
which the PMF should be applied to the project. The project manager should look at
the range of project management activities and consider the effort expended
compared with benefits gained. For example, a project that costs little but has
strategic value may benefit from a well-developed communication plan. The project
steering committee or other governing authority makes the decision on the extent to
which the PMF is to be applied.
Document Version Control
Project plans and other documents should use version control, that is, show the dates
when the documents and plans change with the reason for the change. If required, a
table for sign off should be included. If possible, indicate the changes. The changed
file may be saved as a new version if tracking the changes is difficult (as in a Project
Plan).
A two-tiered numbering system is the standard: for example, 1.0 and 2.3. A major
change requires an increase before the point, while a minor change means an
increase in the number after the point. Version 0.0 is the first draft of a document.
The filename of a plan should contain the version number and be contained in the
footer as an indicator.
Version control allows effective tracking and information for audit purposes.
A Version Control table is included with most forms and can be inserted where
necessary with other documents.

4 THE PROJECT SELECTION PROCESS

QUT will fund and progress those projects that provide the best value proposition for
advancing its mission and goals according to the QUT Blueprint and the IT Vision and
Strategy, taking into account financial costs and benefits. AMP (IT) projects follow a
well laid out set of processes for submission and approvals. Other projects may have
different governing authorities and funding sources, but the same general principle
applies. Approving authorities for those projects will adjust criteria to make approvals
according to their own circumstances.
AMP (IT) Information
The AMP (IT) Prioritisation web page, in the PPO web site, contains links to
documents containing detailed information specific to the AMP (IT), including
governance processes, funding eligibility and approvals processes.
Approval Workflow Diagrams
Limited Scope, Straightforward / Standard to Highly Complex Project Standard to Highly Complex Project
Streamlined Project with Known Product/Process with Unknown Product/Process
Notification Notification Notification
Project Proposal Project Proposal

Project Proposal Project Proposal (Project
(Feasibility Study)
Specifications)
Project Plans
Activity - Risk Feasibility Study
Completion Report - Quality Report
- Comm’n
Project Proposal (on

Activity
the basis of FS or
Completion Report
PS findings)
Project Plans
Post - Risk
Implementation - Quality
Review (For major projects) - Comm’n
Activity
Completion Report
Post
Implementation
(For major projects)
Review

Release of Funding for Projects

The PMF stipulates that the Project Proposal lays out the elements of a project for
consideration for approval by a governing authority. Approval means that funds are
reserved. Circumstances under which reserved funds are released into a project
account:
 Partial release for engagement of a project manager to prepare a Project
Plan (request through email, decided on a case by case basis) after
Project Proposal approval
 Approval to prepare a Feasibility Study (using the Project Proposal
template)
 Approval to prepare Project Specifications (using the Project Proposal
template)
 Approval of a streamlined Project Proposal that is treated as a Project
Plan for small projects. See section on Streamlining with a Project
Proposal into the Executing Phase in the write up for Project Proposal in
Initiating Phase in Part B of this guide.
 An approved Project Plan from the Planning Phase
AMP (IT) projects follow this process rigorously. The process can be modified for
other types of projects, as appropriate.
5 PROJECT REGISTRY
The Project Registry is a central repository document that provides information on
current and recently completed IT projects. Most projects in the registry are
information technology (IT) projects funded from the AMP (IT) budget, but other IT
projects also appear.
The Project Portfolio Office administers the Project Registry and produces a quarterly
report with a brief description of the projects and their current statuses, supplied by
the project managers.
Project Stages in the Registry
The Project Registry aligns with project phases in the Project Management Body
of Knowledge, PMBOK Guide 2000 (pp 30-31), tailored for QUT projects. See
Part B, the section on Project Phases and Templates later in this document for
more information on the templates to be used with the standard phases. The
Project Registry stages:
 Initiating
This stage begins with the lodging of a Notification Form, followed by
submission of a Project Proposal or Feasibility Study. Upon approval, project
funds are reserved.
 Planning
This stage includes the preparation and approval of a Project Plan. The
project steering committee or authoritative body must approve the plan. For
AMP (IT) projects the DVC (TILS) must then approve. Funds will be released
upon approval.
 Executing
This stage covers the implementation of the approved Project Plan. Project
Change Requests should be approved by the steering committee/governing
authority. Significant changes in AMP (IT) projects, for example, request for
additional funding, must also be approved by the DVC (TILS).

 Halted
This status indicates that project has paused while significant changes are
considered or taking place.
 Terminated
This status results when a project is killed at any stage, for whatever reason.
An Activity Completion Report is required.
 Closing
This stage involves completing or ending the project, as indicated through an
Activity Completion Report for all projects. Activity completion may mean a
successful completion of the project or an early termination during the
planning or execution stages of the project.
 Retired
After completion or termination, a project is retired after submission of a
Project Activity Completion Report for all projects and, then, a Post
Implementation Review, if required. A Post Implementation Review is
required:
o Upon completion or termination of all major projects
o For AMP (IT) projects upon completion or termination of any other
project at the request of the DVC (TILS)
See Appendix A to view an entry from the Project Registry.
6 PROJECT KILL AND HALT POINTS

The QUT Project Management Framework recognises that conditions may arise
during the life of the project that dictate that a steering committee or other
decision-making authority should end or halt a project before its completion.
Ending a project may be viewed as a positive outcome for all, depending on the
situation. For example, a global change in technology may mean that the
underlying technology in the project has become obsolete and killing the project
will have the positive outcome of funds and resources being released for another
project.
An alternative approach may be to halt the project while resizing the project,
addressing external factors, finding more funds or making other major changes.
Restarting the project will mean resubmission of appropriate documents and sign
off by approving authorities again.
Major kill and halt points are:
 A Project Proposal that is considered for approval and reserved funding.
 A Project Plan that is reviewed by the steering committee for confirmation
and final release of funds to proceed with implementation.
 A steering committee meeting in the execution phase of the project at a major
milestone point, during which reason to kill or halt the project is decided.

7 PROJECT MANAGERS AT QUT

The Project Management Body of Knowledge PMBOK Guide 2000 identifies key
project management areas in which all project managers should possess a degree of
proficiency, irrespective of the projects they are working on: integration, scope, time,
cost, quality, human resource, communications, risk and procurement. Additionally,
the PMBOK Guide specifies that project managers should have general management
skills: leading, communicating, negotiating, problem solving and influencing the
organisation. All these skills contribute to the success of projects in the complex QUT
environment in which business activities, systems and other projects are
interdependent and integrated.
The project manager should also be knowledgeable about the contents of this, the
QUT Project Management Framework (PMF) Guide and its associated templates.
Good managers for projects at QUT may be realised by:
 Hiring project managers with expertise already in place
 Encouraging professional standard project management accreditation
 Raising awareness of the opportunities for staff development in management,
negotiation skills, conflict management, etc, at QUT
 Providing opportunities for staff members to gain experience by working on
projects
 Supporting the placement of mentors with project management expertise
 Gaining knowledge of and training in the PMF.
Note that the amount of effort expended on project management activities depends
on the value and benefits that these activities bring to the project.
8 STEERING COMMITTEE COMPOSITION

A project should be guided by a steering committee working at a strategic level. Note
that a small project may have the sponsor as its entire governing authority without a
steering committee.
A steering committee should be small in number for best practice. A minimum
composition is:
 Sponsor - is accountable for the project, chairs the steering committee
meetings and has ongoing accountability for the outcomes of the project in
the form of its end product/services.
 Client Leader - provides QUT business leadership, ownership and guidance
to the project. This role is critical to the project. Client Leaders can ensure
that QUT’s leadership view is inserted into key areas of the projects, for
example, timing, cost and quality considerations. They will normally be
chosen on the basis of their having a keen interest in the outcome of the
project (as a user). They do not have line responsibility for the project’s end
product/services.
 Expert/specialist - often the key person who will be designing and building the
outcomes.
 The DVC (TILS) or nominee - required on all AMP (IT) projects and
designated by the DVC (TILS).
 Internal Auditor - invited as an observer to attend steering committees of
major projects. With AMP (IT) projects, Internal Audit is always queried as to
whether they wish to provide a representative on the steering committee.
QUT steering committees are able to use this model as a basis to form
memberships. Other members may be added, as appropriate.

The project manager is usually not a member, but reports to the steering committee.
In some instances, the project manager and specialist may be the same person.
See Appendix B for a list of roles and responsibilities of steering committees,
sponsors and project managers.
9 ADDITIONAL PROJECT AREAS FOR CONSIDERATION

The PMF is a set of guidelines for many areas of project management. Additional
aspects outside the scope of the PMF that should be considered for specific projects
are:
 Systems Development Framework (SDF) – A flexible framework with different
options for software and systems development available with the PMF templates
under Additional Documents. The SDF is available with the templates from the
PMF web site.
 HR Change Management – If workflow changes are part of the outcomes, the
QUT Change Management Policy web site should be studied and contact made
with HR to avoid problems. Workplace change should ideally be planned and
supported by the University planning processes. However, often change can be
relatively unexpected and may need to occur within more urgent timeframes. The
policy outlines key principles, procedures and practices that the University seeks
to apply to ensure the effective management of workplace change consistent with
sound management practice, relevant commitments outlined in University
enterprise bargaining agreements, and related policies and procedures.
 QUT intellectual property matters – Identification of intellectual property should
take place early in a project so that the decision can be made whether to protect
that intellectual property to the benefit of QUT. See the Intellectual Property
Policy, Appendix 22 of the Manual of Policies and Procedures and use the QUT
Copyright Guide. A QUT Copyright Officer is located in the Office of the DVC
(TILS).
 Equity – Project staff should always consider equity issues and include these
factors at the initial stages of the project. Refer to the QUT Equity web site for
information.
 Web Governance Framework – QUT’s Web Governance Framework should be
taken into account when evaluating and procuring applications and, also, when
managing web sites around the University. The Web Governance Framework
provides a model for the governance of websites and web content at QUT. The
framework addresses the issues of quality, accuracy, currency, accessibility, and
compliance (with corporate web policy and standards) of QUT websites. The
framework defines the necessary processes, staff roles and responsibilities,
which must be followed to ensure that websites and web content are
appropriately governed.
 Procurement – Tendering, purchasing and contract management are wide
topics best dealt with through the advice and procedures from the Department of
Financial Services. Additionally, see Web Governance Framework, above, if web
issues are involved.
 Open Source Software – The University should deploy and use Open Source
Software (OSS) where possible and efficient. Therefore, OSS should be
considered for all software procurement. It is recognised that OSS software may
be unavailable or unsuitable for specific situations. The Information Management
Office of the Australian Government provides the SourceIT web site with the
Guide to Open Source Software for Australian Government Agencies, an
excellent reference document.
 Griffith/QUT Collaboration – A collaborative IT relationship exists between the
Griffith Division of Information Services and QUT Division of Technology,
Information and Learning Support (TILS). The partnership between the two

Divisions under the Collaboration Program leads to possible synergies and cost
effectiveness with the sharing of capability, resources and expertise. Therefore,
options for collaboration with Griffith on a TILS project should be examined.
Contact the Project Portfolio Office at project_portfolio@qut.edu.au for
information, as required.

Part B – Project Phases and Templates

10 PMF PROJECT PHASES
The Project Management Framework is divided into five standard phases, as defined in the
Project Management Body of Knowledge, PMBOK Guide 2000 (pp 30-31), tailored for QUT
projects. Each phase has associated activities, but, additionally, the phases overlap.
 Initiating processes – preparing a notification followed by a project proposal, then,
gaining approval and reserved funding for the project. The end to end life of the project
must be taken into account at the proposal stage, for example, recognising that the
information for an Activity Completion Report at the end of the project should be
considered at the proposal stage and throughout subsequent stages of the project.
 Planning processes – defining and refining objectives, preparing the Project Plans
and associated sub-plans for running the project, then gaining final allocation of
funding.
 Executing processes – implementing the Project Plans; coordinating people and
other resources to carry out the Project Plans. Typically, this is the longest phase of a
project.
 Controlling processes – ensuring that project objectives are met by monitoring and
measuring progress regularly to identify variances from the plans; taking corrective
action when necessary; tracking the variances and changes. Controlling has much
overlap with other phases.
 Closing Processes – bringing the project to an orderly end: formalising and
communicating the acceptance or conclusion of a project, handing over to the ongoing
accountable area, completing an Activity Completion Report and, for major projects,
holding a post implementation review.
The project manager is not necessarily the one to facilitate each activity, for example, an area
manager may prepare a project proposal with the project manager being appointed afterwards.
Someone external to the project should conduct the Post Implementation Review, if required.
See next page for a diagram of a typical project as represented through the phases.

11 PROJECT PHASES AND PMF TEMPLATES DIAGRAM

A standard, generic project; time for and level of activities will vary with specific projects
Executing
Processes
Level
Of
Activity Planning
Processes Closing
Initiating Processes
Processes
Controlling Processes
Retired
Time
Project Templates
Notification Form
Project Proposal
Project Plan
Work Breakdown Structure
Risk Management Plan
Quality Plan
Communication Plan
Change Management Plan (optional)
Project Status Report
Project Change Request Form
Project Activity Completion Report
Post Implementation Review Report
Project Approval Project Confirmation
Resources Reserved Resources Governance Sign-off

12 INITIATING PHASE
Definition: declaring and authorising the project
This phase includes notification of the intention of developing a project proposal.
As part of the same phase, the authority controlling project resources, typically
funding, will approve or reject the proposal. With approval, the AMP (IT) projects
will have funds reserved for resources and governing authorities for other
projects may follow this process.
 Project Notification
 Project Proposal (may be used in three ways)
o Project Proposal - define the conceived project as the basis for
approving and reserving funding for a project.
o Project Specifications Request - request funding to prepare
detailed project specifications.
o Feasibility Study Request - request funding to conduct a Feasibility
Study, used to provide an analysis of the objectives, requirements,
and concepts of the proposed work
 Feasibility Study Report
See the Approval Workflow Diagrams in The Project Selection Process in Part A
of this guide for clarification of the approval process.
Project Notification
Project Notification advises that proposing and developing a project is being

considered. Information supplied is succinct and broad in nature.
This information may be used to review the list of other projects to determine
overlap or redundancy with these projects or systems and to identify integration
issues. The potential project may be discarded before much effort has been
expended if conflicts or other impacting factors are evident.
For AMP (IT) projects a Project Notification form must be completed and sent to
the Project Portfolio Office at project_portfolio@qut.edu.au. The AMP (IT)
Systems and Projects Advisory Group then reviews the potential project. Other
projects may be posted to a local database or list of projects, as available. No
facility for registering and tracking projects centrally outside the Project Registry
currently exists at QUT.
Project Proposal
The Project Proposal defines the conceived project as the basis for approving
and reserving funding for a project. Care must be taken in preparing the
document to present the project’s case accurately, so that the University has
relevant information to allow it to progress the most valuable projects.
Compelling reasons for carrying out the project in the form of specifying clear,
quantifiable benefits and mechanisms for realising them beyond the end of the
project are increasingly required.
The relevant business area usually prepares the project proposal. During the
process, the outcomes of the project must be considered and planned for. This
means that the Activity Completion Report (and Post Implementation Review for
a major project) and its requirements should kept in mind at all times during the
Planning Phase and throughout the life of the project. For AMP (IT) projects the
expectation is that a presentation on the completed Activity Completion Report
(and Post Implementation Review for a major project) will be made at project
end.

It is vital to consult as many stakeholders as possible in the proposal

process to ensure that all aspects of the project are considered and included in
the proposal, then in the Project Plan.
The proposal should clearly state key project information as shown in the
template, including objectives, scope, scope issues, project assumptions as well
as benefits and the business value to QUT linked to success criteria and risks.
Poor definition of the objectives and scope often lead to project failure; studies
suggest a strong correlation between project success and clear scope definition.
The proposal should contain information on alternative options, if available, with
a recommendation on which option to select.
An AMP (IT) projects, the Project Proposal should be submitted to the Project
Portfolio Office at project_portfolio@qut.edu.au as the office facilitates
governance.
Project Specifications Request
The Project Proposal template may be used to request funding to prepare

detailed project specifications so that accurate plans and budgets can be
developed where required. Then, a Project Proposal that incorporates
information drawn from these specifications may be submitted for the main
project.
A specification is basically the blue print (floor plan) for the project to be
developed and is vital in ensuring a finished product that satisfies all your
requirements. A detailed specification may include flowcharts, database designs,
screen designs and detailed descriptions on what the program does, etc. The
specification would also include a detailed pricing. It could involve a wide variety
of people, for example, project manager, business client, system analyst, graphic
designer, programmer, user, etc.
The documents should be submitted to the Project Portfolio Office at
project_portfolio@qut.edu.au for AMP (IT) projects.
Feasibility Study Request
The Project Proposal template may be used to request funding to conduct a

Feasibility Study, used to provide an analysis of the objectives, requirements,
and concepts of the proposed work, including justification, schedule, and
deliverables. Its main purpose it to determine the technical and financial viability
of a proposed change as well as to assist in identifying or clarifying activities,
cost, timeframes and/or requirements (system and/or business). During the
analysis, the objectives of the proposed work are defined based on the needs
identified.
Depending on the project, the Feasibility Study may be Stage 1 of a large
project. The Feasibility Study may also be used to conduct a preliminary part of
project where it is unclear how to quantify the resources or if the
product/system/process to be implemented needs to be identified before
progressing to complete a Project Proposal. See Approval Workflow Diagrams in
Part A of this Guide.
The outcomes of the study must be considered and planned for. This means that
the Feasibility Study Report requirements should kept in mind at all times during
the Planning Phase and throughout the life of the study. The output from the
Feasibility Study is a report detailing the methodology used, the evaluation
criteria, the study findings and recommendations.
Once the study is completed a Feasibility Study Report is required as the
outcome for the work undertaken. If the study recommends continuing with the
project idea then a Project Proposal for a new project should be completed and
submitted either with the Feasibility Study Report or soon after.

The documents should be submitted to the governing authorities for approval,

then to the Project Portfolio Office at project_portfolio@qut.edu.au for AMP (IT)
projects.
Feasibility Study Report
The Feasibility Study Report template is used to provide information about the
outcomes and success of a feasibility study. The report should include details
on methodology used, the evaluation criteria, options analysed with findings and
recommendations resulting from the study. Supporting documentation may be
included as appendices.
The report recommendations may support proceeding with a project or project
stage as a result of the study. In this case the Project Proposal should be
prepared. Both documents should be submitted to the governing authorities for
approval, then to the Project Portfolio Office at project_portfolio@qut.edu.au for
AMP (IT) projects.
Streamlining with a Project Proposal into the Executing

Phase
The governing authority, which is the DVC (TILS) for AMP (IT) projects, may
approve a comprehensive and complete Project Proposal as a Project Plan for
progression to the Executing phase for small, straightforward projects with
limited scope. The proposer may indicate the intention when submitting such a
Project Proposal.
Where requirements for such a project indicate, additional information or
documents may be required. Project managers should check the categories in
the Project Plan template and add them into the Proposal/Plan as needed for the
project. For example, a separate Communication Plan may be called for because
of widespread impacts of the project.
13 PLANNING PHASE
Definition: defining and refining objectives.
This phase requires completion of a Project Plan. A Work Breakdown Structure
and sub-plans are part of the Project Plan. The sub-plans may be incorporated
into the main Project Plan or may be separate, depending on the scope and
value of the project:
 Work Breakdown Structure diagram or Gantt chart
 Risk Management Plan
 Quality Plan
 Communication Plan
The Project Plan is a dynamic document that supplies an integrated suite of
information to coordinate, run and control the project. The level of detail depends
on the size of the project and impacts outside the local area. The project
manager should always bear in mind that an overly long plan may contain so
much detail that the documentation will never be read. An important
consideration is to use the PMF templates to ensure that the University has a
consistent approach.
The project manager will practise a wide range of skills, including technical,
communications, human resource and political to prepare the plan. Best practice
stipulates that the project manger should interact with key stakeholders to set up
the plan, thereby ensuring that the plan is well thought out, understood and

capable of being executed. A high degree of involvement of the project team is

desirable.
Finally, all should note that projects are dynamic and will change as they run
their course. The project manager should produce the best Project Plan possible,
but the stakeholders should be aware that changes will take place and plans will
be modified accordingly. Appropriate stakeholders should be kept informed of
any changes to the plans.
The Project Plan and its associated documents should be approved by the
steering committee, then considered by the governing authority for final approval.
For AMP (IT) projects a Project Plan approved by the steering committee should
be sent to the Project Portfolio Office at project_portfolio@qut.edu.au for PMF
compliance and for DVC (TILS) consideration and approval.
Project Plan
The Project Plan is a document that describes and brings together the
components of a project. In effect, the Project Plan is the guidebook for all to the
project. All aspects of the project should be covered, although the level of detail
depends on the size of the project. Detailed project specifications are outside the
PMF.
The Systems Development Framework is complementary to the PMF for
development projects and may be found on the Project Portfolio web site.
Work Breakdown Structure
A Work Breakdown Structure diagram is necessary.

The Work Breakdown Structure (WBS) is a foundation document in project
management and all projects should contain at least a high level WBS that
shows the main project products or phases with the main tasks. Then, the WBS
can provide the basis for planning and managing the key areas of the project.
Risks and costs may be referenced against the WBS, as well as time frames and
milestones. MS Project is recommended as a support tool to develop a high level
work breakdown structure.
Project plans for larger projects should develop multi-level WBSs. The extent
depends on the size of the project. Very large projects may have as many as five
levels in the WBS, rarely more, because each level requires the corresponding
amount of extra work. Adding a level to a WBS increases workload, as each
activity in each level must be tracked and recorded.
A graphical representation of the work breakdown structure can be used in
reports to management and steering committees as a visual means of showing
the status of the project.
QUT’s Risk Management Policy is available in the University’s Manual of Policy

and Procedures (MOPP A/2.5). A separate risk management plan is required for
all but very small or limited scope projects, using the PMF Risk Management
Plan (RMP) template. Small or limited scope projects may use the RMP template
or embed a limited risk table in the Project Plan, as judged by the project
manager and governing authorities. It should be noted that the risks identified in
the template are IT generic and must be reviewed, augmented and updated to fit
all risks specific to the project.

An important factor is that projects are dynamic and risks, as well as their
ratings, will change as the project progresses. New risks, unidentified in the early
stages, often emerge over time. Therefore, the project manager should review
the RMP regularly and make changes and additions, using the Version Control
table as a Change Log. The evolving RMP through the execution of a major
project should be included as part of steering committee meeting papers. For all
projects, a review of high risks, otherwise notable risks and changed risks should
be specified in the Project Status Report.
Details of managing risk at QUT are found in the QUT Risk Management
Framework. The framework is in line with the Risk Management Standard
(AS/NZS 4360:2004). An overview of the risk management process from the
QUT Risk Management Framework follows:
1. Establish the context: start the risk management process with a clear
understanding of the operating environment. In establishing the context it is
essential to identify and scope all influences (internal and external) which
may reasonably impact on QUT. The context includes financial,
operational, competitive, political (public perceptions/ image), social, client,
cultural and legal aspects of QUT’s functions.
2. Identify the risks: look at possible risks from all sources that will impact on
all stakeholders. Realise that unidentified risks may present major threats.
3. Analyse the risks: do to provide an input to decisions on whether risks
need to be treated and the most appropriate and cost-effective risk
treatment strategies.
4. Rate and evaluate the risk: make decisions, based on the outcomes of
the risk analysis, about which risks need treatment and treatment priorities.
5. Treat risks: follow five options: avoid the risk, change the likelihood of the
risk, change the consequences of the risk, share the risk, or retain the risk.
6. Monitor and review: follow through with regular monitoring and reviewing
and raise awareness as risks invariably change during the course of a
project.
Opportunities may also be included in the above processes. A similar set of five
options may be applied for treating risks with positive outcomes, that is, opportunities.
Quality Plan
A separate quality plan may be provided, using the Quality Plan template, as
appropriate.
Both the quality of the management of the project and the “product” of the project
must be addressed. Quality is the “totality of features and characteristics of a
product or service that bear on its ability to satisfy stated or implied needs”
(ISO8402). Three aspects of quality are taken into consideration: quality planning
and standards, quality assurance and quality control. Each aspect is addressed
in the quality plan specific categories.
As a minimum, the Project Plan should include the quality measures and
acceptance criteria.
If problems occur with quality, changes in other areas of the project may need to
take place, according to the integrated nature of projects.

Communication Plan
Communication strategies to address stakeholders previously identified in the

Project Proposal and any new stakeholders subsequently determined must be
formed.
A separate communication plan may be provided, using the Communication
Plan template, as appropriate. The template comprises tables for training
strategies, and marketing and communication strategies. A well-developed and
comprehensive Communication Plan using both tables meets the change
management needs for most projects. Keep in mind that managing change is
required in all projects to some degree because change is embedded in all
projects.
In fact communication is a critical component of every project plan because it
provides the vital link between the project, the client and success. When
developing a communication plan it is essential to answer the following
questions: Who will be impacted by this project? What type of change does this
project represent, is it only going to affect one department, or the entire
university? When is this change scheduled to occur? Where will this change
occur, and finally how will those impacted by this change be notified? By
answering these questions it will help you to identify the most appropriate target
audience to be communicating with and this will in turn determine the most
effective communication mechanisms you need to use in order to convey your
message. A communication plan is not static, but rather will develop as the
project progresses therefore it is imperative to continually revisit the
communication plan and update it as needed.
Project managers should contact their Marketing and/or Communications
Officers if available for advice on communication requirements for the project.
Within the ITS Department Client Relations Managers must be consulted and for
all AMP (IT) projects it is recommended that the ITS Client Relations Managers
be consulted. The ITS Learning and Development Unit has a cost-recovered
service and may also be consulted on course development and delivery. See the
Marketing and Communication Checklist and Training Checklist in Appendix C.
If the project involves workflow changes, HR must be contacted. See the section
on Additional Areas for Consideration in Part A of this guide for information on
HR Change Management.
14 EXECUTING PHASE
Definition: coordinating people and other resources to carry out the plan
Project plan execution involves implementing the plan by performing the
activities in the plan. The project manager must integrate related areas of the
project into a harmonious whole often by using a variety of techniques to engage
with stakeholders. External factors may exert an influence and need to be taken
into account. The project manager will again use a wide range of skills, including
technical, financial, communications, human resource and political. The aim is to
focus on pulling all activities and aspects of the project together to achieve a
successful end.
Changes and variances that occur to the plan during implementation feed into
the controlling phase of the project, which overlaps all phases of the project.
Project Change Requests are described in the section the Controlling Phase,
below.
The project manager will conduct regular project team meetings to discuss
progress on activities, project issues and keep track of developments. The
project may have a reference group to ensure an appropriately wide range of
issues are considered.

The project manager will organise steering committee meetings, which should be
included in the project schedule in the Project Plan, as described in the
Controlling Phase, below. The project manager will illustrate project progress
using a variety of methods, for example, a Gantt chart in MS Project or a
graphical representation of amount completed of the WBS. Regular reporting of
the monitoring and measuring of progress and other metrics must take place for
the steering committee.
The Project Plan should list milestones and kill points. The steering committee
will be advised of progress against milestones as the project executes to make
determinations of whether to continue execution of, halt or kill the project.
Appropriate stakeholders should be kept informed of any changes to the Project
Plan.
15 CONTROLLING PHASE
Definition: ensuring that project objectives are met by monitoring and measuring
progress regularly to identify variances from the plan so that corrective action
can be taken.
Controls show that the project is producing the required results (that meet
predefined quality criteria), is on schedule in meeting its targets using previously
agreed resources and funding and remains viable against its business case.
Controls balance benefits against costs and risks.
In conjunction with the execution phase, the project manager will be watching the
progress of the project and ensuring that variances from the plan are identified
and reported on and using a Project Change Request if required.
The project manager, the project team and the reference group will handle
operational issues and minor variances. The steering committee will take action
on major issues and deviations, which are strategic. The project manager should
prepare the presentation of information for the steering committee to make
informed assessments and decisions.
This phase includes:
 Project Status Report for regular monitoring and reporting
 Project Change Request for requesting significant project changes
Project Monitoring
The Project Plan should have included a schedule for steering committee
meetings and other key points to ensure regular tracking of project progress and
release of status reports. Additionally, the plan should have identified milestones
and project kill points, that is, go/no go decision points for the action of senior
management, the steering committee or other authority.
Steering committee meetings may be scheduled around milestone and kill point
dates, and while meetings are not formally required on a specific timeline (eg
every 4 or 6 weeks) it is expected that at least one meeting will take place within
a 3 month period. The project manager should prepare a Project Status Report
for the committee using the Project Status Report template provided. Additional
material may include specific highlights and achievements, as well as a visual
representation of stages of completion of the WBS and other issues such as cost
status. The mechanism for requesting changes is the Project Change Request.

Projects are dynamic. The Project Status Report indicates the areas of a
project that may vary as the project proceeds: integration, scope, time, cost,
quality and risk. Decisions may then have to be made to adjust the other areas to
compensate. If the schedule slips, then resources may be increased to bring the
project back on schedule to meet a critical deadline. An increasing focus of
attention in the report is risk management with review of project risks in each
report. Changes in or new risks may explain the need for variation in the project.
The Project Status Report is a tool for reporting on progress of the project
suitable for inclusion as a standing agenda item at steering committee meetings.
The report has a visual aspect that is valuable for a quick examination of the
status of the main project areas.
All Project Status Reports should be copied to the Project Portfolio Office
through email: project_portfolio@qut.edu.au in order to meet Project Registry
reporting requirements.
Project Change Requests
The project manager should use the Project Change Request to request a
significant change in the key project areas. The steering committee has authority
must approve all changes. Requests for significant changes, for example, any
requests for additional funding, must be submitted to the governing authority for
final consideration for approval.
For AMP (IT) projects, Project Change Requests approved by steering
committees should be sent to the Project Portfolio Office through email:
project_portfolio@qut.edu.au for consideration by the DVC (TILS).
Integrated Change Control
The Project Manager must have a holistic view of key areas of the project with a
view to recognising changes in those areas, how the changes impact on other
key areas and mitigation strategies. The project manager must also be aware of
how the project fits in with other QUT business activities, systems and projects
and be prepared to take action or raise awareness if problems arise on this front.
The steering committee must be alerted if change is significant, whether internal
or external.
Scope Change Control
The Project Manager should have worked closely with stakeholders so that the
Project Plan clearly defined the scope of the project, but a need for a scope
change may arise. The project manager should consider the request for change
in scope and make a formal submission to the steering committee with the
Project Change Request, which delineates the changes requested, impact on the
project completion date, resource requirements, risk versus returns, etc, and a
recommendation for approval.
Significant scope change and scope creep (numerous small changes) are a
major cause of project failure. The project manager is responsible for managing
the change, ensuring that the steering committee is aware of the change in
scope, the impacts of the change so that they make informed decisions.

Time Control
Finishing a project on time is a customary measure of whether a project has

been successful, but many factors may cause a project timeline to change. The
Project Plan should have built in contingencies (not necessarily financial).
Regular meetings with stakeholders and project team members are an important
means of checking the schedule. The project manager should be highly aware of
project progress with respect to time and inform the steering committee
accordingly.
Steering committee members need a visual overview of project schedule
progress, for example, a table of milestones for smaller projects and an MS
Project Gantt chart with larger projects. If serious problems occur, the project
manager must work with the steering committee to resolve the issues. An
alternative is to kill the project.
Cost Control
Comparing the actual project cost against the original planned cost is a
customary method of determining whether a project has been successful. As
with other elements of a project, costs are subject to change. MS Project is the
recommended support tool to track control costs for projects of sufficient
complexity.
All project costs should be recorded against the project and reported to the
steering committee. The project manager’s responsibility is to ensure accurate
reporting and suggested remediation so that the steering committee has all the
information needed to act correctly. The steering committee must approve and
authorise significant changes to the budget or kill the project.
Quality Control
The Project Plan should have both quality assurance and quality control
measures in place. Quality assurance evaluates the overall project performance
to ensure that the end products meet the project standards. Quality control
means monitoring and testing the project products using the chosen quality
assurance tactics.
Small quality faults can be dealt with operationally, but the steering committee
must be promptly informed if quality problems are major. Significant changes to
other areas of a project may need to take place to remedy the quality. One
choice may be to kill the project.
Risk
Risk management control is critical to the success of a project. Risks will

definitely change as the project progresses. Risks unidentified at the time of the
creation of the original Project Plan may appear, as well as new risks. As these
risks change and other risks present themselves, the project manager should
manage the situation, modify the Risk Management Plan and draw attention
through the Review of Risks in the Project Status Report to the steering
committee.
Communication
As with other key project areas, communications requirements are likely to

change. These changes may occur as a result of modifications in the other areas
of the Project Plan. For example, regular stakeholder meetings to discuss project
issues may determine that the project product uptake may be higher than
originally foreseen because the product is seen to be worthwhile, so that
communication updates must be at a broader level than originally noted in the

Project Plan or separate Communication Plan. A need for training may be

identified in the meetings and must be written into the Plan. A sometimes
overlooked is the inclusion of a factor to account for communication if setbacks
occur during implementation.
16 CLOSING PHASE
Definition: formalising acceptance of the project, bringing it to an orderly end
and reviewing
This phase provides the opportunity for the organisation to learn from the work
done via a review and analysis of metrics.
The forms for the closing phase:
 Project Activity Completion Report – required for all projects
 Post Implementation Review Report – required for major projects and for
other projects if requested by the DVC (TILS).
Project Closure
The project manager should carry out a controlled close to the project,
irrespective of whether the project was completed or ended early. Ongoing work
should be assigned to other staff, as appropriate. Project documentation should
be completed.
A Project Activity Completion Report should be completed for all projects and
sent to the Primary Sponsor and copied to the Project Portfolio Office through
email: project_portfolio@qut.edu.au
The Primary Sponsor is responsible for any resulting actions with consideration
and response to recommendations, as well as promulgating lessons learned, as
appropriate.
Post Implementation Review
All major projects require a PIR after completion. The DVC (TILS) may request a
PIR for any other project, for example, if more information is needed than
detailed in the Project Activity Completion Report.
The sponsor should make arrangements for the Post Implementation Review
(PIR) when the project closes, as required.
 Recommended composition of PIR team for a major project
(>$250,000):
o Chair (Not usually the project manager)
o 1 steering committee member
o 1 independent member from the client area
o 1 project team member
 Composition of a typical PIR team for a minor project:
o Project manager as organiser and leader
o 1 independent member
The review should take place within a time frame appropriate to the nature of the
project, often within three months, but as long as six months for a large project.
The Post Implementation Review Report form provided in the PMF templates
should be used.

The review should evaluate the way the project was run and assess whether the
projected benefits have materialised or will be realised in future. The review
should identify the highlights and good practices adopted during the project and
contain an evaluation/appraisal of events that occurred, lessons learned and
pitfalls to be avoided in future. The project manager, steering committee
members and designated stakeholders should have input to the review.
Supporting documentation should be supplied, depending on the size of the
project.
The report and other resulting documentation should be presented to the Primary
Sponsor. A copy should be sent to the Project Portfolio Office (email:
project_portfolio@qut.edu.au). The Project Portfolio Office will make the
appropriate governing bodies aware of the reports, ITGC for major projects and
DVC (TILS) for minor projects.
The Primary Sponsor is responsible for any resulting actions with consideration
and response to recommendations, as well as promulgating lessons learned, as
appropriate.
For AMP (IT) projects the report will be accessible to all through a link from the
Project Registry so that the knowledge gained during the project can be reused
and taken into consideration when planning and executing other projects.
Additionally the project manager for AMP (IT) projects may talk to the report at
project management improvement sessions, covering lessons learned and
recommendations from projects.
17 FUTURE OF THE PMF

The ongoing development of the PMF is an iterative process, with annual
reviews. The PMF will evolve to meet the increasing demands and complexities
of project management at QUT, always following best practice and drawing upon
the experiences of project managers and governance authorities at QUT.

18 APPENDIX A – PROJECT REGISTRY

An example of the Project Registry:
Key Red Serious significant issues Phase I Initiating
Yellow Noteworthy minor issues P Planning
Green No changes or issues E Executing/Controlling
White Closing C Closing
Purple Halted H Halted
Grey No report submitted -- --
Communication
Overall Project
Report Date
Resources
Project Name (A-Z)
Timeline
Budget
Scope
Phase
Risks
AMP (IT) Funded
Non AMP (IT) funded
Example project status report E Y Y G R R G Y
Example project status report P G Y G G Y G G
Example project status report E R G G G R G Y
Example project status report C W W W W W W W
Example project status report E P P P P P P P
Example project status report I G G G G G G G
Example project status report I Gr Gr Gr Gr Gr Gr Gr

19 APPENDIX B – KEY PLAYERS IN A QUT PROJECT

Projects have sponsors, steering committees, client champions and project managers.
Internal Audit may become involved. Projects may have reference teams, as required.
Primary Sponsor responsibilities
 Be chief champion of the project

 Have accountability for the project and ongoing accountability for the
outcomes
 Chair the project steering committee
 Advocate the project internally and externally
 Facilitate and support policy and funding recommendations
 Provide overview and direction for the project
 Resolve issues identified by the project manager when requested (and
agreed)
 Support the project manager in carrying out the project
 Monitor the project budget
 Monitor project risk
 Ensure that deliberations of the project are adequately recorded and
available to appropriate parties
Client Leader
The client leader should come from outside the project area to ensure objectivity.
 Participate as a member of the steering committee
 Provide business leadership and guidance to the project
 Assist the Primary Sponsor in championing the project
Steering Committee responsibilities
 Direct attention to the project at a strategic level

 Make strategic decisions where required
 Approve or kill the Project Plan
 Make decisions on whether to approve requested changes in the Project
Plan or kill or halt the project while the project is executing
 Ensure that the DVC (TILS) and ITGC are advised of significant project
issues through the Project Portfolio Office
 Provide guidance to the project manager
 Review project progress and issues with the project manager regularly
 Monitor the project budget: a key factor
 Monitor the project risk: a key factor that is increasingly important
 Resolve policy issues
 Escalate issues where required
Deputy Vice-Chancellor (TILS) – or nominee
The DVC (TILS) will indicate membership or designate a nominee.

 Participate as a member of the steering committee
 Ensure that communications and considerations of issues between the
project and project governance structure take place

 Contribute to identification and resolution of interdependent integration

issues
 Ensure that client needs are addressed to satisfaction in the project
Expert/Specialist responsibilities
For small projects, the expert/specialist may be the project manager and,
therefore, a full member of the steering committee.
 Provide technical expertise
Internal Audit responsibilities
Internal Audit should always be asked at whether they wish to provide a

representative.
 Undertake an observer role on the project steering committees with rights of
audience and debate
 Provide advice on internal controls, including computer system security
 Provide advice on the application of project management principles
Project manager responsibilities
 Manage the project taking into account integration across all areas
 Engage with stakeholders
 Develop Project Plan
 Direct project resources
 Monitor and manage the project schedule
 Monitor and manage the project budget
 Monitor and manage the project risk
 Deal with operational issues
 Organise steering committee meetings, including ensuring that minutes will
be taken
 Report to the steering committee, raising strategic issues
 Prepare Project Status Reports and Project Change Requests for the
steering committee
 Ensure project meets requirements and objectives
 Manage project team members
 Negotiate and resolve issues as they arise across areas of the project and
where they impact on other QUT activities, systems and projects
 Look after the interests of the project team
 Organise and chair project reference group meetings, as appropriate
 Communicate project status to project sponsor, all team members, and other
relevant stakeholders and involved parties
 Maintain project documentation
Project Reference Group
A group of stakeholders brought together to discuss and deal with operational

issues for the project. Members may be part of the main project team, but, also,
clients/users from areas across the University that will be impacted by the
outcomes of the projects. Reference group members should:
 Bring operational issues from their areas to the reference group meetings
 Look for collaborative solutions
 Disseminate needed information and actions resulting from the reference

group meetings to their areas
 Act as a team for the sake of the project

20 APPENDIX C – COMMUNICATION PLAN CHECKLISTS

The following checklists will assist in drawing up a stakeholder Communication Plan
that includes training. All stakeholders must be considered. Marketing and/or
Communications Officers in faculties and divisions should be consulted if available.
Within the ITS Department Client Relations Managers must be consulted and for all
AMP (IT) projects it is recommended that the ITS Client Relations Managers be
consulted. The ITS Learning and Development Unit has a cost-recovered service and
may also be consulted.
In the tables below, the consultant is labelled “the expert”.
Marketing and Communication Checklist
Communication and marketing aspects to be taken into consideration for a project.

Use the items in the checklist as appropriate:
Y/N Points for Marketing and Communication

Consultation with the expert at Project Proposal stage
Consultation with the expert at Project Plan stage
Assessment of risks (for example, messages about unforeseen problems with project
implementation)
Realistic time frame for development and delivery of marketing and communication
elements (for example, brochures)
Allocation of budget for marketing and communication (for example, costs of design
and printing)
Designation of project manager or team member to be accountable for ensuring the
quality of the information (for example, right time, format and audience)
Agreement of marketing and communication strategies/actions by the expert
Training Checklist
Training aspects to be taken into consideration for a project. Use the items in the checklist
as appropriate:
Y/N Points for Training

Consultation with the expert at Project Proposal stage
Consultation with the expert at Project Plan stage
Assessment of risks (for example, more training required than estimated)
Realistic time frame for development and delivery of training materials
Attention given to type of training and supporting materials
Decisions on who will develop training materials and who will do the training (for
example, QUT staff or external)
Consideration of ongoing training needs and support
Allocation of budget for training (for example, development of course)
Designation of stakeholder to be accountable for ensuring the quality of the training
from the clients’ or business point of view
Agreement of marketing and communication strategies/actions/budget by the expert
A more extensive checklist that can be generally applied to projects is available from ITS
Learning and Development:
http://www.its.qut.edu.au/training/checklist.pdf
NOTIFICATION FORM
NAME OF PROJECT
Project Notification Form

Project Notification Form is a brief document advising of the intent to develop a project.
The funding authority provides advice to either proceed with a project proposal or to liaise with
other project managers/project proposers to consider obvious intersections with the work
proposed. See the Approval Workflow Diagrams in The Project Selection Process in Part A of the
PMF Guide for clarification of the process
For potential AMP (IT) projects, the Notification Form should be sent to the Project Portfolio Office
at project_portfolio@qut.edu.au for prioritisation.
See the example of a completed Project Notification Form.
Guidance boxes like this are displayed in MS Word Print View (not in Normal View). They should be deleted when you
have finished with the contents: position the cursor on the border, left click when a cross appears and press delete.
1 PROJECT INFORMATION
Project Number (if applicable):
Project Name: A brief name to describe the project
Date: Of project notification
Project Ownership: Area responsible for project
Project Contacts:
Name Position Phone Email
Primary
Other
Other
Project Approval: Authority for project funding (example, Information Technology

Governance Committee through AMP (IT) budget)
2 OBJECTIVES
The aims of the project: the compelling reason(s) for carrying out the project and the overall
outcomes. These outcomes should be clearly defined and may include a justification or
consequences of not proceeding.
Type in your project information below, then delete this guidance box: position the cursor on the border, left click when a
cross appears and press delete.
3 SCOPE
PMFNotificationFormV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 1
NOTIFICATION FORM
NAME OF PROJECT
The activities and tasks contained in the project, showing the boundaries of the project. This
section may include the activities outside the scope.
4 INTERDEPENDENCY WITH OTHER SYSTEMS AND

INFRASTRUCTURE
A statement on impacts of the outcome of the project on other systems and QUT infrastructure,
as well as impacts of other key systems and QUT infrastructure on the project, if applicable.
Projects must integrate with QUT business dates, with existing services and systems and with
each other.
cross appears and press delete
5 PROJECT COSTS
A rough estimate of the funding required that is envisaged for the project. Specify the expected
source of the funds.
6 TIMING & DURATION
A rough estimate when the project would take place and the duration.
PMFNotificationFormV4.3
PROJECT PROPOSAL
NAME OF PROJECT
Project Proposal
The Project Proposal lays out the elements of a project of any size and complexity to bring
together all its components, present details and provide information for approval of the project in
the Initiating phase. This template may also be used to seek approval to conduct an initiative such
as detailed Project Specifications, a Feasibility Study, a Business Process Analysis, or a
Marketplace Scan (RFI, RFO or RFP).
A steering committee should have first approval of the Project Proposal, followed by approval by
the funding authority. For example, ITGC approval for AMP (IT) projects results in funds being
reserved for the project. See the Approval Workflow Diagrams in The Project Selection Process in
Part A of the PMF Guide for clarification of the process.
A completed Project Proposal for a project that seeks funds from the AMP (IT) budget should be
sent to the Project Portfolio Office at project_portfolio@qut.edu.au for prioritisation.
If your project is small, consult Streamlining with a Project Proposal into the Executing Phase in
Part B of the PMF Guide for information on using a well-developed Project Proposal as a Project
Plan. Check the Project Plan template headings and copy any category into your Proposal/Plan
that needs more information than the Project Proposal alone provides. You may also add a
separate Risk Management Plan, Communication Plan or Work Breakdown Structure, as
appropriate for the project.
The PMF Guide also has additional information on how to use this template for an initiative like a
Project Specifications Request, Feasibility Study Request, a Business Process Analysis or a
Marketplace scan (RFI, RFO or RFP).
Guidance boxes like this are displayed in MS Word Print View (not in Normal View). They should be deleted after you have
finished with the contents: position the cursor on the border, left click when a cross appears and press delete.

Date: Of submission of the proposal
Project Contacts:

Primary
Other
Other
Project Approval: Authority for project funding (example, Information Technology

Governance Committee through the AMP (IT) budget)
PMFProjectProposaLV4.3
PROJECT PROPOSAL
NAME OF PROJECT
2 VERSION CONTROL
Add new rows to the table that follows as necessary.
Version
Date Reason/Comments/Approvals
Number
3 BACKGROUND
A concise history of events leading up to the need to propose the project giving an explanation
of why the project is needed.
Type in your project information below, then delete this guidance box: position the cursor on the border, left click when
a cross appears and press delete.
4 OBJECTIVES
The aims of the project, the overall outcomes, presented with clarity.
Projects should be broken out into “chunks” or stages. Multi-year projects should show annual
objectives. Funding is reserved and, later, released accordingly.
Type in your project information below, then delete this guidance box: position the cursor on the border, left click when
5 SCOPE, CONSTRAINTS, ASSUMPTIONS
section should also outline activities outside the project scope and any assumptions that the
project is based on. Whoever is preparing the project proposal should make considerable
efforts to establish the scope with the stakeholders. Scope verification and clear user
requirements are important aspects for gaining agreement with the stakeholders. The better
the outcomes are defined, the less probability of dramatic scope changes or scope creep.
Projects should be broken out into “chunks” or stages. Multi-year projects should show annual
objectives.
To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
Scope
Within Scope
Outside Scope
PROJECT PROPOSAL
NAME OF PROJECT
Constraints
Assumptions
6 INTERDEPENDENCIES WITH BUSINESS ACTIVITIES, SYSTEMS

AND OTHER PROJECTS
A listing of major interdependencies and possible impacts to draw attention to QUT

integration issues in the complex university environment.
Interdependent Activity Possible Impact
PROJECT PROPOSAL
NAME OF PROJECT
7 BUSINESS CASE: COST/EFFECTIVENESS ANALYSIS

The proposal should present the approving authority with firm business reasons for carrying
out a prospective project. The business case shows the benefits and added value of the
project for the business area and to QUT. Clear strategic alignment and financial benefits
are increasingly required. List only those benefits contained within the scope of the project.
Guidelines for benefits:
1) A method for measuring the improvement or value should accompany each benefit. The
monitoring and measuring will take place throughout the life of the system or service, long
after the project and its Post Implementation Review are completed.
3) During the project the project team should establish baselines for measurements that
continue into the operational phase for comparison.
2) Details on the method of measurement after the project ends should be handed over to
the service or product owner at the time of transition from project status to operational.
4) Quick wins during the project and immediately after should also be identified if possible.
Strategic Alignment: Use the QUT Blueprint and top-level plans located through the FRP
web page to demonstrate the value of implementing the project, for example, improves
research outcomes by ……..
Financial Benefits: Include the measure of determining savings or increase in revenue.
How to use standard techniques like Return On Investment and Net Present Value are
easily available on the Internet and in textbooks, if required.
Benefits How to Measure

Strategic alignment with QUT Blueprint & University Plans
Financial: quantitative, for example, saves money, increases revenue
Other, for example, legislative compliance, infrastructure refresh, local benefit
Impact of NOT proceeding How to Measure
PROJECT PROPOSAL
NAME OF PROJECT
8 STAKEHOLDERS
Stakeholders are individuals and groups that are actively involved in the project or whose
interests may be positively or negatively affected as a result of the execution or completion of
the project. Typical stakeholders are QUT students, the project manager, the sponsor, the
project team members, the steering committee, staff members in the business area and those
with equity issues.
Stakeholder Interest in Project
9 SIGNIFICANT RISKS
The major risks to the project and treatment strategies, including mitigation. The probability
and impact ratings cover the risks.
Major Risk Probability: Impact: Risk Treatment

H, M, L H, M, L
PROJECT PROPOSAL
NAME OF PROJECT
10 COSTS AND RESOURCES
The proposal should provide an overview of the project costs and resources in the table below,
which aligns with Oracle Financials reporting.
Overview: Projects should be broken out into logical “chunks” or stages. Funding may be reserved
for multiple stages or for a single stage with new submissions for later stages as the project
progresses. If alternative approaches to the project are possible, break out into Option 1 and Option
2 (or more) with a recommendation on the choice to make. (Delete option table if unused.)
Salaries: These should be calculated using the HR Salary Scales - Professional Staff table and the
HR Oncosts. Show end to end costs, including those that will be absorbed, for example, salaries
from the Operating Grant. Modify the Costing Schedule as required, for example, a staff
development allowance on a longer contract salary. Salaries for extra Helpdesk staff, extra
communications and other technical staff may have to be factored in as well, especially considering
the risk that the implementation may go adversely. For major projects include a salary cost
component for the Post Implementation Review.
Totalling costs: The Grand Total comprises end to end costs, as indicated in the line items of the
table. The amount from Operating Grant will be absorbed, but should be shown as indicated.
Specify any other funding known in Total from other Funding, for example, a co-contribution from a
faculty. Show the amount being requested in the proposal in Total Project Funds Requested. (All
three should add up to the Grand Total). If project funding will be required across two calendar
years, specify the years and amounts.
Capitalisation of Developing Software: Resulting assignment of capitalisation percentage is not
always straightforward. The local financial officer or FRP may be consulted, as required.
Other: may include extras such as costs for BPR, as required.
Ongoing costs: This section with table to provide information on funding required after the project
makes the transition to operational must be completed. The table should include figures for the
ongoing costs of the continued maintenance and support of the products of the project when the
project has ended. The funding source that will provide the ongoing resources must sign off on
these costs or the project may not proceed – a project kill or halt point.
Use MS Excel if calculations warrant the use of a spreadsheet, or MS Project.
10.1 Costs and resources during the life of the project:
# Category Details Length Funding Amount

of Time Source
(eg, Op
(as
Grant or
applicable)
AMP (IT))
Recommended Option 1
Salaries
PROJECT PROPOSAL
NAME OF PROJECT

of Time Source
(eg, Op
(as
Grant or
applicable)
AMP (IT))
Non-Capitalised Expenditure, including Hardware <$5K and Software <$100K
Travel & Related Staff Development & Training
Other, Including General Consumables, Printing and Stationery, Telecommunications,

Consultancy and Contractors
Capitalised Expenditure, including Hardware >$5K, Software >$100K
Grand total (all costs)
Total from Operating Grant
Total from other funding (eg, faculties, carry forwards)
Total project funds requested, (eg, from AMP (IT))
Year(s) to receive above requested funding (eg If total requested = $100K, Year 1 –
then, 2008: $40K, 2009: $60K)
200x: amount
Year 2 –
200x: amount

of Time Source
(eg, Op
(as
Grant or
applicable)
AMP (IT))
Option 2
Salaries
PROJECT PROPOSAL
NAME OF PROJECT

of Time Source
(eg, Op
(as
Grant or
applicable)
AMP (IT))

Capitalised Expenditure, including Hardware >$5K, Software >$100K and Developing

Software
then, 2008: $40K, 2009: $60K)
200x: amount
Year 2 –
200x: amount
10.2 Basis for estimated project costs
An explanation of the basis of estimated costs above.

Type in your project information below, then delete this guidance box: position the cursor on the border, left
click when a cross appears and press delete.
10.3 Ongoing costs after project completes:
PROJECT PROPOSAL
NAME OF PROJECT
Break out into Option 1 and Option 2 if appropriate.
To delete this guidance box: position the cursor on the border, left click when a cross appears and press
delete.
Ongoing Detail Funding Annual Name of

Support & Source after Amount Delegate of
Maintenance Project Ends Funding Source
Who Agreed
Salaries
Equipment
Software
Other
Annual Total
10.4 Basis for estimated ongoing costs

10.5 Recommendation
If 2 options (or more) have been proposed, a recommendation for the preferred option with
an explanation for the selection should be presented.
PROJECT PROPOSAL
NAME OF PROJECT
11 SPONSOR, PROJECT MANAGER, STEERING COMMITTEE
The proposal should name the individuals who will be of key importance to the success of
the project and indicate their stake in the project. All should be chosen carefully because of
their future impact on the project and should understand their roles and obligations. The
sponsor or appointed delegate should Chair the steering committee. The project manager
may not yet have been appointed.
For a small project or feasibility study, a scaled down authoritative body or simply the project
owner may be appropriate.
See Appendix B in the PMF Guide for details on the roles and responsibilities.
Project Role Name QUT Position Interest in Project

Sponsor
Client Leader
Project Manager
Expert/Specialist
Steering Committee
member
DVC (TILS) or
nominee
Internal Audit
representative
12 PROPOSED TIME FRAME

The proposal should contain a time frame in a table with major milestones, with
deliverables indicated specifically. The milestones will be at significant project times and
can be used as indicators for reports, steering committee meetings and project kill points.
Allow time for transition from project to operational with a handover to the service owner.
An Activity Completion Report should be factored in, as well as a Post Implementation
Review for a major project.
Activities, Milestones, Time Frame Kill/Milestone

Deliverables Date
The example will not always be using the up-to-date template. The latest templates can be found
at http://www.its.qut.edu.au/pp/framework/pmftemplates.jsp
FEASIBILITY STUDY REPORT
PAYABLES ON-LINE APPROVAL PROJECT
Feasibility Study Report

Project Number (if applicable): 2005-54
Project Name: Payables On-Line Approval with OCR Document Imaging
Date: 8 March 2006
Project Ownership: Finance and Resource Planning
Project Contacts:

Primary Ruby Khaw Project Manager x2232 r.khaw@qut.edu.au
Other Robert Bryde Associate Director, x1763 r.bryde@qut.edu.au
Financial Systems
Project Approval: Information Technology Advisory Committee through the AMP (IT)
budget
2 VERSION CONTROL
Version
Number
1.0 10/01/2006 Robert Bryde - Draft
2.0 06/02/2006 Ruby Khaw, Robert Bryde - Statistics included. Also other
changes
2.1 13/02/2006 Ruby Khaw, Robert Bryde - Costings, Cost/Benefit analysis
2.2 24/02/2006 Ruby Khaw, Robert Bryde - Minor revisions
2.3 03/03/2006 Ruby Khaw, Robert Bryde - Major revision
2.4 08/03/2006 Ruby Khaw, Robert Bryde - Minor modifications
PMFFeasbilityStudyReportV4.1
3 MANAGEMENT SUMMARY
An important aspect of QUT's financial administration strategy is development of a robust and

cohesive financial administration framework, based on appropriate and clear policies and
procedures, and supported by effective administrative systems
(Business & Service Improvement (BSI) Program – Financial Administration Terms of Reference)
BACKGROUND
The use of rubber stamps since 2003 has been a stop gap measure for ensuring that
payments were legitimately authorised. The intention was always to implement a more robust
method using the electronic approval of invoices in Oracle Payables.
The implementation of Oracle Financials 11i in August 2005 now provides the opportunity to
replace the rubber stamps.
ITAC considered a project proposal for the Payables On-Line Approval with OCR Document
Imaging project in July 2005. The project proposal provided for an investigatory study option.
ITAC requested that the investigatory study be undertaken and that the following aspects be
considered during the study:
1) mapping current and future processes,
2) conducting workshops with stakeholders and obtaining agreement on the final process,
3) determining cost savings surrendered as a result, and
4) determining funding sources for the main project, including from the business area.
A revised project proposal based on the outcomes of the study was to be provided to DVC
(TILS) through the Project Portfolio Office.
This report on the investigatory study was endorsed by the project steering committee on
March 9 2006.
CONSULTATION
A reference group was formed with broad representation from all faculties and divisions. The
group provided valuable feedback for the investigatory study. In addition, a Steering
Committee was established with membership from key areas in QUT.
The dominant issues identified during the consultation process were:
• Internal control and accountability in the University Library
• Accountability and processing inefficiency with goods receipting and invoice payment
• Duplicated Accounts Payable records
• Staff reimbursements efficiencies
There has been broad consensus across the University community of the significance of
these issues and the process improvements and recommendations arising from the
investigatory study.
PROJECT DELIVERABLES
The key deliverable of the project is an integrated scanning and workflow solution providing:
• Use of online invoice approval functionality in Oracle Payables
• Electronic record keeping
• Timely entry of invoices
• Integration between Alesco Payroll and Oracle Financials
PROJECT BENEFITS
The outcomes of the project will add significant value to the university in the following ways:
• A set of common Purchase to Pay business processes across the University
community providing greater accountability and control
• Elimination of paper records for Accounts Payable
• Elimination of duplicate records and processes across the University
• Substantial efficiency gains in invoice processing
• Significant savings arising from productivity improvements and improved cash
management with payment scheduling and discount opportunities
• Improved service to staff and suppliers with timely payments
The associated savings have been estimated at $300,000 per year. These savings will be
considered in the context of the impending BSI Review of financial processes later this year.
PROJECT COSTS
The Business Case Framework has been used to determine an overall project cost of
$393,000. The framework includes estimates based on supplier quotations, experience with
similar projects and information from the University of Melbourne for their implementation. In
kind contributions from Financial Services and CIS form part of the costs of the project.
Further, Faculties and Divisions have been requested to consider in the context of potential
benefits realisations, a contribution to the project’s implementation costs equating to one-third
of the project budget (i.e. $130,000).
Faculty and Division responses to this request will be separately provided to the DVC (TILS)
for consideration as part of total project financing. Further progression of this matter will, if
required, need to be progressed through VCAC or ITAC.
PROJECT TIMEFRAME
The project’s major activities and timelines are:
October 2005 - March 2006 Project initiation and investigatory study. Steering
committee established.
April 2006 - August 2006 An initial implementation with participation from a
major business area and/or faculty
September - November 2006 Rollout across the university
November 2006 Establish gateways for electronic documents from
suppliers
CONCLUSION
The investigatory study has received positive support across the University. On the basis of
the benefits and costs of the project, a revised project proposal should be forwarded to the
Deputy Vice Chancellor (TILS).
4 INTRODUCTION
The purpose of this report is to document the investigatory study to determine the feasibility of
applying on-line approval and scanning technology to the accounts payable business
process.
A revised (PMF) project proposal for consideration by the DVC (TILS) will be drafted based
on this report.
Background
In 2003, the QAO identified deficiencies in the authorisation for payment of standard invoices
and staff reimbursements. Several options were canvassed, including the use of electronic
approval in Oracle Financials. The use of an approval stamp by financial delegates was
ultimately introduced as a means of ensuring that payments were legitimately authorised.
In November 2004, QUT commenced a project to upgrade its then current version of Oracle
Financials (11.0.3) to the latest version available (11.5.10). At the outset, it was decided that
the upgrade project would involve only the upgrading to the latest version as a baseline. This
was completed successfully in August 2005.
The intention was to then commence a series of projects to leverage new functionality and
technology available in the new version, including online Accounts Payable invoice approval.
The project proposal for the Payables OnLine Approval (POLA) Project was originally
submitted to the Information Technology Advisory Committee (ITAC) in May 2005. That
proposal was for a project of about 6 months’ duration to implement the online approval
functionality in conjunction with scanning technology. The approach and solution was based
on a similar implementation at the University of Melbourne. The proposal was not linked with
any other initiatives, nor did it place the POLA project in the context of a major improvement
to the Procure to Pay process.
Consequently in July 2005, ITAC approved the proposal, but directed that an investigatory
study be undertaken and a revised project proposal, based on the outcomes of the study, be
provided to the DVC (TILS) for further consideration. ITAC provided $30,000 to FRP to
undertake the study.
A steering committee, with broad representation, to oversight the project has been
established. High level governance is also provided by the recently convened FRP projects
governance committee.
The study commenced in November 2005 and was concluded in March 2006.
Objectives
The primary objective of the project is to provide QUT with a more streamlined, efficient and
state of the art business process that delivers significant cost savings across all areas of the
University and enhances the internal control framework surrounding the Purchase-to-Pay
process.
The study objective is to establish a documented business case having regard to savings and
alternate funding opportunities arising from a targeted assessment of the Purchase-to-Pay
business process.
5 FEASIBILITY STUDY METHODOLOGY

5.1 Consultation with the University Community
Working Party
A working group was formed with broad representation from the university
community. The participants were:
Name Role Cost Centre

Daniel Donovan Budget & Resources Coordinator Creative Industries
Shally Ho Finance Officer Faculty of BEE
Debby Lamprecht Finance & Budget Officer Faculty of Business
Carol Partridge Administration Coordinator Faculty of Education
Amy Bachman Finance & Resources Coordinator Faculty of Health
Betty Lee Budget & Resources Manager Faculty of IT
Gail Turnbull PA to Head of School QUT Carseldine
Maria Field/Melanie Waugh Administration Officer Faculty of Science
Kathie Thomson Administration Officer Chancellery
Jo Blakely/Bradley Ryan Budget Officer Administrative Services
Shannon Fitzsimons Divisional Administration Officer Finance & Resource
Planning
Sothy Be Administration Officer TILS
Lilli Gooch Finance Officer International & Development
Dianne Major Administration Officer Research &
Commercialisation
Tracey Hodgkin Manager, Accounting Operations Financial Services
Russell Lawrence Senior Finance Officer – Accounts Financial Services
Payable
The working party met 9 times over the period November 2005 through February
2006. The main focus of the working party was to contribute to the development of
possible business processes consistent with the objectives of the project. An
underlying objective was to engineer processes that could be applied equally across
the university community.
In addition to this forum, interviews were conducted with the:
• University’s Accounts Payable section,
• University Library (procurement section),
• Faculty of Business,
• IHBI, and
• ISIS project representatives
Issues
The dominant issues identified during this consultation process are:
• Internal control and accountability in the university library
• Accountability and processing in-efficiency with goods receipting and invoice
payment
• Duplicated accounts payable records
• Staff reimbursements inefficiencies
The University Library

The library represents about 25% of Accounts Payable transaction volume for non
order related invoices. In 2005, this amounted to $7.9M.
The Library streamlined its purchasing and payment processes around 2000 on the
basis of a compliant, robust and auditable link between purchases recorded in the
library system and payments in the financial system. Prima facie evidence suggests
that purchases are not authorised correctly and the invoice approval process does not
compensate for this control weakness. The overall process is labour intensive with
library staff maintaining entries in both the Millennium library system and Oracle
Payables. Due to the accounting practices involved with foreign currency
transactions, the systems inevitably do not reconcile. Duplicate paper based records
are also maintained.
The library managers are keen to adopt processes that support a higher degree of
risk based compliance.
Accountability and In-efficiency

Direct purchasing (with the exception of those made with the corporate card) and
deviation from agreed policy avoids basic controls, such as pre-approval of
expenditure. The payment process relies on the transporting of the original paper
based documentation across the university community, typically requiring handwritten
authorisation or additional transactions in the finance system to be completed before
the invoice can be entered, matched and paid. About ½ of the Oracle Payables
activity is not purchase order based.
“Rubber approval stamps” as a system to manage financial approval, has little
flexibility to cater with re-organisations and is insensitive to delegation changes. The
financial delegation structure is largely based on cost centres and projects which
consistently experience change. Approval stamps need to be replaced on a regular
basis at a significant cost. Also, there is evidence of inappropriate use of the approval
stamps with examples of “approvals” above the delegation value and/or outside the
related organisational responsibility.
Duplicated Records
The process, particularly in the Accounts Payable section, is paper based. Storage of
the paper-based records for a period of 5 years in a central area as per legislative
requirements continues to be a constraint both on space and access.
Multiple copies of invoices are also systematically stored and managed throughout
the university community, principally for local reference. A common complaint is that
invoices are often lost in the mail or misfiled. These local accounts payable record
systems typically maintain invoice copies for up to 2 years.
Staff reimbursements
Staff reimbursements is one of the few remaining staff related transactions that is not
captured using self-service functionality. Bank details, timesheets and leave requests
can be maintained by staff using self-service functions in the Alesco HR/Payroll
system. Plans are underway to also introduce overtime, car mileage claims and
allowance claims to be also entered using self-service Alesco functions.
Bank account details are not consistent between payroll and accounts payable as
staff are manually entered into Oracle Financials as a supplier when a staff
reimbursement claim is made. These claims typically have supporting, paper based
documentation that often needs to be vetted by both approvers and accounts payable
staff. Quality assurance and review focuses on the context of the claim and the
correct documentation being used. Easy access to these documents is required
should a tax audit be required for FBT.
Staff reimbursements can also be made via the petty cash system. This is time-
consuming for approvers, payees and petty cash holders alike. Nearly 8,000 petty
cash claims were made during 2005 for a total value of only $200,000.
Moving Forward
There is broad agreement within the working party how improvements can be applied
to each of these issues. These improvements are:
• use of the electronic financial delegation hierarchy for all Oracle Financials
documents requiring approval
• adoption of electronic record keeping
• capture of business documents, such as invoices, at the earliest point in the
process
• consistency between corporate information held in Alesco and Oracle
Financials
• extension of self service for staff transactions
FEASIBILITY STUDY REPORT FEASIBILITY STUDY REPORT
Where we want to be…..
Alesco (Payroll) Staff

Claims for Workflow Approvals
Callista
Payment Student Access to
Refunds Invoice Images
Staff Details Library

Including bank account Workflow Approvals
Faculty
Direct
Invoices PO Related
ISIS Invoices
Agent Accounts Payable
Commissions
Standard
Invoices
Faxed
Invoices
eMailed
EF
Invoices AP transac to GLy
T
PO Related
Invoices
Cheques
$
Standard
Invoices
Flexipurchase
costings to GL
Bank
Credit card Library

payments Invoices
QUT
Accounts Payable
Invoices Suppliers
6 EVALUATION CRITERIA
This has been captured below along with the assessment of options.
7 OPTIONS ANALYSED
7.1 Assessment of Options
The original project proposal presumed that the University of Melbourne solution
(which included an unsupported Oracle product) could be equally applied to the QUT
environment.
This presumption has been now been dismissed as further investigation of the
University of Melbourne solution has determined that it is not suitable for use at QUT:
• The scanning software is not integrated with Oracle Financials,
• A component of the solution to enable integration between the scanning
software and Oracle Financials is unsupported Oracle software, with no
assured compatibility with future versions of Oracle Financials, and
• Customisations to enable the workflow for invoice approvals is not compatible
with QUT business requirements
Alternatives have been researched and evaluated. Four products have been
assessed:
a) Ascent Capture (Dicom Australia Pty Ltd) – this is a component of the
University of Melbourne solution. This product is keenly priced, but requires
substantial customisation to inter-operate with Oracle Financials,
b) InvoiceIT (ReadSoft Australia Pty Ltd) – this product interoperates with Oracle
Financials “out-of-the-box” and is supported by a certified Oracle Partner,
c) BasWare (Canon Australia Pty Ltd) – this comprehensive system has no sites
in Australia and duplicates (rather than inter-operates with) Oracle Financials,
and
d) Optio (BITG) – this product has limited functionality and would require
substantial customisation to meet the university business requirements.
The Ascent Capture and InvoiceIT solutions were analysed further. Based on this
analysis the InvoiceIT product offered by ReadSoft is the preferred solution.
ReadSoft also provided a high level implementation plan which has been used to
determine a revised project proposal and associated costs.
The preferred solution comprises:
• Scanning of all paper based accounts payable invoices with gateways
provided for submission of electronic documents, such as via email and fax,
• Use of OCR technology to assist in data entry,
• Inter-operation and integration with Oracle Payables,
• Electronic approval similar to purchase requests,
• Continued devolved processes for the library and possibly some larger faculty
administration offices,
• A gateway for the ISIS Student Agent Management system to automate the
loading of agents commission invoices, and
• An Interface between Alesco and Oracle Financials to automate the creation
and synchronisation of staff as accounts payables vendors and associated
bank accounts for payments via EFT.
The preferred solution addresses the dominant issues arising from the working party
consultations. Also, the problems that were identified with the University of
Melbourne solution are overcome with the preferred solution.
The application of a self service function for staff reimbursements has an enormous
change management aspect. The scope of this project excludes this aspect of the
possible solutions. Options to provide this functionality include a custom built staff portal
through to implementing the Oracle Financials module iExpenses. Further
investigation and assessment of options is required to prepare a separate project
proposal for the staff reimbursement solution.
7.2 Engaging the University Community

Linkages with senior management and related forums across the university community have
been established early in the project. This is a key communication requirement as a high
level of change is expected with the implementation of the preferred solution.
An FRP divisional project governance committee has been established with over-arching
responsibility (in addition to the steering committee) for projects such as the POLA project.
The project was included in a FRP project priorities proposal to ITAC, which clearly defined
the relative importance of all projects being considered by the division.
Importantly, discussions with a sub-set of Faculty and Division managers have commenced.
There has been broad support for the project, with its accompanying business process
improvements and possible solutions.
Senior managers that have been consulted during these preliminary stages of the project
include:
Name Role Cost Centre

Peter Sullivan Executive Director Finance and resource Planning
Joe Dascoli Associate Director ITS
Chris Kane Business Services Manager Faculty of Business
Patricia Cussens Executive Officer Division of Administrative Services
Robyn Daniel Executive Officer Division of TILS
Janet Dyke Executive Officer QUT Carseldine
Cassandra Russell Faculty Administration Manager Creative Industries Faculty
Brigita Zebergs Faculty Administration Manager Faculty of Education
Wendy Jones ISIS Project Manager QUT International
Lisa Murray Institute Manager IHBI
Ann Huthwaite Library Resource Services Manager Library
Colleen Cleary Library Resource Services Deputy Library
Manager
Several areas of the university have offered assistance to support the project, mainly
by way of resources in-kind for the implementation phases. These in-kind resources
have been included in the cost benefit analysis in the following section.
7.3 Analysis of Benefits

The benefits of the preferred solution include:
• Common purchase to pay business processes across the university
community
• Elimination of paper based records for accounts payable
• Elimination of duplicate accounts payable systems/records across the
university community
• Improved data entry productivity of accounts payables invoices
• Timely entry and registration of accounts payable invoices

• Fewer duplicate (accidental) payments
• Fewer “chase ups” and supplier enquiries
• Substantial improvements in accountability and control with the use of
electronic approvals
• Reliable and consistent audit trails and unqualified response to audit requests
relating to financial approvals
• elimination of “rubber stamps”
• Improved supplier relations with timely payments
• Improved cash management with payment scheduling and discount
opportunities
• Improved service to staff with fewer reimbursement “payment problems”
The associated savings have been estimated to be about $300,000 per year. The
following table describes the benefits further and projected savings.
Benefits Cost Savings $
Elimination of storage of AP paper Internal costs relating to archiving are 3,500

documents both in accounts payable and in estimated as 1 month of HEWA4.
faculties and divisions. Alphabetised or Area equivalent to 1 work space freed up and
indexed filing of documents will no longer made available.
be required.
Recall Total Information Management
Off-site storage is no longer required. Services annual expenses are about $4500. 4,500
Secure and immediate access to invoices. Internal costs relating to finding filed invoices 9,000
Elimination of duplicate systems/records. are estimated at more than 2 months of
HEWA4
Original documents no longer need to be
handled, copied, enveloped, forwarded or Internal costs relating to maintaining duplicate
systems and records across the university are 36,000
delivered.
estimated at more than 10 months of HEWA4
Internal costs relating to handling original
documents around the university community
are estimated at more than 20 months of 72,000
HEWA4
Improved data entry productivity. Internal costs relating to improved data entry of
Invoices are tracked and available for invoices in accounts payable and the library 21,000
access and enquiry significantly earlier than are estimated at about ½ HEWA4.
at present. Internal costs relating to finding unregistered
invoices are estimated at more than 2 months
of HEWA4 9,000
Costs related to copying invoices for local
access in faculties and divisions are estimated
at $3,000 per year across the University. 3,000
Improved internal control with the use of About 25 rubber stamps are ordered/replaced $2,000
electronic approvals. Elimination of the each year.
“rubber stamp”.
Benefits Cost Savings $
Improved and timely processing of invoices. Opportunities for improved cash position is
Improved trading terms with suppliers. based on 0.5% improvement in trading terms
Payments can be scheduled to take or discounts with QUT principal suppliers
(excluding library and facilities) $80,000
discount opportunities.
Improved service to staff Internal costs relating to setup of staff details

as vendors in Oracle Financials are estimated 10,000
at about 3 months of HEWA4
Total Estimated Base Savings $250,000
Plus estimated on-costs $ 50,000
Total Estimated Savings $300,000
The project costs have been estimated at $393,000. These estimates are based on the
following assumptions:
• An initial implementation duration of about 16 weeks for the preferred solution in
accounts payable and a “pilot” faculty,
• A roll out duration of about 12 weeks of the preferred solution across the
university community,
• Implementation duration of about 2 weeks for a gateway for suppliers that provide
electronic documents, and
• The Cost components are as follows
Component Funding Source Amount
Project Management Project 55,000
Software Project 117,000
Hardware Project 27,000
Consulting Project 100,000
Project Resources Financial Services 61,000
CIS 30,000
Total Costs for 2006 $390,000
8 RECOMMENDATIONS
Finance and Resource Planning recommends a solution encompassing on-line electronic

approvals with intelligent scanning and digital storage of invoices seamlessly integrated to the
Oracle financial system.
This solution incorporates substantial integration with Oracle Financials and is a recent
showcased implementation at Vodafone (Australia/New Zealand)
The individual components making up the solution are as follows:
1. Configuration of Oracle workflow & approvals hierarchy.
2. InvoiceIT for integration of digitally captured data with the Oracle Payables module.
3. Document imaging technology hardware and software.
The proposed solution addresses the processing efficiency issues by drastically reducing
processing nodes along the critical path, enabling on-line querying and redirection of
electronic image “paperwork”, whilst at the same time eliminating the internal control
deficiencies.
It is recommended that the steering committee:
a) Accept this report as the basis for the Payables Online Approval Project
b) Approve the revised AMP (IT) Project proposal, based on this report, for submission to the
DVC (TILS) in accordance with the Investigatory Study approval of 2005-54
Project Plan
Name of project
Prepared by “name of project manager”

Name of area
Version number:
Date of current plan:
PMF V4.4
CRICOS Institution Code 00213J
PROJECT PLAN
NAME OF PROJECT
1 PROJECT PLAN DISTRIBUTION LIST

The recipients of the project plan
Name Position Interest in Project
2 VERSION CONTROL
Record changes to the project plan.
Version
Number
PROJECT PLAN
NAME OF PROJECT
3 MANAGEMENT SUMMARY
The Management Summary should comprise a summing up of the information on the
project that is most important to management: objectives, cost, time frame, key benefits
and an outline of the milestones.
The summary should usually be 1page or less in length, 2 pages at most, depending on
the size of the project.
Guidance boxes like this are displayed in MS Word Print View (not in Normal View). They should be deleted
when you have finished with the contents: position the cursor on the border, left click when a cross appears
and press delete.
3.1 Major Changes From Project Proposal
If significant changes are required from the Project Proposal, use the table below to
indicate changes needed across the specific key project areas and the adjustments within
each area to accommodate the requested changes. If no significant changes have taken
place, delete 3.1 and 3.2.
Category Reason for Variance from Proposed Changes

Project Proposal
(From Project Proposal)
Scope
Time
Cost
Quality
Risk
Management
Communications
3.2 Detailed Description and Justification for Project

Changes
Where required, a detailed description and justification for the project changes from which
the Steering Committee and the governing authority (the DVC (TILS) for AMP (IT)
projects) can make the decision whether or not to approve the changes.
Type in your project information below, then delete this guidance box: position the cursor on the border, left click
when a cross appears and press delete.
PROJECT PLAN
NAME OF PROJECT
Table Of Contents
Regenerate the Table of Contents as required.
1 PROJECT PLAN DISTRIBUTION LIST ..................................................................................... II
2 VERSION CONTROL............................................................................................................. II
3 M ANAGEMENT SUMMARY ................................................................................................... III
3.1 Major Changes From Project Proposal ................................................................. iii
3.2 Detailed Description and Justification for Project Changes .............................. iii
4 PROJECT INFORMATION ..................................................................................................... 1
5 INTRODUCTION AND BACKGROUND..................................................................................... 1
6 OBJECTIVES ...................................................................................................................... 1
7 SCOPE, CONSTRAINTS, ASSUMPTIONS ............................................................................... 2
8 INTERDEPENDENCIES WITH BUSINESS ACTIVITIES, SYSTEMS AND OTHER PROJECTS ............ 2
9 BUSINESS CASE AND BENEFITS REALISATION .................................................................... 3
10 WORK BREAKDOWN STRUCTURE (WBS) ........................................................................... 4
11 RISK MANAGEMENT ........................................................................................................... 4
12 COSTS AND RESOURCES ................................................................................................... 5
12.1 Costs and resources during the life of the project ............................................ 5
12.2 Basis for estimated project costs ........................................................................ 6
12.3 Ongoing costs after project completes ............................................................... 7
12.4 Basis for estimated ongoing costs ...................................................................... 7
13 TIMELINES ......................................................................................................................... 7
14 QUALITY ........................................................................................................................... 8
15 PROJECT M ANAGEMENT STRUCTURE ................................................................................. 8
16 COMMUNICATION ............................................................................................................... 9
PROJECT PLAN
NAME OF PROJECT
The Project Plan contains details of the strategies and information necessary to execute a
project. Prepare the Project Plan, then check against the Project Plan Compliance
Assessment document available on the PMF templates web page.The Project Plan must
be endorsed by the steering committee, followed by approval by the governing authority.
Then, funds previously reserved with the approved Project Proposal will be released. For
AMP (IT) projects a Project Plan approved by the steering committee should be sent to
the Project Portfolio Office at project_portfolio@qut.edu.au for PMF compliance and for
DVC (TILS) consideration and approval.
Separate Risk Management, Quality and Communication Plans may be prepared, as
appropriate.
Changes in the project during the executing phase are documented with Project Change
Requests and handled as described in Part B of the PMF Guide in Project Monitoring.
See the example of a completed Project Plan.
after you have finished with the contents: position the cursor on the border, left click when a cross appears and
press delete.

Date: Date of current plan
Project Contacts:
Primary
Other
Other
Project Approval: Business Owner/Relevant Service Manager Endorsement,

Steering Committee Approval and Authority for project funding (for example, Information
Technology Governance Committee through the AMP (IT) budget)
5 INTRODUCTION AND BACKGROUND

A commentary on the circumstances leading up to the need for and decision to fund the
project.
6 OBJECTIVES
PMFPROJECTPLANV4.3
PROJECT PLAN
NAME OF PROJECT
The overall aims of the project. Projects should be broken out into “chunks” or stages.
Multi-year projects should show annual objectives. Funds reserved earlier, when the
Project Proposal was approved, will be released accordingly.
7 SCOPE, CONSTRAINTS, ASSUMPTIONS

section should outline activities outside the project scope and any assumptions that the
project is based on. Whoever is preparing the project proposal should make considerable
efforts to establish the scope with the stakeholders. Scope verification and clear user
requirements are important aspects to gain agreement with the stakeholders. The better the
outcomes are defined, the less probability of dramatic scope changes or scope creep.
Projects should be broken out into “chunks” or stages. Multi-year projects should show
annual objectives.
Scope
Within Scope
Outside Scope
Constraints
Assumptions
8 INTERDEPENDENCIES WITH BUSINESS ACTIVITIES,

SYSTEMS AND OTHER PROJECTS
PMFPROJECTPLANV4.3
PROJECT PLAN
NAME OF PROJECT
A table of interdependencies and possible impacts to draw attention to QUT integration

issues in the complex University environment.
Interdependent Activity Possible Impact
9 BUSINESS CASE AND BENEFITS REALISATION

The plan should present the approving authority with firm business reasons for carrying out
the project. The business case shows the benefits and added value of the project for the
business area and to QUT. Clear strategic alignment and financial benefits are increasingly
required. List only those benefits contained within the scope of the project.
Guidelines for benefits:
1) A method for measuring the improvement or value should accompany each benefit. The
monitoring and measuring will take place throughout the life of the system or service, long
after the project and its Post Implementation Review are completed.
3) During the project the project team should establish baselines for measurements that
continue into the operational phase for comparison.
2) Details on the method of measurement after the project ends should be handed over to
the service or product owner at the time of transition from project status to operational.
4) Quick wins during the project and immediately after should also be identified if possible.
Strategic Alignment: Use the QUT Blueprint and top-level plans located through the FRP
web page to demonstrate the value of implementing the project, for example, improves
research outcomes by ……..
Financial Benefits: Include the measure of determining savings or increase in revenue.
How to use standard techniques like Return On Investment and Net Present Value are
easily available on the Internet and in textbooks, if required.
Benefits How to Measure

Strategic alignment with QUT Blueprint & University Plans
Financial: quantitative, for example, saves money, increases revenue
Other, for example, legislative compliance, infrastructure refresh, local benefit
PMFPROJECTPLANV4.3
PROJECT PLAN
NAME OF PROJECT
10 WORK BREAKDOWN STRUCTURE (WBS)
The WBS is a separate, foundation project document and may be a diagrammatic

representation of the project activities. MS Project may also be used to prepare a WBS.
Refer to the section on WBS in the PMF Guide.
Indicate below where the WBS for this project can be found.
11 RISK MANAGEMENT
A separate risk management plan is required for all but very small or limited scope projects
to identify project risks, as stipulated in the Manual of Policy and Procedures (MOPP) in
Policy A/2.5. Small or limited scope projects may use the RMP template or embed the
limited risk table found in the Project Proposal template here, as judged by the project
manager and governing authorities. Refer to the section on risk management in the PMF
Guide and the QUT Risk Management Framework for more information. Then, use the Risk
Management Plan template with appropriate customisation.
Indicate below where the Risk Management Plan for this project can be found if separate.
PMFPROJECTPLANV4.3
PROJECT PLAN
NAME OF PROJECT
12 COSTS AND RESOURCES

The proposal should provide an overview of the project costs and resources in the table below,
which aligns with Oracle Financials reporting.
Overview: Projects should be broken out into logical “chunks” or stages. Funding may be reserved
for multiple stages or for a single stage with new submissions for later stages as the project
progresses. If alternative approaches to the project are possible, break out into Option 1 and Option
2 (or more) with a recommendation on the choice to make. (Delete option table if unused.)
Salaries: These should be calculated using the HR Salary Scales - Professional Staff table and the
HR Oncosts. Show end to end costs, including those that will be absorbed, for example, salaries
from the Operating Grant. Modify the Costing Schedule as required, for example, a staff
development allowance on a longer contract salary. Salaries for extra Helpdesk staff, extra
communications and other technical staff may have to be factored in as well, especially considering
the risk that the implementation may go adversely. For major projects include a salary cost
component for the Post Implementation Review.
Totalling costs: The Grand Total comprises end to end costs, as indicated in the line items of the
table. The amount from Operating Grant will be absorbed, but should be shown as indicated.
Specify any other funding known in Total from other Funding, for example, a co-contribution from a
faculty. Show the amount being requested in the proposal in Total Project Funds Requested. (All
three should add up to the Grand Total). If project funding will be required across two calendar
years, specify the years and amounts.
Capitalisation of Developing Software: Resulting assignment of capitalisation percentage is not
always straightforward. The local financial officer or FRP may be consulted, as required.
Other: may include extras such as costs for BPR, as required.
Ongoing costs: This section with table to provide information on funding required after the project
makes the transition to operational must be completed. The table should include figures for the
ongoing costs of the continued maintenance and support of the products of the project when the
project has ended. The funding source that will provide the ongoing resources must sign off on
these costs or the project may not proceed – a project kill or halt point.
Use MS Excel if calculations warrant the use of a spreadsheet or MS Project.
12.1 Costs and resources during the life of the project

of Time Source
(eg, Op
(as
Grant or
applicable)
AMP (IT))
Recommended Option 1
Salaries
PMFPROJECTPLANV4.3
PROJECT PLAN
NAME OF PROJECT

of Time Source
(eg, Op
(as
Grant or
applicable)
AMP (IT))

Capitalised Expenditure, including Hardware >$5K, Software >$100K
then, 2008: $40K, 2009: $60K)
200x: amount
Year 2 –
200x: amount
12.2 Basis for estimated project costs

PMFPROJECTPLANV4.3
PROJECT PLAN
NAME OF PROJECT
12.3 Ongoing costs after project completes
Ongoing Detail Funding Annual Name of

Maintenance Source after Amount Delegate of
Project Ends Funding Source
Who Agreed
Salaries
Equipment
Software
Other
Total
12.4 Basis for estimated ongoing costs

13 TIMELINES
The project plan should detail timing with milestones for implementation of the project’s
activities. A timeline table is provided with the PMF, but for most projects it is advisable to use a
product like MS Project, at least at a high level. No matter what the mechanism used, the
timelines should reflect the work breakdown structure with key activities and deliverables
marked.
The project manager should take much care to ensure a realistic time frame, arriving at the
schedule after consultation with others.
Activity or Deliverable Timeframe Kill/Milestone

Date
PMFPROJECTPLANV4.3
PROJECT PLAN
NAME OF PROJECT
Activity or Deliverable Timeframe Kill/Milestone

Date
14 QUALITY
This section deals with strategies for ensuring high quality for the project
As a minimum, the Project Plan should include the quality measures and acceptance criteria to
be used or a separate Quality Plan may be produced, as described in the PMF Guide using
the Quality Plan form.
If a separate Quality Plan is produced, indicate below where the plan can be found
15 PROJECT MANAGEMENT STRUCTURE
The Project Plan should list the names of the sponsor, steering committee members and project
manager. These key project members must understand their duties and responsibilities for a
project to be successful. The standard duties and responsibilities of the sponsor, steering
committee members and project manager are detailed in Appendix B of the PMF Guide. The
project plan lists customised changes or extra duties from the standard roles and
responsibilities.
General guidelines are that the steering committee should work at a strategic level, while the
project manager deals with operational matters and reports to the steering committee on project
progress, including strategic issues. An operational reference group may be included in the
project structure.
Project Role Name QUT Position Interest in Project
Steering Committee
Sponsor
Client Leader
Project Manager
Expert/Specialist
Steering Committee
member (general)
DVC (TILS) or
nominee
PMFPROJECTPLANV4.3
PROJECT PLAN
NAME OF PROJECT
Internal Audit
representative
Reference Group
Reference Group
member
Reference Group
member
16 COMMUNICATION
This section deals with strategies for communicating to and training stakeholders. The
stakeholders identified in the Project Proposal and any new ones subsequently determined
Use the table below or produce a separate Communication Plan as described in the PMF
Guide using the Communication Plan template, depending on the size and complexity of the
project and specific communication needs for the project. The Communication Plan lists the
activities to inform and train stakeholders about the project and the project outcomes.
Marketing and/or Communications Officers in faculties and divisions should be consulted if
available. Within the ITS Department Client Relations Managers must be consulted and for
all AMP (IT) projects it is recommended that the ITS Client Relations Managers be
consulted. The ITS Learning and Development Unit has a cost-recovered service and may
also be consulted.
All projects involve change and the Communication Plan generally addresses change
management. However if workflow change is involved, contact Human Resources to
discuss QUT’s Change Management policy.
If a separate Communication Plan is produced, indicate below where the plan can be found.
Stakeholder Communication Strategy Training Strategy

Group
PMFPROJECTPLANV4.3
RISK MANAGEMENT PLAN
NAME OF PROJECT

A separate Risk Management Plan (RMP) is required for all but very small or limited scope projects
to identify project risks. The RMP shows the elements of risk to a project and is a dynamic
document. The plan should be reviewed and revised throughout the life of project. High risks,
otherwise notable risks and changes in risks should be included by copying them into the project
Status Reports.
For AMP (IT) projects a Risk Management Plan, in conjunction with the Project Plan, should be
approved by the steering committee, then sent to the Project Portfolio Office at
project_portfolio@qut.edu.au for PMF compliance and for DVC (TILS) consideration and approval.
See the example of a completed Risk Management Plan.
Guidance boxes like this are displayed in MS Word Print View (not in Normal View). They should be deleted when you have
Project Name: The project name
Date: Today’s date
Project Ownership: Area responsible for the project
Prepared by: Name and project position
Project Contacts:
Primary
Other
Other
2 VERSION CONTROL/ RISK CHANGE LOG
This table should be maintained as a complete log of changes in risk. The changes should be
reflected in the main risk table as they occur. This log is a cumulative record of the changes in existing
risks and new risks for the life of the project.
Delete this box when you have finished with the contents: position the cursor on the border, left click when a cross appears and
press delete.
Add new rows to the table as required.

Version
Date Description, Reasons, Comments Approvals
Number
PMFRISKMANAGEMENTPLANV4.3
RISK_MANAGE_PLAN_TEMPLATE4.3.DOC PAGE 1
NAME OF PROJECT
3 RISK ASSESSMENT AND MANAGEMENT TABLE
Risk management is already a significant consideration in project management at QUT and is gaining in importance. Refer to the QUT Risk
Management Framework, as needed. The framework supplies valuable information on dealing with risks and producing a risk management plan. This
table is IT-oriented, but can be adapted to fit the circumstances of individual projects, including non-IT projects. Review sections 4.1 and 4.2 of the
QUT Risk Management Framework before continuing.
IMPORTANT: Retain the 6 category headings in the Risk Management Plan template below, but change, add and delete rows within those categories
to customise the template to fit the specific project being addressed. The project manager should apply thought to the process, gaining input from
stakeholders and other sources, for example, from another experienced project manager. Use only the rows that apply to your project and delete rows
that do not apply, that is, with zero risk for your project. Add new rows with risks not supplied in the template as specifically required.
The rows for high risks, otherwise notable risks and new or changed risks will be copied into the corresponding Review of Risks table in the Project
Status Report.
# A B C D E F G H
Risk Description of Adequacy Likelihood of Consequences of Risk Risk Residual Owner of
Categories Risk and Adverse Adverse Event Rating Treatment Risk Rating Risk
Effectiveness Event Occurring
of Existing Occurring
Controls • High • Avoid the risk • High
• Major • Medium • Share the risk • Medium
• Probable • Moderate
• Good • Low • Accept and • Low
• Possible • Minor reduce the risk
• Satisfactory • Improbable • Retain and
• Poor monitor the risk
1. Project Management Risks

Inadequate
project
definition
NAME OF PROJECT
# A B C D E F G H
Availability of
expert
staff/resources
Unrealistic time
frames
Project plan
deficient
Scope creep
Lack of
communication
Others
2. Security Risks
Security
requirements
met
Accuracy and
integrity of data
and information
NAME OF PROJECT
# A B C D E F G H
Breach of
privacy
Others
3. Resource Risks
Staff turnover
Unclear roles
and
responsibilities
Level of project
team expertise
Insufficient
funding
Others
4. Client Risks
Inadequate
business
requirements
Dissatisfaction
NAME OF PROJECT
# A B C D E F G H
with product in
acceptance
tests
Training of
clients/users
Resistance to
change
Others
5. Technical Risks
Procurement
issues,
including
tendering
Hardware
inadequate
Software
unavailable
Technical
problems
NAME OF PROJECT
# A B C D E F G H
Others
6.
Interdependenc
ies with other
systems, etc
Level of
ongoing
support
QUALITY PLAN
NAME OF PROJECT
Quality Plan
The Quality Plan contains the quality standards, quality assurance processes and quality control
activities for a project.
See the example of a completed Quality Plan.
Date: Date of current Quality Plan
Contact Names:
Primary
Other
Other
2 VERSION CONTROL
Add new rows to the table as necessary.
Version
Number
3 QUALITY PLANNING AND STANDARDS

Identification of the quality standards that will be used for the deliverables and how to satisfy
them, for example, the best practices identified in the PMF and the Project Management Body of
Knowledge – PMBOK Guide 2000 Edition.
Type in your project information below, then, delete this guidance box: position the cursor on the border, left click when
PMFQUALITYPLANV4.3
QUALITY PLAN
NAME OF PROJECT
4 QUALITY ASSURANCE
The processes chosen to evaluate overall project performance on a regular basis to show that
the project will satisfy the quality standards. Quality assurance processes can show whether
reviews took place, whether the “product” was tested and whether the client was satisfied.
Type in your project information below, then, delete this guidance box: position the cursor on the border, left click when
.
5 QUALITY CONTROL
A table to show the monitoring of specific project results to determine if they meet the quality
standards and identifying ways to eliminate causes of unsatisfactory performance. Project
results include both “product” results, such as the deliverables, and project management results,
such as cost and schedule performance
Activity Measure Possible Rectification
6 QUALITY PLAN RECORD
A record of the issues and outcomes resulting from quality plan activities.
Date Activity Issue Outcome
PMFQUALITYPLANV4.3
COMMUNICATION PLAN
NAME OF PROJECT
Communication Plan
The Communication Plan lists the activities to inform and train stakeholders about the project and the
project outcomes. Marketing and/or Communications Officers in faculties and divisions should be
consulted if available. Within the ITS Department Client Relations Managers must be consulted and
for all AMP (IT) projects it is recommended that the ITS Client Relations Managers be consulted. The
ITS Learning and Development Unit has a cost-recovered service and may also be consulted.
.All projects involve change and this plan generally addresses change management. However if
workflow change is involved, contact Human Resources to discuss QUT’s Change Management
policy.
See the example of a completed Communication Plan.
Date: Date of current Communication Plan
Contact Names:

Primary
Other
Other
2 VERSION CONTROL
Add new rows to the table as necessary.
Version
Number
PMFCommunicationPlanV4.3
COMMUNICATION PLAN
NAME OF PROJECT
3 MARKETING AND COMMUNICATION STRATEGIES

These strategies may be for “selling” the project or for providing project details to selected stakeholders, for example, to steering committee
members. Refer to Appendix C in the PMF Guide for additional information.
Action Timing Frequency Costs Actioned By

(Who are you (What is the message? What is the (What time in the project?) (How often?) (Who is responsible for this
informing? Who are method? What do you need to do? action?)
you selling the What steps are involved?)
service to?
Stakeholder1 or
Group1
Stakeholder2 or
Group2
Stakeholder3 or
Group3
COMMUNICATION PLAN
NAME OF PROJECT
4 TRAINING STRATEGIES
The strategies should include ongoing training requirements after the project ends, as appropriate. Refer to Appendix C in the PMF
Guide for additional information.
Audience Type of Training Action Timing and Costs Actioned By

(Who are you (Will you be using (What do you need to do,
Frequency (Who is responsible for
training?) class room, online, what steps are involved?) (What time? How often?) this action? Who will be
streaming media, doing the training?)
seminar, etc)
Stakeholder1 or
Group1
Stakeholder2 or
Group2
Stakeholder3 or
Group3
PROJECT STATUS REPORT
NAME OF PROJECT

The Project Status Report is a tool used throughout the life of a project to supply
information on how the project is proceeding. The report is a vital communication tool
aimed at the sponsor/steering committee. The report will also be distributed to other
appropriate stakeholders. A Work Breakdown Structure showing progress may be
distributed at the same time. For major projects, the complete Risk Management Plan
may be included. The report includes a Review of Risks at the end, required for all
projects, showing all high and changed or otherwise notable risks.
After the date, add the sequential report number, eg, 1 for the first project Status Report
All AMP (IT) project Status Reports should include the Project Portfolio Office in the
distribution list, at project_portfolio@qut.edu.au.
See the example of a completed Project Status Report:
http://www.its.qut.edu.au/pp/framework/pmfexamples.jsp
when you have finished with the contents: position the cursor on the border, left click when a cross appears and
Project/Program Number (if applicable):
Date: Date of current Project Status Report Report Number: (1, 2, 3, etc)
Distribution List: List of those receiving the report
Project Objective: Copy project objective from the Project Plan
2 RECENT PROJECT PROGRESS, ACTIVITIES AND HIGHLIGHTS
Details of project progress including highlights, achievements and other notable items.
when a cross appears and press delete
PMFSTATUSREPORTV4.3
NAME OF PROJECT
3 PROJECT PERFORMANCE
Indicate the performance of each key area of the project, and of the project overall, by assigning
the appropriate colour for each reporting period. Continue to add a row for each new report so
that ALL reporting periods are shown. Fill in the categories as follows, using the row shown as an
example:
Red: Serious significant issues
Yellow: Noteworthy minor issues
Green: No issues
Important note re Overall Project:
• One or more red entries in the row means a red entry under Overall Project
• Two or more yellow entries in the row mean a yellow entry under Overall Project.
• To select colour:
o Select the cell you want to colour then >> Table >> Table Properties >> Table Tab
>> Borders and Shading button >> Shading Tab >> Select relevant fill colour (Yellow,
Bright Green or Red) >> Select Apply to: Cell >> OK
o Add the appropriate letter to the cell for people who print in black and white and
those who are visually impaired.
See end of this template for full explanation of the criteria.
Date Timeline Budget Commun Scope Resources Risks Overall

ication Project
dd/mm/yy g y g r r y r
3.1 Issues
This section is a summary of issues or potential issues that have arisen for the project.
Yellow and red entries in the table above should be included. Potential issues (or changes)
for each category that may affect the project no matter what its current colour status can be
listed as well. There should be an explanation of each issue and how it is being or will be
addressed.
PMFSTATUSREPORTV4.3
NAME OF PROJECT
Performance Areas Issues / Concerns

Timeline
Budget
Communication
Scope
Resources
Risks
Overall Project
Other
3.2 Timeline
A record of the progress made against milestones and deliverables to date or since last
report.
Actual
Due Completed Reason for Actions and
Milestones Deliverables
Date Slippage Resolutions
Date
3.3 Budget Status
An accounting of the current state of the actual expenditure to date compared with the
planned budget. A notable variance should be addressed. Budget categories include
salaries, equipment and software.
Amount of
Budget in Amount On
Category Project Spent to Track Explanation if Necessary
Plan by Date Y/N?
Category
PMFSTATUSREPORTV4.3
NAME OF PROJECT
Amount of
Budget in Amount On
Category Project Spent to Track Explanation if Necessary
Plan by Date Y/N?
Category
4 PLANNED ACTIVITIES/DELIVERABLES FOR NEXT TIME PERIOD
A list of forthcoming, notable activities that can be reviewed in the next Status Report.
Include comments where appropriate.
Due
Activity Deliverables Comments
Date
(See Review of Risks on next page.)
PMFSTATUSREPORTV4.3
NAME OF PROJECT
5 REVIEW OF RISKS
This table is the same format as that in the Risk Management Plan. The table should include all high risks, otherwise notable risks and
new or changed risks for review, copied from the Risk Management Plan. A risk that decreases to Low or zero should be removed in
the next Status Report.
The Risk Management Plan itself should be up to date with current status of all risks. The Version Control table in the Risk
Management Plan is the Risk Change Log and should be maintained showing all the cumulative changes and new risks as the Risk
Management Plan is modified.
# Risk Description of Adequacy and Likelihood Consequences Risk Rating Risk Residual Owner of
Categories Risk Effectiveness of Adverse of Adverse Treatment Risk Rating Risk
of Existing Event Event
Controls Occurring Occurring
PMFSTATUSREPORTV4.3
NAME OF PROJECT
DELETE THIS SECTION AS REQUIRED. This section is provided as a convenience to project

managers.
Colour Status Criteria
For Project Status Report and Project Registry
Three status colours are represented in the Project Status Reports and in the Project Registry,
which is produced quarterly. The table below is provided as a convenience to show the reporting
action for each colour. Project managers should apply the colours as appropriate to each of the
project management knowledge areas and an overall status for the project.
Note that a certain amount of subjectivity may be involved.
Colour Description Reporting Action
Red There are one or more significant issues Two required actions:
which threaten the success of the
project to the extent of: • The issues will be explained in the Project
Status Report in Section 3 below the
• 30% or greater cost overrun Project Performance table.
• 30% or greater timeline overrun • The Chair of the project steering
• Likely failure to deliver a significant committee will submit a statement
component of anticipated project explaining how the project is addressing
outcomes these issues. The response will be sent to
• Significant external factors that the Project Portfolio Office for progression
emerge that require reassessment to the Systems and Projects Advisory
e.g. vendor takeover, merger or Group, IT Governance Committee and/or
bankruptcy, which raises questions the DVC (TILS) as appropriate.
as to their product’s viability.
Yellow There are current issues that could The issues will be briefly explained in the
threaten the success of the project. Project Status Report in Section 3 below the
However, the project manager and/or Project Performance table.
steering committee do not perceive it as
having reached the “red” threshold. No
governance action is sought other than
being brought to the attention of the
steering committee in the Status Report.
Green There are no significant issues. The None.
project is progressing as planned.
Project managers should use the above criteria to insert colours into Section 3, the Project
Performance table in the Project Status Report, as in the example below:
Date Timeline Budget Commun Scope Resources Risks Overall

ication Project
dd/mm/yy G Y G R R Y R
Important note:
• One or more red entries in the row means a red entry under Overall Project
• Two or more yellow entries in the row mean a yellow entry under Overall Project.
Project managers should select the colours: and add rows to report over the life of the project:
PMFSTATUSREPORTV4.3
NAME OF PROJECT
• Report the performance of the project for each reporting period throughout the course
of the project.
• Add rows to Project Performance chart with oldest row at the top.
• Continue to add rows as required so that all reporting periods are shown.
• To select colour:
o Select the cell you want to colour then >> Table >> Table Properties >> Table
Tab >> Borders and Shading button >> Shading Tab >> Select relevant fill
colour (Yellow, Bright Green or Red) >> Select Apply to: Cell >> OK
o Add the appropriate letter to the cell for people who print in black and white and
those who are visually impaired.
PMFSTATUSREPORTV4.3
PROJECT CHANGE REQUEST
NAME OF PROJECT
Project Change Request

The Project Change Request Form is used to request approval of notable, strategic changes
in a project from its Steering Committee. Projects are dynamic and changes are inevitable.
Good project management ensures that the changes are recognised, documented and dealt
with at the right level. Every change should have a separate request form.
The steering committee has authority to approve most changes. For AMP (IT) projects.
Requests for significant changes (a call of judgement) and all requests for additional funding
should first be approved by the steering committee, then go to the DVC (TILS) for approval.
Requests for major additional funding may involve ITGC.
Project Change Request Forms approved by the steering committee should be copied to the
Project Portfolio Office. The Project Portfolio Office will advise the DVC (TILS) and ITGC of
changes approved by steering committees, as appropriate.
See the example of a completed Project Change Request.
Guidance boxes like this are displayed in MS Word Print View (not in Normal View). They should be deleted when
you have finished with the contents: position the cursor on the border, left click when a cross appears and press
delete.
Project Name: Name of project
Date: Of the change request
Distribution List: List of those receiving the change request
2 DESCRIPTION OF REQUEST WITH REASON(S)
A full description of the change request and the basis for the change. Include expected
outcomes and benefits.
3 CHANGES IN KEY PROJECT AREAS

A table showing the changes needed across the specific key project areas and the
adjustments within each area to accommodate the requested change.
PMFPROJectChangeRequestV4.3
PROJECT CHANGE REQUEST
NAME OF PROJECT
Category Reason for Variance from Proposed Change

Project Plan
(Against Project Plan)
Scope
Time
Cost
Quality
Risk Management
Communications
4 PROJECT PLANS TO BE REVIEWED AND SUITABLY MODIFIED?
Indicate Y/N. If Y, give details, including time frame, etc. If N, give reason.
5 DISPOSITION OF CHANGE REQUEST
This section to be completed on behalf of the Steering Committee. Upon approval by the
steering committee, a Project Change Request for significant changes and all requests for
additional funding should be forwarded to Project Portfolio Office for the approval of the DVC
(TILS) (and to ITGC if required).
Indicate the decision on the request for change and resulting actions. This information is for
tracking purposes.
Date of Approved Reason for Approval or Resulting Action

Decision Rejection
Y/N?
PMFPROJectChangeRequestV4.3
ACTIVITY COMPLETION REPORT
NAME OF PROJECT
Activity Completion Report

The Project Activity Completion Report advises that the project has ended, either at the
end of the closing phase or for another reason in an earlier phase. For AMP (IT)
projects a Post Implementation Report will also be required for major projects and for
other projects at the discretion of the DVC (TILS). Usually, the Project Manager will
complete the Activity Completion Form.
See the example of a completed Project Activity Completion Report.
The Project Activity Completion Report should be approved by the steering committee,
then sent to the Project Portfolio Office at project_portfolio@qut.edu.au.
when you have finished with the contents: position the cursor on the border, left click when a cross appears
and press delete.
Date: Today’s date
Project Ownership: Areas responsible for project
Contact Names:

Primary
Other
Other
2 REASON FOR CLOSURE
Includes successful completion of project or termination before completion.

3 CLOSING ACTIVITIES
PMFActivityCompletionFormV4.3
NAME OF PROJECT
Tasks and activities undertaken to bring the project to an orderly end, including handover
upon completion, as appropriate. An example is the production of documentation for the
ongoing support group.
4 OVERVIEW OF CLOSING PROJECT

A table indicating the status of key factors when the project closed. Indicate how the
project had met these factors upon closing.
Add more rows as required for additional objectives, benefits and milestones.
Key Factor Description Achieved Upon Closing

Objective 1
Objective 2
Scope
Benefit 1
Benefit 2
Costs and
Resources
Schedule overall
Milestone 1
Milestone 2
5 LESSONS LEARNED
List the lessons learned from your project. The idea is to be positive. How can these
lessons be applied to other projects?
No. Lesson Where/How to be used
6 RECOMMENDATIONS ARISING FROM THE PROJECT
List the recommendations derived from your project. The idea is to be positive. What
could have been improved? How will these lessons/recommendations be applied to other
projects?
NAME OF PROJECT
No. Recommendation Where/How to be used
7 ADDITIONAL INFORMATION
Any information not already shown in the report, for example, a note that the project may
have a subsequent phase as a result of additional client expectations.
PIR REPORT
NAME OF PROJECT
Post Implementation Review Report

The Post Implementation Review (PIR) Report is used to supply information about the outcomes
and success of a project. The PIR lists the expected outcomes as specified in the Project Plan,
reports on variances from that plan and then asks for recommendations and how they will be used,
as well as lessons learned.
All projects require a Project Activity Completion Report to be completed.
Additionally, for AMP (IT) projects a PIR is required for all major projects. A PIR for other projects
may also be requested by the DVC (TILS). The PIR should be approved by the steering committee
and sent to the Project Portfolio Office at project_portfolio@qut.edu.au.
See the example of a completed Post Implementation Report.
Project Name: Name of project
Date: Of submission of the PIR
2 SUMMARY OF PROJECT
A brief history of the project to give context.

3 MEMBERS OF PIR TEAM
List those involved in the PIR, including identification of the Chair or organiser.
• Recommended composition of PIR team for a major project (>$250,000):
o Chair (Not usually the project manager)
o 1 steering committee member
o 1 independent member from the client area
o 1 project team member
• Composition of a typical PIR team for minor project:
o Project manager as organiser and leader
o 1 independent member
PMF_PIRV4.3
PIR REPORT
NAME OF PROJECT
Name QUT Position Role in Project Phone
PMF_PIRV4.3
PIR REPORT
NAME OF PROJECT
4 OUTCOMES IN KEY PROJECT AREAS
A table showing information about key project areas. Include a reference for evidence where appropriate.
Key Project Area Planned Expectation Actual Outcome Reference for Reason for Variance from Project
Evidence Plan
(as in Project Plan)
Scope
Time
Cost
Quality
Risk Management
Communication
PMF_PIRV4.3
PIR REPORT
NAME OF PROJECT
5 OBJECTIVE OUTCOMES
A table showing information about project objectives.

Objective Objective Met? Outcome Reference for Reason for Variance from Project
Evidence Plan
(as in Project Plan) (Score 1-5
1=Not at all
5= Completely)
6 BENEFITS REALISATION
A table showing information about benefits realisation. Include a reference for evidence where appropriate.
Benefits Realised Benefit realised? Outcome Reference for Reason for Variance from Project
Evidence Plan
1=Not at all
5= Completely)
PMF_PIRV4.3
PIR REPORT
NAME OF PROJECT
Benefits Realised Benefit realised? Outcome Reference for Reason for Variance from Project
Evidence Plan
1=Not at all
5= Completely)
7 BUSINESS REQUIREMENTS
A table showing information about business requirements where applicable, as in the project specifications. Include a reference for evidence where
appropriate.
Top Level Business Requirement met? Outcome Reference for Reason for Variance from
Requirements Evidence Specifications
(Score 1-5
(as in Specifications) 1=Not at all
5= Completely)
PMF_PIRV4.3
PIR REPORT
NAME OF PROJECT
8 LESSONS LEARNED
List the lessons learned from your project. The idea is to be positive. How can these
lessons be applied to other projects?
No. Lesson Where/How to be used
9 RECOMMENDATIONS ARISING FROM THE PROJECT
List the recommendations derived from your project. The idea is to be positive. What
could have been improved? How will these lessons/recommendations be applied to other
projects?
No. Recommendation Where/How to be used
10 MECHANISMS USED TO GATHER INFORMATION FOR PIR

Provide information on how information for PIR was gathered, eg, focus group, individual
interviews, log reports, status reports. List names and other details for focus groups and
interviews. Designated stakeholders, business clients, steering committee members,
impacted areas, etc, should be consulted as necessary for the project.
Type of Information All Names Position at QUT Interest or Role in

Gathering (eg, Project
focus group,
interview)
PMF_PIRV4.3
PIR REPORT
NAME OF PROJECT
Type of Information All Names Position at QUT Interest or Role in

Gathering (eg, Project
focus group,
interview)
11 APPENDICES AND SUPPORTING DOCUMENTATION (OPTIONAL)
List attached appendices and supporting documentation. This information is optional,

depending on project size and outcomes. For example, appropriate records from a project
that encountered significant problems could well be useful. Similarly, information that
demonstrates a lesson to be learned from a project could be included. Logs of changes
and incidents should be included here. Original documentation may also be included, for
example, a report on lower level specification success.
• Appendix A - document 1
• Appendix B - document 2
PMF_PIRV4.3
AMP IT Support & MaintenanceActivity Request
SAMA OVERVIEW
DATE: dd/mm/yy
SAMA NAME:
KEY CONTACT:
PHONE NUMBER:
REQUEST TYPE: New SAMA / EBA increase / Other increase (delete inapplicable choice)
REQUEST CATEGORIES: Staffing / Hardware / Software / Other (delete inapplicable choices)
SAMA DETAILS
Please provide an overview of the SaMA here. Attach relevant supporting documentation such as
equipment roll-over schedules. A request for an increase in current projected funding will require
justification.
FUNDING
EXISTING (current year and projections)

2009: $ 2010: $ 2011: $
REQUESTED
2010: $ 2011: $ 2012: $
JUSTIFICATION FOR INCREASED FUNDING

If additional funding is being requested, please provide a rationale for the increase that includes details of
the new expenditure and an explanation why it can’t be supported through existing SAMA funding or
operational budgets.
BENEFITS
Provide a description of the benefits realised for the university through the 2010 allocation that includes
details of;
- The client group/s receiving benefits
- Type of benefit realised (eg compliance, service improvement, increased performance etc)
- Quantifiable measures of the gains
FALLBACK POSITION
2010: $ 2011: $ 2012: $
IMPACTS OF FALLBACK FUNDING

Please provide a description of impacts with quantifiable measures.
CRICOS INSTITUTION CODE 00213J Page 1

FUNDING ITEMS
Please itemise proposed expenditure below. Eligible items for funding include university infrastructure,
staff salaries (including oncosts), vendor consultancies and technical training. Items that are not eligible
for funding, unless otherwise approved, are non-technical training, conferences, workplace computers,
university funded mobile phones, home broadband and parking and general consumables such as printing
and stationery. Funding approval for these items may be sought from the Deputy Vice-Chancellor (TILS)
via the PPO.
STAFF SALARIES
HEW - level & step Position title and key responsibility $
CAPITALISED EXPENDITURE (hardware >$5k and software >$100k)
Item Description of item $
NON-CAPITALISED EXPENDITURE (hardware <$5k and software <$100k)
Item Description
$
TRAINING
Position Title Training course and key focus $
OTHER
Item Purpose $
TOTAL REQUESTED FROM AMP IT $
CRICOS INSTITUTION CODE 00213J Page 2

Key Changes in
Project Management Framework V4.3
December 2008
Table of Key Changes in PMF V4.3 from PMF V4.2
Improvement Reason
Updates to the following project templates: All footers updated to reflect version 4.3. In
addition the following updates were made:
• Project Notification • Project Notification

• Project Proposal • Project Proposal
• Project Proposal – Compliance • Project Proposal – Compliance
Guidelines Guidelines
• Feasibility Study Report • Feasibility Study Report
• Project Plan • Project Plan
• Project Plan – Compliance Guidelines • Project Plan – Compliance Guidelines
• Risk Management Plan • Risk Management Plan – new link to Risk
Management Framework
• Quality Plan
• Quality Plan
• Communication Plan
• Communication Plan
• Status Report
• Status Report – new colour coding
• Project Change Request
• Project Change Request
• Activity Completion Report
• Activity Completion Report
• Post Implementation Review
• Post Implementation Review
• Support and Maintenance Activity
Request • Support and Maintenance Activity
Request - changed dates for requesting
funding.
• PMF Guide 4.3 - includes link to Risk
Management Framework and an example
of the project registry with new colour
coding
Robyn Warren 23 December 2008

PMFv4 3wtemplates2010v3

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PMFv4 3wtemplates2010v3

Uploaded by

Copyright:

Available Formats

Project Management Framework

Project Management Framework Guide

The framework comprises this guide and a set of project management

Updated by Michele Berrie and Robyn Warren

CRICOS Institution Code 00213J

Version Number Date Reason/Comments

Project Change Requests ........................................................................................... 18

Part A – Project Management Framework

PMF_GUIDE_V4.3 PAGE 1 23 DECEMBER 2008

3 FOLLOWING THE PMF GUIDELINES

The PMF Guide and the Templates

Rigour and Length of Project Documentation

Document Version Control

PMF_GUIDE_V4.3 PAGE 2 23 DECEMBER 2008

4 THE PROJECT SELECTION PROCESS

Approval Workflow Diagrams

Notification Notification Notification

Project Proposal Project Proposal

Project Proposal (on

PMF_GUIDE_V4.3 PAGE 3 23 DECEMBER 2008

Release of Funding for Projects

Project Stages in the Registry

PMF_GUIDE_V4.3 PAGE 4 23 DECEMBER 2008

6 PROJECT KILL AND HALT POINTS

PMF_GUIDE_V4.3 PAGE 5 23 DECEMBER 2008

7 PROJECT MANAGERS AT QUT

8 STEERING COMMITTEE COMPOSITION

PMF_GUIDE_V4.3 PAGE 6 23 DECEMBER 2008

9 ADDITIONAL PROJECT AREAS FOR CONSIDERATION

PMF_GUIDE_V4.3 PAGE 7 23 DECEMBER 2008

PMF_GUIDE_V4.3 PAGE 8 23 DECEMBER 2008

Part B – Project Phases and Templates

PMF_GUIDE_V4.3 PAGE 9 23 DECEMBER 2008

11 PROJECT PHASES AND PMF TEMPLATES DIAGRAM

PMF_GUIDE_V4.3 PAGE 10 23 DECEMBER 2008

Project Notification advises that proposing and developing a project is being

PMF_GUIDE_V4.3 PAGE 11 23 DECEMBER 2008

It is vital to consult as many stakeholders as possible in the proposal

Project Specifications Request

The Project Proposal template may be used to request funding to prepare

Feasibility Study Request

The Project Proposal template may be used to request funding to conduct a

PMF_GUIDE_V4.3 PAGE 12 23 DECEMBER 2008

The documents should be submitted to the governing authorities for approval,

Feasibility Study Report

Streamlining with a Project Proposal into the Executing

PMF_GUIDE_V4.3 PAGE 13 23 DECEMBER 2008

capable of being executed. A high degree of involvement of the project team is

Work Breakdown Structure

A Work Breakdown Structure diagram is necessary.

Risk Management Plan

QUT’s Risk Management Policy is available in the University’s Manual of Policy

PMF_GUIDE_V4.3 PAGE 14 23 DECEMBER 2008

PMF_GUIDE_V4.3 PAGE 15 23 DECEMBER 2008

Communication strategies to address stakeholders previously identified in the

PMF_GUIDE_V4.3 PAGE 16 23 DECEMBER 2008

PMF_GUIDE_V4.3 PAGE 17 23 DECEMBER 2008

Project Status Report

Project Change Requests

Integrated Change Control

Scope Change Control

PMF_GUIDE_V4.3 PAGE 18 23 DECEMBER 2008