Escolar Documentos
Profissional Documentos
Cultura Documentos
Version 4.3
December 2008
Version Control
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 MANAGEMENT FRAMEWORK
PROJECT MANAGEMENT FRAMEWORK GUIDE
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.
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.
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.
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.
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.
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.
Limited Scope, Straightforward / Standard to Highly Complex Project Standard to Highly Complex Project
Streamlined Project with Known Product/Process with Unknown Product/Process
Project Plans
Activity - Risk Feasibility Study
Completion Report - Quality Report
- Comm’n
Project Plans
Post - Risk
Implementation - Quality
Review (For major projects) - Comm’n
Activity
Completion Report
Post
Implementation
(For major projects)
Review
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.
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.
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.
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.
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 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.
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.
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
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.
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
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.
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).
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.
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
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
Communication
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.
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.
Communication
Overall Project
Report Date
Resources
Project Name (A-Z)
Timeline
Budget
Scope
Phase
Risks
AMP (IT) Funded
Non AMP (IT) funded
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
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
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
Bring operational issues from their areas to the reference group meetings
Look for collaborative solutions
PMF_GUIDE_V4.3 PAGE 24 23 DECEMBER 2008
CRICOS INSTITUTION CODE 00213J
PROJECT MANAGEMENT FRAMEWORK GUIDE
Training Checklist
Training aspects to be taken into consideration for a project. Use the items in the checklist
as appropriate:
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
PMF_GUIDE_V4.3 PAGE 26 23 DECEMBER 2008
CRICOS INSTITUTION CODE 00213J
NOTIFICATION FORM
NAME OF PROJECT
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
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
CRICOS INSTITUTION CODE 00213J
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.
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.
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.
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
5 PROJECT COSTS
A rough estimate of the funding required that is envisaged for the project. Specify the expected
source of the funds.
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
A rough estimate when the project would take place and the duration.
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
PMFNotificationFormV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 2
CRICOS INSTITUTION CODE 00213J
PROJECT PROPOSAL
NAME OF PROJECT
Project Proposal
1 PROJECT INFORMATION
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.
PMFProjectProposaLV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 1
CRICOS INSTITUTION CODE 00213J
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
a cross appears and press delete.
The activities and tasks contained in the project, showing the boundaries of the project. This
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
PMFProjectProposaLV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 2
CRICOS INSTITUTION CODE 00213J
PROJECT PROPOSAL
NAME OF PROJECT
Constraints
Assumptions
PMFProjectProposaLV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 3
CRICOS INSTITUTION CODE 00213J
PROJECT PROPOSAL
NAME OF PROJECT
PMFProjectProposaLV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 4
CRICOS INSTITUTION CODE 00213J
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.
To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
9 SIGNIFICANT RISKS
The major risks to the project and treatment strategies, including mitigation. The probability
and impact ratings cover the risks.
To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
PMFProjectProposaLV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 5
CRICOS INSTITUTION CODE 00213J
PROJECT PROPOSAL
NAME OF PROJECT
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.
To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
Recommended Option 1
Salaries
PMFProjectProposaLV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 6
CRICOS INSTITUTION CODE 00213J
PROJECT PROPOSAL
NAME OF PROJECT
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
PMFProjectProposaLV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 7
CRICOS INSTITUTION CODE 00213J
PROJECT PROPOSAL
NAME OF PROJECT
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
PMFProjectProposaLV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 8
CRICOS INSTITUTION CODE 00213J
PROJECT PROPOSAL
NAME OF PROJECT
To delete this guidance box: position the cursor on the border, left click when a cross appears and press
delete.
Equipment
Software
Other
Annual Total
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.
To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
PMFProjectProposaLV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 9
CRICOS INSTITUTION CODE 00213J
PROJECT PROPOSAL
NAME OF PROJECT
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.
To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
PMFProjectProposaLV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 10
CRICOS INSTITUTION CODE 00213J
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
Project Approval: Information Technology Advisory Committee through the AMP (IT)
budget
2 VERSION CONTROL
Version
Date Reason/Comments/Approvals
Number
1.0 10/01/2006 Robert Bryde - Draft
2.0 06/02/2006 Ruby Khaw, Robert Bryde - Statistics included. Also other
changes
PMFFeasbilityStudyReportV4.1
ENTER FILENAME WITH VERSION NUMBER PAGE 1
CRICOS INSTITUTION CODE 00213J
FEASIBILITY STUDY REPORT
PAYABLES ON-LINE APPROVAL PROJECT
3 MANAGEMENT SUMMARY
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
PMFFeasbilityStudyReportV4.1
ENTER FILENAME WITH VERSION NUMBER PAGE 2
CRICOS INSTITUTION CODE 00213J
FEASIBILITY STUDY REPORT
PAYABLES ON-LINE APPROVAL PROJECT
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).
PMFFeasbilityStudyReportV4.1
ENTER FILENAME WITH VERSION NUMBER PAGE 3
CRICOS INSTITUTION CODE 00213J
FEASIBILITY STUDY REPORT
PAYABLES ON-LINE APPROVAL PROJECT
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.
PMFFeasbilityStudyReportV4.1
ENTER FILENAME WITH VERSION NUMBER PAGE 4
CRICOS INSTITUTION CODE 00213J
FEASIBILITY STUDY REPORT
PAYABLES ON-LINE APPROVAL PROJECT
Working Party
A working group was formed with broad representation from the university
community. The participants were:
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
PMFFeasbilityStudyReportV4.1
ENTER FILENAME WITH VERSION NUMBER PAGE 5
CRICOS INSTITUTION CODE 00213J
FEASIBILITY STUDY REPORT
PAYABLES ON-LINE APPROVAL PROJECT
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.
PMFFeasbilityStudyReportV4.1
ENTER FILENAME WITH VERSION NUMBER PAGE 6
CRICOS INSTITUTION CODE 00213J
FEASIBILITY STUDY REPORT
PAYABLES ON-LINE APPROVAL PROJECT
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
PMFFeasbilityStudyReportV4.1
ENTER FILENAME WITH VERSION NUMBER PAGE 7
CRICOS INSTITUTION CODE 00213J
FEASIBILITY STUDY REPORT FEASIBILITY STUDY REPORT
PAYABLES ON-LINE APPROVAL PROJECT
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
PMFFeasbilityStudyReportV4.1
ENTER FILENAME WITH VERSION NUMBER PAGE 8
CRICOS INSTITUTION CODE 00213J
FEASIBILITY STUDY REPORT
PAYABLES ON-LINE APPROVAL PROJECT
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.
PMFFeasbilityStudyReportV4.1
ENTER FILENAME WITH VERSION NUMBER PAGE 9
CRICOS INSTITUTION CODE 00213J
FEASIBILITY STUDY REPORT
PAYABLES ON-LINE APPROVAL PROJECT
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.
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.
The associated savings have been estimated to be about $300,000 per year. The
following table describes the benefits further and projected savings.
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”.
PMFFeasbilityStudyReportV4.1
ENTER FILENAME WITH VERSION NUMBER PAGE 11
CRICOS INSTITUTION CODE 00213J
FEASIBILITY STUDY REPORT
PAYABLES ON-LINE APPROVAL PROJECT
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.
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
CIS 30,000
PMFFeasbilityStudyReportV4.1
ENTER FILENAME WITH VERSION NUMBER PAGE 12
CRICOS INSTITUTION CODE 00213J
FEASIBILITY STUDY REPORT
PAYABLES ON-LINE APPROVAL PROJECT
8 RECOMMENDATIONS
PMFFeasbilityStudyReportV4.1
ENTER FILENAME WITH VERSION NUMBER PAGE 13
CRICOS INSTITUTION CODE 00213J
Project Plan
Name of project
Version number:
Date of current plan:
PMF V4.4
CRICOS Institution Code 00213J
PROJECT PLAN
NAME OF PROJECT
2 VERSION CONTROL
Record changes to the project plan.
Version
Date Reason/Comments/Approvals
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.
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.
To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
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
4 PROJECT INFORMATION
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.
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.
6 OBJECTIVES
PMFPROJECTPLANV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 1
CRICOS INSTITUTION CODE 00213J
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.
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.
Scope
Within Scope
Outside Scope
Constraints
Assumptions
PMFPROJECTPLANV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 2
CRICOS INSTITUTION CODE 00213J
PROJECT PLAN
NAME OF PROJECT
PMFPROJECTPLANV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 3
CRICOS INSTITUTION CODE 00213J
PROJECT PLAN
NAME OF PROJECT
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.
To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
PMFPROJECTPLANV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 4
CRICOS INSTITUTION CODE 00213J
PROJECT PLAN
NAME OF PROJECT
PMFPROJECTPLANV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 5
CRICOS INSTITUTION CODE 00213J
PROJECT PLAN
NAME OF PROJECT
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
PMFPROJECTPLANV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 6
CRICOS INSTITUTION CODE 00213J
PROJECT PLAN
NAME OF PROJECT
Equipment
Software
Other
Total
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.
To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
PMFPROJECTPLANV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 7
CRICOS INSTITUTION CODE 00213J
PROJECT PLAN
NAME OF PROJECT
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
To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
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.
To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
Steering Committee
Sponsor
Client Leader
Project Manager
Expert/Specialist
Steering Committee
member (general)
DVC (TILS) or
nominee
PMFPROJECTPLANV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 8
CRICOS INSTITUTION CODE 00213J
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.
To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
PMFPROJECTPLANV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 9
CRICOS INSTITUTION CODE 00213J
RISK MANAGEMENT PLAN
NAME OF PROJECT
1 PROJECT INFORMATION
Project Number (if applicable):
Project Name: The project name
Date: Today’s date
Project Ownership: Area responsible for the project
Prepared by: Name and project position
Project Contacts:
Name Position Phone Email
Primary
Other
Other
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.
PMFRISKMANAGEMENTPLANV4.3
RISK_MANAGE_PLAN_TEMPLATE4.3.DOC PAGE 1
CRICOS INSTITUTION CODE 00213J
RISK MANAGEMENT PLAN
NAME OF PROJECT
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
PMFRISKMANAGEMENTPLANV4.3
RISK_MANAGE_PLAN_TEMPLATE4.3.DOC PAGE 2
CRICOS INSTITUTION CODE 00213J
RISK MANAGEMENT PLAN
NAME OF PROJECT
# 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
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
PMFRISKMANAGEMENTPLANV4.3
RISK_MANAGE_PLAN_TEMPLATE4.3.DOC PAGE 3
CRICOS INSTITUTION CODE 00213J
RISK MANAGEMENT PLAN
NAME OF PROJECT
# 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
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
PMFRISKMANAGEMENTPLANV4.3
RISK_MANAGE_PLAN_TEMPLATE4.3.DOC PAGE 4
CRICOS INSTITUTION CODE 00213J
RISK MANAGEMENT PLAN
NAME OF PROJECT
# 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
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
PMFRISKMANAGEMENTPLANV4.3
RISK_MANAGE_PLAN_TEMPLATE4.3.DOC PAGE 5
CRICOS INSTITUTION CODE 00213J
RISK MANAGEMENT PLAN
NAME OF PROJECT
# 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
Others
6.
Interdependenc
ies with other
systems, etc
Level of
ongoing
support
PMFRISKMANAGEMENTPLANV4.3
RISK_MANAGE_PLAN_TEMPLATE4.3.DOC PAGE 6
CRICOS INSTITUTION CODE 00213J
QUALITY PLAN
NAME OF PROJECT
Quality Plan
The Quality Plan contains the quality standards, quality assurance processes and quality control
activities for a project.
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 Quality Plan.
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: Date of current Quality Plan
Project Ownership: Area responsible for the project
Prepared by: Name and project position
Contact Names:
Name Position Phone Email
Primary
Other
Other
2 VERSION CONTROL
Add new rows to the table as necessary.
Version
Date Reason/Comments/Approvals
Number
PMFQUALITYPLANV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 1
CRICOS INSTITUTION CODE 00213J
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
a cross appears and press delete.
.
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
To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
A record of the issues and outcomes resulting from quality plan activities.
To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
PMFQUALITYPLANV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 2
CRICOS INSTITUTION CODE 00213J
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.
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 Communication Plan.
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: Date of current Communication Plan
Project Ownership: Area responsible for the project
Prepared by: Name and project position
Contact Names:
2 VERSION CONTROL
Add new rows to the table as necessary.
Version
Date Reason/Comments/Approvals
Number
PMFCommunicationPlanV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 1
CRICOS INSTITUTION CODE 00213J
COMMUNICATION PLAN
NAME OF PROJECT
Stakeholder2 or
Group2
Stakeholder3 or
Group3
PMFCommunicationPlanV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 2
CRICOS INSTITUTION CODE 00213J
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.
To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
Stakeholder2 or
Group2
Stakeholder3 or
Group3
PMFCommunicationPlanV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 3
CRICOS INSTITUTION CODE 00213J
PROJECT STATUS REPORT
NAME OF PROJECT
1 PROJECT INFORMATION
Project/Program Number (if applicable):
Project Name: A brief name to describe the project
Date: Date of current Project Status Report Report Number: (1, 2, 3, etc)
Project Ownership: Area responsible for the project
Prepared by: Name and project position
Distribution List: List of those receiving the report
Project Objective: Copy project objective from the Project Plan
Details of project progress including highlights, achievements and other notable items.
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
PMFSTATUSREPORTV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 1
CRICOS INSTITUTION CODE 00213J
PROJECT STATUS REPORT
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.
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.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.
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
PMFSTATUSREPORTV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 2
CRICOS INSTITUTION CODE 00213J
PROJECT STATUS REPORT
NAME OF PROJECT
3.2 Timeline
A record of the progress made against milestones and deliverables to date or since last
report.
Type in your project information below, then delete this guidance box: position the cursor on the border, left click
Actual
Due Completed Reason for Actions and
Milestones Deliverables
Date Slippage Resolutions
Date
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.
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
Amount of
Budget in Amount On
Category Project Spent to Track Explanation if Necessary
Plan by Date Y/N?
Category
PMFSTATUSREPORTV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 3
CRICOS INSTITUTION CODE 00213J
PROJECT STATUS REPORT
NAME OF PROJECT
Amount of
Budget in Amount On
Category Project Spent to Track Explanation if Necessary
Plan by Date Y/N?
Category
A list of forthcoming, notable activities that can be reviewed in the next Status Report.
Include comments where appropriate.
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
Due
Activity Deliverables Comments
Date
PMFSTATUSREPORTV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 4
CRICOS INSTITUTION CODE 00213J
PROJECT STATUS REPORT
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.
To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
# 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
ENTER FILENAME WITH VERSION NUMBER PAGE 5
CRICOS INSTITUTION CODE 00213J
PROJECT STATUS REPORT
NAME OF PROJECT
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:
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
ENTER FILENAME WITH VERSION NUMBER PAGE 6
CRICOS INSTITUTION CODE 00213J
PROJECT STATUS REPORT
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
ENTER FILENAME WITH VERSION NUMBER PAGE 7
CRICOS INSTITUTION CODE 00213J
PROJECT CHANGE REQUEST
NAME OF PROJECT
1 PROJECT INFORMATION
Project Number (if applicable):
Project Name: Name of project
Date: Of the change request
Project Ownership: Area responsible for the project
Prepared by: Name and project position
Distribution List: List of those receiving the change request
A full description of the change request and the basis for the change. Include expected
outcomes and benefits.
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
PMFPROJectChangeRequestV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 1
CRICOS INSTITUTION CODE 00213J
PROJECT CHANGE REQUEST
NAME OF PROJECT
Indicate Y/N. If Y, give details, including time frame, etc. If N, give reason.
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
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.
To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
PMFPROJectChangeRequestV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 2
CRICOS INSTITUTION CODE 00213J
ACTIVITY COMPLETION REPORT
NAME OF PROJECT
1 PROJECT INFORMATION
Project Number (if applicable):
Project Name: A brief name to describe the project
Date: Today’s date
Project Ownership: Areas responsible for project
Prepared by: Name and project position
Contact Names:
3 CLOSING ACTIVITIES
PMFActivityCompletionFormV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 1
CRICOS INSTITUTION CODE 00213J
ACTIVITY COMPLETION REPORT
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.
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.
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?
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
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?
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
PMFActivityCompletionFormV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 2
CRICOS INSTITUTION CODE 00213J
ACTIVITY COMPLETION REPORT
NAME OF PROJECT
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.
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.
PMFActivityCompletionFormV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 3
CRICOS INSTITUTION CODE 00213J
PIR REPORT
NAME OF PROJECT
1 PROJECT INFORMATION
Project Number (if applicable):
Project Name: Name of project
Date: Of submission of the PIR
Project Ownership: Area responsible for the project
Prepared by: Name and project position
2 SUMMARY OF PROJECT
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
To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
PMF_PIRV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 1
CRICOS INSTITUTION CODE 00213J
PIR REPORT
NAME OF PROJECT
PMF_PIRV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 2
CRICOS INSTITUTION CODE 00213J
PIR REPORT
NAME OF PROJECT
A table showing information about key project areas. Include a reference for evidence where appropriate.
To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
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
ENTER FILENAME WITH VERSION NUMBER PAGE 3
CRICOS INSTITUTION CODE 00213J
PIR REPORT
NAME OF PROJECT
5 OBJECTIVE OUTCOMES
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.
To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
Benefits Realised Benefit realised? Outcome Reference for Reason for Variance from Project
Evidence Plan
(as in Project Plan) (Score 1-5
1=Not at all
5= Completely)
PMF_PIRV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 4
CRICOS INSTITUTION CODE 00213J
PIR REPORT
NAME OF PROJECT
Benefits Realised Benefit realised? Outcome Reference for Reason for Variance from Project
Evidence Plan
(as in Project Plan) (Score 1-5
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.
To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
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
ENTER FILENAME WITH VERSION NUMBER PAGE 5
CRICOS INSTITUTION CODE 00213J
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?
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
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?
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
PMF_PIRV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 6
CRICOS INSTITUTION CODE 00213J
PIR REPORT
NAME OF PROJECT
• Appendix A - document 1
• Appendix B - document 2
PMF_PIRV4.3
ENTER FILENAME WITH VERSION NUMBER PAGE 7
CRICOS INSTITUTION CODE 00213J
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)
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
REQUESTED
2010: $ 2011: $ 2012: $
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
STAFF SALARIES
Item Description
$
TRAINING
OTHER
Item Purpose $
Improvement Reason
Updates to the following project templates: All footers updated to reflect version 4.3. In
addition the following updates were made: