Project Management Framework Project Management Framework Guide The framework comprises this guide and a set of project management templates, as referenced within this guide.
Prepared by Michele Berrie Updated by Tracy Smith Project Portfolio Office
Version 4.2
January 2008
CRICOS Institution Code 00213J
PROJECT MANAGEMENT FRAMEWORK PROJECT MANAGEMENT FRAMEWORK GUIDE
Version Control Version Number
Date
Reason/Comments
1.0 1.1 1.2 1.3 1.4 1.5
14 March 2003 1 April 2003 16 April 2003 28 April 2003 12 May 2003 19 May 2003
2.0 2.1 2.2
26 May 2003 30 May 2003 24 February 2004
3.0
1 May 2005
4.0
19 May 2006
4.1
21 July 2006
4.2
8 January 2008
Additions and edits to document Additions and edits Additions and edits Additions and edits Additions and edits Additions and edits for SC, deletion of forms category information Final edits and changes – to go to SC SC edits and changes Revision of PMF Guide for 2004, including BCF and Internal Audit changes Post Implementation Review Report with change in process for PIR and Activity Completion Report, plus continuous improvement changes to templates and PMF Guide Revised version of the Risk Management Plan to adhere to changes in the University Risk Management Framework. Revised version of the Project Proposal to strengthen benefits realisation, more closely aligned costings tables to reports from the finance system and deliverables in time frames. Change Project Proposal to allow use for Feasibility Study and Project Specifications document, etc, also PMF Guide. Workflow Approval Diagrams added to PMF Guide. Incorporation of a new Feasibility Study Report to capture findings and encourage PM’s to use this option to make the best use of AMP (IT) funds. Communication Plan revamped. More generic PMF Guide, breaking out AMP (IT) specifics Plus continuous improvement changes to templates and the PMF Guide Removal of the Business Case Framework section Updated references to IT Governance groups and process for project status reporting. Also updated all project templates. See Key Changes document for full details.
PROJECT MANAGEMENT FRAMEWORK PROJECT MANAGEMENT FRAMEWORK GUIDE
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................................................................................................ 5 8 Steering Committee Composition ................................................................................. 6 9 Additional Project Areas for Consideration ................................................................. 6 PART B – PROJECT PHASES AND TEMPLATES .............................................................................. 8 10 PMF Project Phases ...................................................................................................... 8 11 Project Phases and PMF Templates Diagram ............................................................ 9 12 Initiating Phase ............................................................................................................ 10 Project Notification ..................................................................................................... 10 Project Proposal.......................................................................................................... 10 Project Specifications Request.................................................................................. 11 Feasibility Study Request........................................................................................... 11 Feasibility Study Report ............................................................................................. 12 Streamlining with a Project Proposal into the Executing Phase............................ 12 13 Planning Phase............................................................................................................ 12 Project Plan.................................................................................................................. 13 Work Breakdown Structure ........................................................................................ 13 Risk Management Plan ............................................................................................... 13 Quality Plan.................................................................................................................. 14 Communication Plan................................................................................................... 15 14 Executing Phase.......................................................................................................... 15 15 Controlling Phase........................................................................................................ 16 Project Monitoring....................................................................................................... 16 Project Status Report.................................................................................................. 17
PROJECT MANAGEMENT FRAMEWORK PROJECT MANAGEMENT FRAMEWORK GUIDE
Project Change Requests........................................................................................... 17 Integrated Change Control ......................................................................................... 17 Scope Change Control................................................................................................ 17 Time Control ................................................................................................................ 18 Cost Control................................................................................................................. 18 Quality Control ............................................................................................................ 18 Risk ............................................................................................................................... 18 Communication ........................................................................................................... 18 16 Closing Phase.............................................................................................................. 19 Project Closure ............................................................................................................ 19 Post Implementation Review...................................................................................... 19 17 Future of the PMF ........................................................................................................ 20 18 Appendix A – Project Registry................................................................................... 21 19 Appendix B – Key Players in a QUT Project............................................................. 22 Primary Sponsor responsibilities .............................................................................. 22 Client Leader................................................................................................................ 22 Steering Committee responsibilities......................................................................... 22 Deputy Vice-Chancellor (TILS) – or nominee ........................................................... 22 Expert/Specialist responsibilities .............................................................................. 23 Internal Audit responsibilities.................................................................................... 23 Project manager responsibilities............................................................................... 23 Project Reference Group ............................................................................................ 23 20 Appendix C – Communication Plan Checklists ....................................................... 25 Marketing and Communication Checklist................................................................. 25 Training Checklist ....................................................................................................... 25
PROJECT MANAGEMENT FRAMEWORK PROJECT MANAGEMENT FRAMEWORK GUIDE
Part A – Project Management Framework Information 1 INTRODUCTION This document contains a Project Management Framework (PMF) for QUT. The PMF follows best practice project management guidelines with templates and completed examples. Therefore, the PMF can be used as a standard, but flexible, methodology for a wide range of projects across the University. The PMF is a mandatory standard for Asset Management Program Information Technology (AMP (IT)), projects and other IT projects at QUT. Projects in special disciplines like building construction and those that follow ISO 9001 are generally exempt from the PMF. This PMF Guide contains many details for AMP (IT) projects, which must follow the processes closely, but the PMF can be applied generically to other types of projects. Projects outside the AMP (IT) follow the PMF with the following differences: •
Funding sources
•
Governance/approval body
•
Project Portfolio Office interaction not essential, depending on circumstances
The PMF is composed of 2 parts: •
Part A with general information about projects at QUT.
•
Part B with details of five standard overlapping phases through the life of a project: initiating, planning, executing, controlling and closing. Activities and project templates used within each phase are explained. The PMF templates and examples for each are provided separately.
The Project Portfolio Office provides a focus for: •
Continuous improvement and maturity in project management at QUT
•
Advice on this document and the PMF templates
•
Connection to other, experienced project managers for guidance and possible mentoring
•
Direction for training in the PMF and project management more generally
•
Applicability of the PMF
•
Feedback on the PMF
The Project Portfolio Office email address is project_portfolio@qut.edu.au
2 PURPOSE Systems and services at QUT have become increasingly more interdependent and complex over time. This environment means that a standard, consistent and comprehensive means to manage projects well at QUT is essential. The decision was made several years ago to develop a custom project management framework that would evolve as the project management community and the organisation matured. The PMF would follow best practice guidelines from the Project Management Institute (PMI) and its Project Management Body of Knowledge (PMBOK), which is an ANSI standard. Certain project management practices already being followed in limited areas at the University were also incorporated.
PMF_GUIDE_V4.2 CRICOS INSTITUTION CODE 00213J
PAGE 1
8 JANUARY 2008
PROJECT MANAGEMENT FRAMEWORK PROJECT MANAGEMENT FRAMEWORK GUIDE
This approach has been highly successful. PMF V1.0 was released in July 2003 with several later releases. The revisions introduced improvements over time accompanied by an educative program from the Project Portfolio Office as reinforcement. As a result the PMF is embedded in IT project management at QUT and uptake is expanding into other types of projects.
3 FOLLOWING THE PMF GUIDELINES Overall considerations for using the PMF are:
The PMF Guide and the Templates The PMF Guide is a reference for the framework while separate PMF project templates provide specific project documentation. Part B of this document provides direction on when to use the templates within standard project phases. Each template has guidance boxes for each of its categories/heading providing specific information on the details to be included. Flexible changes in the templates may be made where appropriate. MS Project is the recommended support tool for PMF projects. However, the basic PMF templates use Word tables. Calculations for costs and resources may benefit from the use of an Excel spreadsheet.
Rigour and Length of Project Documentation In general terms the length of project documents will be contingent on the scope and complexity of the project. Documents should be as concise as possible with enough information for monitoring, tracking and auditing purposes. Focused documents that are referred to and used should be the goal, no matter what the size of the project. A common complaint is that overly long documents may appear first-rate, but are never read or referred to. The project manager should perform a risk analysis when determining the rigour with which the PMF should be applied to the project. The project manager should look at the range of project management activities and consider the effort expended compared with benefits gained. For example, a project that costs little but has strategic value may benefit from a well-developed communication plan. The project steering committee or other governing authority makes the decision on the extent to which the PMF is to be applied.
Document Version Control Project plans and other documents should use version control, that is, show the dates when the documents and plans change with the reason for the change. If required, a table for sign off should be included. If possible, indicate the changes. The changed file may be saved as a new version if tracking the changes is difficult (as in a Project Plan). A two-tiered numbering system is the standard: for example, 1.0 and 2.3. A major change requires an increase before the point, while a minor change means an increase in the number after the point. Version 0.0 is the first draft of a document. The filename of a plan should contain the version number and be contained in the footer as an indicator. Version control allows effective tracking and information for audit purposes. A Version Control table is included with most forms and can be inserted where necessary with other documents.
PMF_GUIDE_V4.2 CRICOS INSTITUTION CODE 00213J
PAGE 2
8 JANUARY 2008
PROJECT MANAGEMENT FRAMEWORK PROJECT MANAGEMENT FRAMEWORK GUIDE
4 THE PROJECT SELECTION PROCESS QUT will fund and progress those projects that provide the best value proposition for advancing its mission and goals according to the QUT Blueprint and the IT Vision and Strategy, taking into account financial costs and benefits. AMP (IT) projects follow a well laid out set of processes for submission and approvals. Other projects may have different governing authorities and funding sources, but the same general principle applies. Approving authorities for those projects will adjust criteria to make approvals according to their own circumstances.
AMP (IT) Information The AMP (IT) Prioritisation web page, in the PPO web site, contains links to documents containing detailed information specific to the AMP (IT), including governance processes, funding eligibility and approvals processes.
Approval Workflow Diagrams
Limited Scope, Straightforward / Streamlined Project
Standard to Highly Complex Project with Known Product/Process
Standard to Highly Complex Project with Unknown Product/Process
Notification
Notification
Notification
Project Proposal
Project Proposal
Project Proposal (Feasibility Study)
Activity Completion Report
Project Plans - Risk - Quality - Comm’n
Feasibility Study Report
Project Proposal (Project Specifications)
Activity Completion Report
Project Proposal (on the basis of FS or PS findings)
Post Implementation Review
Project Plans - Risk - Quality - Comm’n
(For major projects)
Activity Completion Report
Post Implementation Review
PMF_GUIDE_V4.2 CRICOS INSTITUTION CODE 00213J
PAGE 3
(For major projects)
8 JANUARY 2008
PROJECT MANAGEMENT FRAMEWORK PROJECT MANAGEMENT FRAMEWORK GUIDE
Release of Funding for Projects The PMF stipulates that the Project Proposal lays out the elements of a project for consideration for approval by a governing authority. Approval means that funds are reserved. Circumstances under which reserved funds are released into a project account: • • • •
•
Partial release for engagement of a project manager to prepare a Project Plan (request through email, decided on a case by case basis) after Project Proposal approval Approval to prepare a Feasibility Study (using the Project Proposal template) Approval to prepare Project Specifications (using the Project Proposal template) Approval of a streamlined Project Proposal that is treated as a Project Plan for small projects. See section on Streamlining with a Project Proposal into the Executing Phase in the write up for Project Proposal in Initiating Phase in Part B of this guide. An approved Project Plan from the Planning Phase
AMP (IT) projects follow this process rigorously. The process can be modified for other types of projects, as appropriate.
5 PROJECT REGISTRY The Project Registry is a central repository document that provides information on current and recently completed IT projects. Most projects in the registry are information technology (IT) projects funded from the AMP (IT) budget, but other IT projects also appear. The Project Portfolio Office administers the Project Registry and produces a quarterly report with a brief description of the projects and their current statuses, supplied by the project managers.
Project Stages in the Registry The Project Registry aligns with project phases in the Project Management Body of Knowledge, PMBOK Guide 2000 (pp 30-31), tailored for QUT projects. See Part B, the section on Project Phases and Templates later in this document for more information on the templates to be used with the standard phases. The Project Registry stages: •
Initiating This stage begins with the lodging of a Notification Form, followed by submission of a Project Proposal or Feasibility Study. Upon approval, project funds are reserved.
•
Planning This stage includes the preparation and approval of a Project Plan. The project steering committee or authoritative body must approve the plan. For AMP (IT) projects the DVC (TILS) must then approve. Funds will be released upon approval.
•
Executing This stage covers the implementation of the approved Project Plan. Project Change Requests should be approved by the steering committee/governing authority. Significant changes in AMP (IT) projects, for example, request for additional funding, must also be approved by the DVC (TILS).
•
Halted
PMF_GUIDE_V4.2 CRICOS INSTITUTION CODE 00213J
PAGE 4
8 JANUARY 2008
PROJECT MANAGEMENT FRAMEWORK PROJECT MANAGEMENT FRAMEWORK GUIDE
This status indicates that project has paused while significant changes are considered or taking place. •
Terminated This status results when a project is killed at any stage, for whatever reason. An Activity Completion Report is required.
•
Closing This stage involves completing or ending the project, as indicated through an Activity Completion Report for all projects. Activity completion may mean a successful completion of the project or an early termination during the planning or execution stages of the project.
•
Retired After completion or termination, a project is retired after submission of a Project Activity Completion Report for all projects and, then, a Post Implementation Review, if required. A Post Implementation Review is required: o
Upon completion or termination of all major projects
o
For AMP (IT) projects upon completion or termination of any other project at the request of the DVC (TILS)
See Appendix A to view an entry from the Project Registry.
6 PROJECT KILL AND HALT POINTS The QUT Project Management Framework recognises that conditions may arise during the life of the project that dictate that a steering committee or other decision-making authority should end or halt a project before its completion. Ending a project may be viewed as a positive outcome for all, depending on the situation. For example, a global change in technology may mean that the underlying technology in the project has become obsolete and killing the project will have the positive outcome of funds and resources being released for another project. An alternative approach may be to halt the project while resizing the project, addressing external factors, finding more funds or making other major changes. Restarting the project will mean resubmission of appropriate documents and sign off by approving authorities again. Major kill and halt points are: •
A Project Proposal that is considered for approval and reserved funding.
•
A Project Plan that is reviewed by the steering committee for confirmation and final release of funds to proceed with implementation.
•
A steering committee meeting in the execution phase of the project at a major milestone point, during which reason to kill or halt the project is decided.
7 PROJECT MANAGERS AT QUT The Project Management Body of Knowledge PMBOK Guide 2000 identifies key project management areas in which all project managers should possess a degree of proficiency, irrespective of the projects they are working on: integration, scope, time, cost, quality, human resource, communications, risk and procurement. Additionally, the PMBOK Guide specifies that project managers should have general management skills: leading, communicating, negotiating, problem solving and influencing the organisation. All these skills contribute to the success of projects in the complex QUT environment in which business activities, systems and other projects are interdependent and integrated.
PMF_GUIDE_V4.2 CRICOS INSTITUTION CODE 00213J
PAGE 5
8 JANUARY 2008
PROJECT MANAGEMENT FRAMEWORK PROJECT MANAGEMENT FRAMEWORK GUIDE
The project manager should also be knowledgeable about the contents of this, the QUT Project Management Framework (PMF) Guide and its associated templates. Good managers for projects at QUT may be realised by: •
Hiring project managers with expertise already in place
•
Encouraging professional standard project management accreditation
•
Raising awareness of the opportunities for staff development in management, negotiation skills, conflict management, etc, at QUT
•
Providing opportunities for staff members to gain experience by working on projects
•
Supporting the placement of mentors with project management expertise
•
Gaining knowledge of and training in the PMF.
Note that the amount of effort expended on project management activities depends on the value and benefits that these activities bring to the project.
8 STEERING COMMITTEE COMPOSITION A project should be guided by a steering committee working at a strategic level. Note that a small project may have the sponsor as its entire governing authority without a steering committee. A steering committee should be small in number for best practice. A minimum composition is: •
Sponsor - is accountable for the project, chairs the steering committee meetings and has ongoing accountability for the outcomes of the project in the form of its end product/services.
•
Client Leader - provides QUT business leadership, ownership and guidance to the project. This role is critical to the project. Client Leaders can ensure that QUT’s leadership view is inserted into key areas of the projects, for example, timing, cost and quality considerations. They will normally be chosen on the basis of their having a keen interest in the outcome of the project (as a user). They do not have line responsibility for the project’s end product/services.
•
Expert/specialist - often the key person who will be designing and building the outcomes.
•
The DVC (TILS) or nominee - required on all AMP (IT) projects and designated by the DVC (TILS).
•
Internal Auditor - invited as an observer to attend steering committees of major projects. With AMP (IT) projects, Internal Audit is always queried as to whether they wish to provide a representative on the steering committee.
QUT steering committees are able to use this model as a basis to form memberships. Other members may be added, as appropriate. The project manager is usually not a member, but reports to the steering committee. In some instances, the project manager and specialist may be the same person. See Appendix B for a list of roles and responsibilities of steering committees, sponsors and project managers.
9 ADDITIONAL PROJECT AREAS FOR CONSIDERATION The PMF is a set of guidelines for many areas of project management. Additional aspects outside the scope of the PMF that should be considered for specific projects are:
PMF_GUIDE_V4.2 CRICOS INSTITUTION CODE 00213J
PAGE 6
8 JANUARY 2008
PROJECT MANAGEMENT FRAMEWORK PROJECT MANAGEMENT FRAMEWORK GUIDE
•
Systems Development Framework (SDF) – A flexible framework with different options for software and systems development available with the PMF templates under Additional Documents. The SDF is available with the templates from the PMF web site.
•
HR Change Management – If workflow changes are part of the outcomes, the QUT Change Management Policy web site should be studied and contact made with HR to avoid problems. Workplace change should ideally be planned and supported by the University planning processes. However, often change can be relatively unexpected and may need to occur within more urgent timeframes. The policy outlines key principles, procedures and practices that the University seeks to apply to ensure the effective management of workplace change consistent with sound management practice, relevant commitments outlined in University enterprise bargaining agreements, and related policies and procedures.
•
QUT intellectual property matters – Identification of intellectual property should take place early in a project so that the decision can be made whether to protect that intellectual property to the benefit of QUT. See the Intellectual Property Policy, Appendix 22 of the Manual of Policies and Procedures and use the QUT Copyright Guide. A QUT Copyright Officer is located in the Office of the DVC (TILS).
•
Equity – Project staff should always consider equity issues and include these factors at the initial stages of the project. Refer to the QUT Equity web site for information.
•
Web Governance Framework – QUT’s Web Governance Framework should be taken into account when evaluating and procuring applications and, also, when managing web sites around the University. The Web Governance Framework provides a model for the governance of websites and web content at QUT. The framework addresses the issues of quality, accuracy, currency, accessibility, and compliance (with corporate web policy and standards) of QUT websites. The framework defines the necessary processes, staff roles and responsibilities, which must be followed to ensure that websites and web content are appropriately governed.
•
Procurement – Tendering, purchasing and contract management are wide topics best dealt with through the advice and procedures from the Department of Financial Services. Additionally, see Web Governance Framework, above, if web issues are involved.
•
Open Source Software – The University should deploy and use Open Source Software (OSS) where possible and efficient. Therefore, OSS should be considered for all software procurement. It is recognised that OSS software may be unavailable or unsuitable for specific situations. The Information Management Office of the Australian Government provides the SourceIT web site with the Guide to Open Source Software for Australian Government Agencies, an excellent reference document.
•
Griffith/QUT Collaboration – A collaborative IT relationship exists between the Griffith Division of Information Services and QUT Division of Technology, Information and Learning Support (TILS). The partnership between the two Divisions under the Collaboration Program leads to possible synergies and cost effectiveness with the sharing of capability, resources and expertise. Therefore, options for collaboration with Griffith on a TILS project should be examined. Contact the Project Portfolio Office at project_portfilio@qut.edu.au for information, as required.
PMF_GUIDE_V4.2 CRICOS INSTITUTION CODE 00213J
PAGE 7
8 JANUARY 2008
PROJECT MANAGEMENT FRAMEWORK PROJECT MANAGEMENT FRAMEWORK GUIDE
Part B – Project Phases and Templates 10 PMF PROJECT PHASES The Project Management Framework is divided into five standard phases, as defined in the Project Management Body of Knowledge, PMBOK Guide 2000 (pp 30-31), tailored for QUT projects. Each phase has associated activities, but, additionally, the phases overlap. •
Initiating processes – preparing a notification followed by a project proposal, then, gaining approval and reserved funding for the project. The end to end life of the project must be taken into account at the proposal stage, for example, recognising that the information for an Activity Completion Report at the end of the project should be considered at the proposal stage and throughout subsequent stages of the project.
•
Planning processes – defining and refining objectives, preparing the Project Plans and associated sub-plans for running the project, then gaining final allocation of funding.
•
Executing processes – implementing the Project Plans; coordinating people and other resources to carry out the Project Plans. Typically, this is the longest phase of a project.
•
Controlling processes – ensuring that project objectives are met by monitoring and measuring progress regularly to identify variances from the plans; taking corrective action when necessary; tracking the variances and changes. Controlling has much overlap with other phases.
•
Closing Processes – bringing the project to an orderly end: formalising and communicating the acceptance or conclusion of a project, handing over to the ongoing accountable area, completing an Activity Completion Report and, for major projects, holding a post implementation review. The project manager is not necessarily the one to facilitate each activity, for example, an area manager may prepare a project proposal with the project manager being appointed afterwards. Someone external to the project should conduct the Post Implementation Review, if required. See next page for a diagram of a typical project as represented through the phases.
PMF_GUIDE_V4.2 CRICOS INSTITUTION CODE 00213J
PAGE 8
8 JANUARY 2008
PROJECT MANAGEMENT FRAMEWORK PROJECT MANAGEMENT FRAMEWORK GUIDE
11 PROJECT PHASES AND PMF TEMPLATES DIAGRAM A standard, generic project; time for and level of activities will vary with specific projects
Executing Processes
Level Of Activity
Planning Processes
Closing Processes
Initiating 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 Resources Reserved PMF_GUIDE_V4.2 CRICOS INSTITUTION CODE 00213J
PAGE 9
Project Confirmation Resources 8 JANUARY 2008
Governance Sign-off
PROJECT MANAGEMENT FRAMEWORK GUIDE
12 INITIATING PHASE Definition: declaring and authorising the project This phase includes notification of the intention of developing a project proposal. As part of the same phase, the authority controlling project resources, typically funding, will approve or reject the proposal. With approval, the AMP (IT) projects will have funds reserved for resources and governing authorities for other projects may follow this process. •
Project Notification
•
Project Proposal (may be used in three ways)
•
o
Project Proposal - define the conceived project as the basis for approving and reserving funding for a project.
o
Project Specifications Request - request funding to prepare detailed project specifications.
o
Feasibility Study Request - request funding to conduct a Feasibility Study, used to provide an analysis of the objectives, requirements, and concepts of the proposed work
Feasibility Study Report
See the Approval Workflow Diagrams in The Project Selection Process in Part A of this guide for clarification of the approval process.
Project Notification Project Notification advises that proposing and developing a project is being considered. Information supplied is succinct and broad in nature. This information may be used to review the list of other projects to determine overlap or redundancy with these projects or systems and to identify integration issues. The potential project may be discarded before much effort has been expended if conflicts or other impacting factors are evident. For AMP (IT) projects a Project Notification form must be completed and sent to the Project Portfolio Office at project_portfolio@qut.edu.au. The AMP (IT) Systems and Projects Advisory Group then reviews the potential project. Other projects may be posted to a local database or list of projects, as available. No facility for registering and tracking projects centrally outside the Project Registry currently exists at QUT.
Project Proposal The Project Proposal defines the conceived project as the basis for approving and reserving funding for a project. Care must be taken in preparing the document to present the project’s case accurately, so that the University has relevant information to allow it to progress the most valuable projects. Compelling reasons for carrying out the project in the form of specifying clear, quantifiable benefits and mechanisms for realising them beyond the end of the project are increasingly required. The relevant business area usually prepares the project proposal. During the process, the outcomes of the project must be considered and planned for. This means that the Activity Completion Report (and Post Implementation Review for a major project) and its requirements should kept in mind at all times during the Planning Phase and throughout the life of the project. For AMP (IT) projects the expectation is that a presentation on the completed Activity Completion Report (and Post Implementation Review for a major project) will be made at project end.
PMF_GUIDE_V4.2 CRICOS INSTITUTION CODE 00213J
PAGE 10
8 JANUARY 2008
PROJECT MANAGEMENT FRAMEWORK GUIDE
It is vital to consult as many stakeholders as possible in the proposal process to ensure that all aspects of the project are considered and included in the proposal, then in the Project Plan. The proposal should clearly state key project information as shown in the template, including objectives, scope, scope issues, project assumptions as well as benefits and the business value to QUT linked to success criteria and risks. Poor definition of the objectives and scope often lead to project failure; studies suggest a strong correlation between project success and clear scope definition. The proposal should contain information on alternative options, if available, with a recommendation on which option to select. An AMP (IT) projects, the Project Proposal should be submitted to the Project Portfolio Office at project_portfolio@qut.edu.au as the office facilitates governance.
Project Specifications Request The Project Proposal template may be used to request funding to prepare detailed project specifications so that accurate plans and budgets can be developed where required. Then, a Project Proposal that incorporates information drawn from these specifications may be submitted for the main project. A specification is basically the blue print (floor plan) for the project to be developed and is vital in ensuring a finished product that satisfies all your requirements. A detailed specification may include flowcharts, database designs, screen designs and detailed descriptions on what the program does, etc. The specification would also include a detailed pricing. It could involve a wide variety of people, for example, project manager, business client, system analyst, graphic designer, programmer, user, etc. The documents should be submitted to the Project Portfolio Office at project_portfolio@qut.edu.au for AMP (IT) projects.
Feasibility Study Request The Project Proposal template may be used to request funding to conduct a Feasibility Study, used to provide an analysis of the objectives, requirements, and concepts of the proposed work, including justification, schedule, and deliverables. Its main purpose it to determine the technical and financial viability of a proposed change as well as to assist in identifying or clarifying activities, cost, timeframes and/or requirements (system and/or business). During the analysis, the objectives of the proposed work are defined based on the needs identified. Depending on the project, the Feasibility Study may be Stage 1 of a large project. The Feasibility Study may also be used to conduct a preliminary part of project where it is unclear how to quantify the resources or if the product/system/process to be implemented needs to be identified before progressing to complete a Project Proposal. See Approval Workflow Diagrams in Part A of this Guide. The outcomes of the study must be considered and planned for. This means that the Feasibility Study Report requirements should kept in mind at all times during the Planning Phase and throughout the life of the study. The output from the Feasibility Study is a report detailing the methodology used, the evaluation criteria, the study findings and recommendations. Once the study is completed a Feasibility Study Report is required as the outcome for the work undertaken. If the study recommends continuing with the project idea then a Project Proposal for a new project should be completed and submitted either with the Feasibility Study Report or soon after. PMF_GUIDE_V4.2 CRICOS INSTITUTION CODE 00213J
PAGE 11
8 JANUARY 2008
PROJECT MANAGEMENT FRAMEWORK GUIDE
The documents should be submitted to the governing authorities for approval, then to the Project Portfolio Office at project_portfolio@qut.edu.au for AMP (IT) projects.
Feasibility Study Report The Feasibility Study Report template is used to provide information about the outcomes and success of a feasibility study. The report should include details on methodology used, the evaluation criteria, options analysed with findings and recommendations resulting from the study. Supporting documentation may be included as appendices. The report recommendations may support proceeding with a project or project stage as a result of the study. In this case the Project Proposal should be prepared. Both documents should be submitted to the governing authorities for approval, then to the Project Portfolio Office at project_portfolio@qut.edu.au for AMP (IT) projects.
Streamlining with a Project Proposal into the Executing Phase The governing authority, which is the DVC (TILS) for AMP (IT) projects, may approve a comprehensive and complete Project Proposal as a Project Plan for progression to the Executing phase for small, straightforward projects with limited scope. The proposer may indicate the intention when submitting such a Project Proposal. Where requirements for such a project indicate, additional information or documents may be required. Project managers should check the categories in the Project Plan template and add them into the Proposal/Plan as needed for the project. For example, a separate Communication Plan may be called for because of widespread impacts of the project.
13 PLANNING PHASE Definition: defining and refining objectives. This phase requires completion of a Project Plan. A Work Breakdown Structure and sub-plans are part of the Project Plan. The sub-plans may be incorporated into the main Project Plan or may be separate, depending on the scope and value of the project: •
Work Breakdown Structure diagram or Gantt chart
•
Risk Management Plan
•
Quality Plan
•
Communication Plan
The Project Plan is a dynamic document that supplies an integrated suite of information to coordinate, run and control the project. The level of detail depends on the size of the project and impacts outside the local area. The project manager should always bear in mind that an overly long plan may contain so much detail that the documentation will never be read. An important consideration is to use the PMF templates to ensure that the University has a consistent approach. The project manager will practise a wide range of skills, including technical, communications, human resource and political to prepare the plan. Best practice stipulates that the project manger should interact with key stakeholders to set up the plan, thereby ensuring that the plan is well thought out, understood and
PMF_GUIDE_V4.2 CRICOS INSTITUTION CODE 00213J
PAGE 12
8 JANUARY 2008
PROJECT MANAGEMENT FRAMEWORK GUIDE
capable of being executed. A high degree of involvement of the project team is desirable. Finally, all should note that projects are dynamic and will change as they run their course. The project manager should produce the best Project Plan possible, but the stakeholders should be aware that changes will take place and plans will be modified accordingly. Appropriate stakeholders should be kept informed of any changes to the plans. The Project Plan and its associated documents should be approved by the steering committee, then considered by the governing authority for final approval. For AMP (IT) projects a Project Plan approved by the steering committee should be sent to the Project Portfolio Office at project_portfolio@qut.edu.au for PMF compliance and for DVC (TILS) consideration and approval.
Project Plan The Project Plan is a document that describes and brings together the components of a project. In effect, the Project Plan is the guidebook for all to the project. All aspects of the project should be covered, although the level of detail depends on the size of the project. Detailed project specifications are outside the PMF. The Systems Development Framework is complementary to the PMF for development projects and may be found on the Project Portfolio web site.
Work Breakdown Structure A Work Breakdown Structure diagram is necessary. The Work Breakdown Structure (WBS) is a foundation document in project management and all projects should contain at least a high level WBS that shows the main project products or phases with the main tasks. Then, the WBS can provide the basis for planning and managing the key areas of the project. Risks and costs may be referenced against the WBS, as well as time frames and milestones. MS Project is recommended as a support tool to develop a high level work breakdown structure. Project plans for larger projects should develop multi-level WBSs. The extent depends on the size of the project. Very large projects may have as many as five levels in the WBS, rarely more, because each level requires the corresponding amount of extra work. Adding a level to a WBS increases workload, as each activity in each level must be tracked and recorded. A graphical representation of the work breakdown structure can be used in reports to management and steering committees as a visual means of showing the status of the project.
Risk Management Plan QUT’s Risk Management Policy is available in the University’s Manual of Policy and Procedures (MOPP A/2.5). A separate risk management plan is required for all but very small or limited scope projects, using the PMF Risk Management Plan (RMP) template. Small or limited scope projects may use the RMP template or embed a limited risk table in the Project Plan, as judged by the project manager and governing authorities. It should be noted that the risks identified in the template are IT generic and must be reviewed, augmented and updated to fit all risks specific to the project.
PMF_GUIDE_V4.2 CRICOS INSTITUTION CODE 00213J
PAGE 13
8 JANUARY 2008
PROJECT MANAGEMENT FRAMEWORK GUIDE
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 in the Finance and Resource Planning web pages. 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.
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.
PMF_GUIDE_V4.2 CRICOS INSTITUTION CODE 00213J
PAGE 14
8 JANUARY 2008
PROJECT MANAGEMENT FRAMEWORK GUIDE
Communication Plan Communication strategies to address stakeholders previously identified in the Project Proposal and any new stakeholders subsequently determined must be formed. A separate communication plan may be provided, using the Communication Plan template, as appropriate. The template comprises tables for training strategies, and marketing and communication strategies. A well-developed and comprehensive Communication Plan using both tables meets the change management needs for most projects. Keep in mind that managing change is required in all projects to some degree because change is embedded in all projects. In fact communication is a critical component of every project plan because it provides the vital link between the project, the client and success. When developing a communication plan it is essential to answer the following questions: Who will be impacted by this project? What type of change does this project represent, is it only going to affect one department, or the entire university? When is this change scheduled to occur? Where will this change occur, and finally how will those impacted by this change be notified? By answering these questions it will help you to identify the most appropriate target audience to be communicating with and this will in turn determine the most effective communication mechanisms you need to use in order to convey your message. A communication plan is not static, but rather will develop as the project progresses therefore it is imperative to continually revisit the communication plan and update it as needed. Project managers should contact their Marketing and/or Communications Officers if available for advice on communication requirements for the project. Within the ITS Department Client Relations Managers must be consulted and for all AMP (IT) projects it is recommended that the ITS Client Relations Managers be consulted. The ITS Learning and Development Unit has a cost-recovered service and may also be consulted on course development and delivery. See the Marketing and Communication Checklist and Training Checklist in Appendix C. If the project involves workflow changes, HR must be contacted. See the section on Additional Areas for Consideration in Part A of this guide for information on HR Change Management.
14 EXECUTING PHASE Definition: coordinating people and other resources to carry out the plan Project plan execution involves implementing the plan by performing the activities in the plan. The project manager must integrate related areas of the project into a harmonious whole often by using a variety of techniques to engage with stakeholders. External factors may exert an influence and need to be taken into account. The project manager will again use a wide range of skills, including technical, financial, communications, human resource and political. The aim is to focus on pulling all activities and aspects of the project together to achieve a successful end. Changes and variances that occur to the plan during implementation feed into the controlling phase of the project, which overlaps all phases of the project. Project Change Requests are described in the section the Controlling Phase, below. The project manager will conduct regular project team meetings to discuss progress on activities, project issues and keep track of developments. The project may have a reference group to ensure an appropriately wide range of issues are considered.
PMF_GUIDE_V4.2 CRICOS INSTITUTION CODE 00213J
PAGE 15
8 JANUARY 2008
PROJECT MANAGEMENT FRAMEWORK GUIDE
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.
PMF_GUIDE_V4.2 CRICOS INSTITUTION CODE 00213J
PAGE 16
8 JANUARY 2008
PROJECT MANAGEMENT FRAMEWORK GUIDE
Project Status Report Projects are dynamic. The Project Status Report indicates the areas of a project that may vary as the project proceeds: integration, scope, time, cost, quality and risk. Decisions may then have to be made to adjust the other areas to compensate. If the schedule slips, then resources may be increased to bring the project back on schedule to meet a critical deadline. An increasing focus of attention in the report is risk management with review of project risks in each report. Changes in or new risks may explain the need for variation in the project. The Project Status Report is a tool for reporting on progress of the project suitable for inclusion as a standing agenda item at steering committee meetings. The report has a visual aspect that is valuable for a quick examination of the status of the main project areas. All Project Status Reports should be copied to the Project Portfolio Office through email: project_portfolio@qut.edu.au in order to meet Project Registry reporting requirements.
Project Change Requests The project manager should use the Project Change Request to request a significant change in the key project areas. The steering committee has authority must approve all changes. Requests for significant changes, for example, any requests for additional funding, must be submitted to the governing authority for final consideration for approval. For AMP (IT) projects, Project Change Requests approved by steering committees should be sent to the Project Portfolio Office through email: project_portfolio@qut.edu.au for consideration by the DVC (TILS).
Integrated Change Control The Project Manager must have a holistic view of key areas of the project with a view to recognising changes in those areas, how the changes impact on other key areas and mitigation strategies. The project manager must also be aware of how the project fits in with other QUT business activities, systems and projects and be prepared to take action or raise awareness if problems arise on this front. The steering committee must be alerted if change is significant, whether internal or external.
Scope Change Control The Project Manager should have worked closely with stakeholders so that the Project Plan clearly defined the scope of the project, but a need for a scope change may arise. The project manager should consider the request for change in scope and make a formal submission to the steering committee with the Project Change Request, which delineates the changes requested, impact on the project completion date, resource requirements, risk versus returns, etc, and a recommendation for approval. Significant scope change and scope creep (numerous small changes) are a major cause of project failure. The project manager is responsible for managing the change, ensuring that the steering committee is aware of the change in scope, the impacts of the change so that they make informed decisions.
PMF_GUIDE_V4.2 CRICOS INSTITUTION CODE 00213J
PAGE 17
8 JANUARY 2008
PROJECT MANAGEMENT FRAMEWORK GUIDE
Time Control Finishing a project on time is a customary measure of whether a project has been successful, but many factors may cause a project timeline to change. The Project Plan should have built in contingencies (not necessarily financial). Regular meetings with stakeholders and project team members are an important means of checking the schedule. The project manager should be highly aware of project progress with respect to time and inform the steering committee accordingly. Steering committee members need a visual overview of project schedule progress, for example, a table of milestones for smaller projects and an MS Project Gantt chart with larger projects. If serious problems occur, the project manager must work with the steering committee to resolve the issues. An alternative is to kill the project.
Cost Control Comparing the actual project cost against the original planned cost is a customary method of determining whether a project has been successful. As with other elements of a project, costs are subject to change. MS Project is the recommended support tool to track control costs for projects of sufficient complexity. All project costs should be recorded against the project and reported to the steering committee. The project manager’s responsibility is to ensure accurate reporting and suggested remediation so that the steering committee has all the information needed to act correctly. The steering committee must approve and authorise significant changes to the budget or kill the project.
Quality Control The Project Plan should have both quality assurance and quality control measures in place. Quality assurance evaluates the overall project performance to ensure that the end products meet the project standards. Quality control means monitoring and testing the project products using the chosen quality assurance tactics. Small quality faults can be dealt with operationally, but the steering committee must be promptly informed if quality problems are major. Significant changes to other areas of a project may need to take place to remedy the quality. One choice may be to kill the project.
Risk Risk management control is critical to the success of a project. Risks will definitely change as the project progresses. Risks unidentified at the time of the creation of the original Project Plan may appear, as well as new risks. As these risks change and other risks present themselves, the project manager should manage the situation, modify the Risk Management Plan and draw attention through the Review of Risks in the Project Status Report to the steering committee.
Communication As with other key project areas, communications requirements are likely to change. These changes may occur as a result of modifications in the other areas of the Project Plan. For example, regular stakeholder meetings to discuss project issues may determine that the project product uptake may be higher than originally foreseen because the product is seen to be worthwhile, so that communication updates must be at a broader level than originally noted in the PMF_GUIDE_V4.2 CRICOS INSTITUTION CODE 00213J
PAGE 18
8 JANUARY 2008
PROJECT MANAGEMENT FRAMEWORK GUIDE
Project Plan or separate Communication Plan. A need for training may be identified in the meetings and must be written into the Plan. A sometimes overlooked is the inclusion of a factor to account for communication if setbacks occur during implementation.
16 CLOSING PHASE Definition: formalising acceptance of the project, bringing it to an orderly end and reviewing This phase provides the opportunity for the organisation to learn from the work done via a review and analysis of metrics. The forms for the closing phase: •
Project Activity Completion Report – required for all projects
•
Post Implementation Review Report – required for major projects and for other projects if requested by the DVC (TILS).
Project Closure The project manager should carry out a controlled close to the project, irrespective of whether the project was completed or ended early. Ongoing work should be assigned to other staff, as appropriate. Project documentation should be completed. A Project Activity Completion Report should be completed for all projects and sent to the Primary Sponsor and copied to the Project Portfolio Office through email: project_portfolio@qut.edu.au The Primary Sponsor is responsible for any resulting actions with consideration and response to recommendations, as well as promulgating lessons learned, as appropriate.
Post Implementation Review All major projects require a PIR after completion. The DVC (TILS) may request a PIR for any other project, for example, if more information is needed than detailed in the Project Activity Completion Report. The sponsor should make arrangements for the Post Implementation Review (PIR) when the project closes, as required. •
Recommended composition of PIR team for a major project (>$250,000): o o o o
•
Chair (Not usually the project manager) 1 steering committee member 1 independent member from the client area 1 project team member
Composition of a typical PIR team for a minor project: o o
Project manager as organiser and leader 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.
PMF_GUIDE_V4.2 CRICOS INSTITUTION CODE 00213J
PAGE 19
8 JANUARY 2008
PROJECT MANAGEMENT FRAMEWORK GUIDE
The review should evaluate the way the project was run and assess whether the projected benefits have materialised or will be realised in future. The review should identify the highlights and good practices adopted during the project and contain an evaluation/appraisal of events that occurred, lessons learned and pitfalls to be avoided in future. The project manager, steering committee members and designated stakeholders should have input to the review. Supporting documentation should be supplied, depending on the size of the project. The report and other resulting documentation should be presented to the Primary Sponsor. A copy should be sent to the Project Portfolio Office (email: project_portfolio@qut.edu.au). The Project Portfolio Office will make the appropriate governing bodies aware of the reports, ITGC for major projects and DVC (TILS) for minor projects. The Primary Sponsor is responsible for any resulting actions with consideration and response to recommendations, as well as promulgating lessons learned, as appropriate. For AMP (IT) projects the report will be accessible to all through a link from the Project Registry so that the knowledge gained during the project can be reused and taken into consideration when planning and executing other projects. Additionally the project manager for AMP (IT) projects may talk to the report at project management improvement sessions, covering lessons learned and recommendations from projects.
17 FUTURE OF THE PMF The ongoing development of the PMF is an iterative process, with annual reviews. The PMF will evolve to meet the increasing demands and complexities of project management at QUT, always following best practice and drawing upon the experiences of project managers and governance authorities at QUT.
PMF_GUIDE_V4.2 CRICOS INSTITUTION CODE 00213J
PAGE 20
8 JANUARY 2008
PROJECT MANAGEMENT FRAMEWORK GUIDE
18 APPENDIX A – PROJECT REGISTRY An example of the Project Registry:
I
Initiating
P
G
No changes or issues
Gr
No report submitted
Planning
Y
Potential changes or issues
W
Project closed
E
Executing/Controlling
R
Changes or issues have arisen
P
Project halted
C
Closing
Communication
Scope
Resources
Risks
Overall Project
Example links to project status report document
E
Y
Y
G
R
R
G
Y
Example links to project status report document
P
G
Y
G
G
Y
G
G
Example links to project status report document
E
R
G
G
G
R
G
Y
Example links to ACR or PIR as appropriate
C
W
W
W
W
W
W
W
Example links to most recent project status report
E
P
P
P
P
P
P
P
Example links to project status report document
I
G
G
G
G
G
G
G
Example links to most recent project status report or documentation
I
Gr
Gr
Gr
Gr
Gr
Gr
Gr
Phase
Project Name (A-Z) AMP (IT) Funded Non AMP (IT) funded
PMF_GUIDE_V4.2 CRICOS INSTITUTION CODE 00213J
PAGE 21
Report Date
Budget
Key
Timeline
Phase
8 JANUARY 2008
PROJECT MANAGEMENT FRAMEWORK GUIDE
19 APPENDIX B – KEY PLAYERS IN A QUT PROJECT Projects have sponsors, steering committees, client champions and project managers. Internal Audit may become involved. Projects may have reference teams, as required.
Primary Sponsor responsibilities •
Be chief champion of the project
•
Have accountability for the project and ongoing accountability for the outcomes
•
Chair the project steering committee
•
Advocate the project internally and externally
•
Facilitate and support policy and funding recommendations
•
Provide overview and direction for the project
•
Resolve issues identified by the project manager when requested (and agreed)
•
Support the project manager in carrying out the project
•
Monitor the project budget
•
Monitor project risk
•
Ensure that deliberations of the project are adequately recorded and available to appropriate parties
Client Leader The client leader should come from outside the project area to ensure objectivity. •
Participate as a member of the steering committee
•
Provide business leadership and guidance to the project
•
Assist the Primary Sponsor in championing the project
Steering Committee responsibilities •
Direct attention to the project at a strategic level
•
Make strategic decisions where required
•
Approve or kill the Project Plan
•
Make decisions on whether to approve requested changes in the Project Plan or kill or halt the project while the project is executing
•
Ensure that the DVC (TILS) and ITGC are advised of significant project issues through the Project Portfolio Office
•
Provide guidance to the project manager
•
Review project progress and issues with the project manager regularly
•
Monitor the project budget: a key factor
•
Monitor the project risk: a key factor that is increasingly important
•
Resolve policy issues
•
Escalate issues where required
Deputy Vice-Chancellor (TILS) – or nominee The DVC (TILS) will indicate membership or designate a nominee. •
Participate as a member of the steering committee
•
Ensure that communications and considerations of issues between the project and project governance structure take place
PMF_GUIDE_V4.2 CRICOS INSTITUTION CODE 00213J
PAGE 22
8 JANUARY 2008
PROJECT MANAGEMENT FRAMEWORK GUIDE
•
Contribute to identification and resolution of interdependent integration issues
•
Ensure that client needs are addressed to satisfaction in the project
Expert/Specialist responsibilities For small projects, the expert/specialist may be the project manager and, therefore, a full member of the steering committee. •
Provide technical expertise
Internal Audit responsibilities Internal Audit should always be asked at whether they wish to provide a representative. •
Undertake an observer role on the project steering committees with rights of audience and debate
•
Provide advice on internal controls, including computer system security
•
Provide advice on the application of project management principles
Project manager responsibilities •
Manage the project taking into account integration across all areas
•
Engage with stakeholders
•
Develop Project Plan
•
Direct project resources
•
Monitor and manage the project schedule
•
Monitor and manage the project budget
•
Monitor and manage the project risk
•
Deal with operational issues
•
Organise steering committee meetings, including ensuring that minutes will be taken
•
Report to the steering committee, raising strategic issues
•
Prepare Project Status Reports and Project Change Requests for the steering committee
•
Ensure project meets requirements and objectives
•
Manage project team members
•
Negotiate and resolve issues as they arise across areas of the project and where they impact on other QUT activities, systems and projects
•
Look after the interests of the project team
•
Organise and chair project reference group meetings, as appropriate
•
Communicate project status to project sponsor, all team members, and other relevant stakeholders and involved parties
•
Maintain project documentation
Project Reference Group A group of stakeholders brought together to discuss and deal with operational issues for the project. Members may be part of the main project team, but, also, clients/users from areas across the University that will be impacted by the outcomes of the projects. Reference group members should: •
Bring operational issues from their areas to the reference group meetings
•
Look for collaborative solutions
PMF_GUIDE_V4.2 CRICOS INSTITUTION CODE 00213J
PAGE 23
8 JANUARY 2008
PROJECT MANAGEMENT FRAMEWORK GUIDE
•
Disseminate needed information and actions resulting from the reference group meetings to their areas
•
Act as a team for the sake of the project
PMF_GUIDE_V4.2 CRICOS INSTITUTION CODE 00213J
PAGE 24
8 JANUARY 2008
PROJECT MANAGEMENT FRAMEWORK GUIDE
20 APPENDIX C – COMMUNICATION PLAN CHECKLISTS The following checklists will assist in drawing up a stakeholder Communication Plan that includes training. All stakeholders must be considered. Marketing and/or Communications Officers in faculties and divisions should be consulted if available. Within the ITS Department Client Relations Managers must be consulted and for all AMP (IT) projects it is recommended that the ITS Client Relations Managers be consulted. The ITS Learning and Development Unit has a cost-recovered service and may also be consulted. In the tables below, the consultant is labelled “the expert”.
Marketing and Communication Checklist Communication and marketing aspects to be taken into consideration for a project. Use the items in the checklist as appropriate:
Y/N
Points for Marketing and Communication Consultation with the expert at Project Proposal stage Consultation with the expert at Project Plan stage Assessment of risks (for example, messages about unforeseen problems with project implementation) Realistic time frame for development and delivery of marketing and communication elements (for example, brochures) Allocation of budget for marketing and communication (for example, costs of design and printing) Designation of project manager or team member to be accountable for ensuring the quality of the information (for example, right time, format and audience) Agreement of marketing and communication strategies/actions by the expert
Training Checklist Training aspects to be taken into consideration for a project. Use the items in the checklist as appropriate:
Y/N
Points for Training Consultation with the expert at Project Proposal stage Consultation with the expert at Project Plan stage Assessment of risks (for example, more training required than estimated) Realistic time frame for development and delivery of training materials Attention given to type of training and supporting materials Decisions on who will develop training materials and who will do the training (for example, QUT staff or external) Consideration of ongoing training needs and support Allocation of budget for training (for example, development of course) Designation of stakeholder to be accountable for ensuring the quality of the training from the clients’ or business point of view Agreement of marketing and communication strategies/actions/budget by the expert A more extensive checklist that can be generally applied to projects is available from ITS Learning and Development: http://www.its.qut.edu.au/training/checklist.pdf
PMF_GUIDE_V4.2 CRICOS INSTITUTION CODE 00213J
PAGE 25
8 JANUARY 2008
NOTIFICATION FORM NAME OF PROJECT
Project Notification Form Project Notification Form is a brief document advising of the intent to develop a project. The funding authority provides advice to either proceed with a project proposal or to liaise with other project managers/project proposers to consider obvious intersections with the work proposed. See the Approval Workflow Diagrams in The Project Selection Process in Part A of the PMF Guide for clarification of the process For potential AMP (IT) projects, the Notification Form should be sent to the Project Portfolio Office at project_portfolio@qut.edu.au for prioritisation. See the example of a completed Project Notification Form. Guidance boxes like this are displayed in MS Word Print View (not in Normal View). They should be deleted when you have finished with the contents: position the cursor on the border, left click when a cross appears and press delete.
1 PROJECT INFORMATION Project Number (if applicable): Project Name: A brief name to describe the project Date: Of project notification Project Ownership: Area responsible for project Project Contacts: Name
Position
Phone
Primary Other Other
Project Approval: Authority for project funding (example, Information Technology Governance Committee through AMP (IT) budget)
2 OBJECTIVES The aims of the project: the compelling reason(s) for carrying out the project and the overall outcomes. These outcomes should be clearly defined and may include a justification or consequences of not proceeding. Type in your project information below, then delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
3 SCOPE
PMFNotificationFormV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
PAGE 1
NOTIFICATION FORM NAME OF PROJECT
The activities and tasks contained in the project, showing the boundaries of the project. This section may include the activities outside the scope. 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 INTERDEPENDENCY WITH OTHER SYSTEMS AND INFRASTRUCTURE A statement on impacts of the outcome of the project on other systems and QUT infrastructure, as well as impacts of other key systems and QUT infrastructure on the project, if applicable. Projects must integrate with QUT business dates, with existing services and systems and with each other. 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
6 TIMING & DURATION 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.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
PAGE 2
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). Approval of the Project Proposal by the funding authority, for example, ITGC with 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.
Project Number (if applicable): Project Name: A brief name to describe the project Date: Of submission of the proposal Project Ownership: Area responsible for project Project Contacts: Name
Position
Phone
Primary Other Other
Project Approval: Authority for project funding (example, Information Technology Governance Committee through the AMP (IT) budget)
2 VERSION CONTROL Add new rows to the table that follows as necessary. PMFProjectProposaLV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
PAGE 1
PROJECT PROPOSAL NAME OF PROJECT
Version Number
Date
Reason/Comments/Approvals
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
5 SCOPE, CONSTRAINTS, ASSUMPTIONS 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.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
PAGE 2
PROJECT PROPOSAL NAME OF PROJECT
Constraints
Assumptions
6 INTERDEPENDENCIES WITH BUSINESS ACTIVITIES, SYSTEMS AND OTHER PROJECTS A listing of major interdependencies and possible impacts to draw attention to QUT integration issues in the complex university environment. To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
Interdependent Activity
PMFProjectProposaLV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
Possible Impact
PAGE 3
PROJECT PROPOSAL NAME OF PROJECT
7 BUSINESS CASE: COST/EFFECTIVENESS ANALYSIS The proposal should present the approving authority with firm business reasons for carrying out a prospective project. The business case shows the benefits and added value of the project for the business area and to QUT. Clear strategic alignment and financial benefits are increasingly required. List only those benefits contained within the scope of the project. Guidelines for benefits: 1) A method for measuring the improvement or value should accompany each benefit. The monitoring and measuring will take place throughout the life of the system or service, long after the project and its Post Implementation Review are completed. 3) During the project the project team should establish baselines for measurements that continue into the operational phase for comparison. 2) Details on the method of measurement after the project ends should be handed over to the service or product owner at the time of transition from project status to operational. 4) Quick wins during the project and immediately after should also be identified if possible. Strategic Alignment: Use the QUT Blueprint and top-level plans located through the FRP web page to demonstrate the value of implementing the project, for example, improves research outcomes by ‌‌.. Financial Benefits: Include the measure of determining savings or increase in revenue. How to use standard techniques like Return On Investment and Net Present Value are easily available on the Internet and in textbooks, if required. To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
Benefits
How to Measure
Strategic alignment with QUT Blueprint & University Plans
Financial: quantitative, for example, saves money, increases revenue
Other, for example, legislative compliance, infrastructure refresh, local benefit
Impact of NOT proceeding
PMFProjectProposaLV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
How to Measure
PAGE 4
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.
Stakeholder
Interest in Project
9 SIGNIFICANT RISKS The major risks to the project and treatment strategies, including mitigation. The probability and impact ratings cover the risks. To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
Major Risk
Probability:
Impact:
H, M, L
H, M, L
PMFProjectProposaLV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
Risk Treatment
PAGE 5
PROJECT PROPOSAL NAME OF PROJECT
10 COSTS AND RESOURCES The proposal should provide an overview of the project costs and resources in the table below, which aligns with Oracle Financials reporting. Overview: Projects should be broken out into logical “chunks” or stages. Funding may be reserved for multiple stages or for a single stage with new submissions for later stages as the project progresses. If alternative approaches to the project are possible, break out into Option 1 and Option 2 (or more) with a recommendation on the choice to make. (Delete option table if unused.) Salaries: These should be calculated using the HR Salary Scales - Professional Staff table and the Costing Schedule from FRP. 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, removing the staff development allowance from a short 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.
10.1 Costs and resources during the life of the project:
#
Category
Details
Length of Time
Funding Source
(as applicable)
(eg, Op Grant or AMP (IT))
Amount
Recommended Option 1 Salaries
PMFProjectProposaLV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
PAGE 6
PROJECT PROPOSAL NAME OF PROJECT
#
Category
Details
Length of Time
Funding Source
(as applicable)
(eg, Op Grant or AMP (IT))
Amount
Non-Capitalised Expenditure, including Hardware <$5K and Software <$100K
Travel & Related Staff Development & Training
Other, Including General Consumables, Printing and Stationery, Telecommunications, Consultancy and Contractors
Capitalised Expenditure, including Hardware >$5K, Software >$100K
Grand total (all costs) Total from Operating Grant Total from other funding (eg, faculties, carry forwards) Total project funds requested, (eg, from AMP (IT)) Year(s) to receive above requested funding (eg If total requested = $100K, then, 2008: $40K, 2009: $60K)
Year 1 – 200x: amount Year 2 – 200x: amount
#
Category
Details
Length of Time
Funding Source
(as applicable)
(eg, Op Grant or AMP (IT))
Amount
Option 2 Salaries
PMFProjectProposaLV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
PAGE 7
PROJECT PROPOSAL NAME OF PROJECT
#
Category
Details
Length of Time
Funding Source
(as applicable)
(eg, Op Grant or AMP (IT))
Amount
Non-Capitalised Expenditure, including Hardware <$5K and Software <$100K
Travel & Related Staff Development & Training
Other, Including General Consumables, Printing and Stationery, Telecommunications, Consultancy and Contractors
Capitalised Expenditure, including Hardware >$5K, Software >$100K and Developing Software
Grand total (all costs) Total from Operating Grant Total from other funding (eg, faculties, carry forwards) Total project funds requested, (eg, from AMP (IT)) Year(s) to receive above requested funding (eg If total requested = $100K, then, 2008: $40K, 2009: $60K)
Year 1 – 200x: amount Year 2 – 200x: amount
10.2 Basis for estimated project costs An explanation of the basis of estimated costs above. Type in your project information below, then delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
10.3 Ongoing costs after project completes:
PMFProjectProposaLV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
PAGE 8
PROJECT PROPOSAL NAME OF PROJECT
Break out into Option 1 and Option 2 if appropriate. To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
Ongoing Support & Maintenance
Detail
Funding Source after Project Ends
Annual Amount
Name of Delegate of Funding Source Who Agreed
Salaries
Equipment
Software
Other
Annual Total
10.4 Basis for estimated ongoing costs
An explanation of the basis of estimated costs above. Type in your project information below, then delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
10.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.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
PAGE 9
PROJECT PROPOSAL NAME OF PROJECT
11 SPONSOR, PROJECT MANAGER, STEERING COMMITTEE The proposal should name the individuals who will be of key importance to the success of the project and indicate their stake in the project. All should be chosen carefully because of their future impact on the project and should understand their roles and obligations. The sponsor or appointed delegate should Chair the steering committee. The project manager may not yet have been appointed. For a small project or feasibility study, a scaled down authoritative body or simply the project owner may be appropriate. See Appendix B in the PMF Guide for details on the roles and responsibilities. To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
Project Role
Name
QUT Position
Interest in Project
Sponsor Client Leader Project Manager Expert/Specialist Steering Committee member DVC (TILS) or nominee Internal Audit representative
12 PROPOSED TIME FRAME The proposal should contain a time frame in a table with major milestones, with deliverables indicated specifically. The milestones will be at significant project times and can be used as indicators for reports, steering committee meetings and project kill points. Allow time for transition from project to operational with a handover to the service owner. An Activity Completion Report should be factored in, as well as a Post Implementation Review for a major project. To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
Activities, Milestones, Deliverables
PMFProjectProposaLV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
Time Frame
Kill/Milestone Date
PAGE 10
FEASIBILITY STUDY REPORT NAME OF PROJECT
Feasibility Study Report 1 PROJECT INFORMATION The Feasibility Study Report is used to supply information about the outcomes and success of a feasibility study. It should detail the methodology used, the evaluation criteria, the study findings and recommendations resulting from the study. A completed Feasibility Study Report should be sent to the Project Portfolio Office at project_portfolio@qut.edu.au upon approval by the steering committee or governing body. Where the Report recommends further project work, it should accompany a Project Proposal and be submitted to the Project Portfolio Office for approval by the funding authority, for example, ITGC with AMP (IT) projects. The PMF Guide also has additional information on Feasibility Studies and Feasibility Study Reports. Also see the example of a completed Feasibility Study Report. 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.
Project Number (if applicable): Project Name: A brief name to describe the project Date: Of submission of the proposal Project Ownership: Area responsible for project Project Contacts: Name
Position
Phone
Primary Other Other
Project Approval: Authority for project funding (example, Information Technology Governance Committee through the AMP (IT) budget)
2 VERSION CONTROL Add new rows to the table as necessary.
Version Number
Date
PMFFeasbilityStudyReportV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
Reason/Comments/Approvals
PAGE 1
FEASIBILITY STUDY REPORT NAME OF PROJECT
3 MANAGEMENT SUMMARY Provide an overview of the study including a concise history of events leading up to the study giving an explanation of why the study was required, the objectives of undertaking the study, the consultation processes used, the methodology used to undertake the study and the findings/recommendations from the study. Where the Report recommends further project work, it should accompany a modified version of the original Project Proposal and be submitted to the Project Proposal for approval by the funding authority, for example, ITGC with AMP (IT) 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.
PMFFeasbilityStudyReportV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
PAGE 2
FEASIBILITY STUDY REPORT NAME OF PROJECT
4 INTRODUCTION The aims and the purpose of study should be presented with clarity. References should also be made to relevant background, including current practices or issues, the objectives and proposed benefits in undertaking the study. 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 FEASIBILITY STUDY METHODOLOGY The activities and tasks contained in the study should be set out with details of any consultation processes, issues considered, and specific processes used that formed the overall methodology for evaluating the object of the study. It is very important in undertaking a Feasibility Study that the project proposer has consulted extensively with the stakeholders likely to be impacted by the planned changes. It is particularly important to ensure clear user requirements and agreement with the stakeholders when undertaking a feasibility study that involves RFI/RFP/RFO processes. To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
6 EVALUATION CRITERIA Identify the criteria applicable to the evaluation of the study that was used to determine the recommended outcome. Such criteria typically include costs, functionality, ease of use, implementation considerations, To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
7 OPTIONS ANALYSED The Report should present the options that were analysed as part of the feasibility study along with the advantages and disadvantages appropriate for each option. To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
PMFFeasbilityStudyReportV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
PAGE 3
FEASIBILITY STUDY REPORT NAME OF PROJECT
8
RECOMMENDATIONS
List the recommendations derived from your study. To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
PMFFeasbilityStudyReportV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
PAGE 4
Project Plan Name of project Prepared by “name of project manager” Name of area
Version number: Date of current plan:
PMF V4.2 CRICOS Institution Code 00213J
PROJECT PLAN NAME OF PROJECT
1 PROJECT PLAN DISTRIBUTION LIST The recipients of the project plan
Name
Position
Interest in Project
2 VERSION CONTROL Record changes to the project plan.
Version Number
Date
Reason/Comments/Approvals
PROJECT PLAN NAME OF PROJECT
3 MANAGEMENT SUMMARY The Management Summary should comprise a summing up of the information on the project that is most important to management: objectives, cost, time frame, key benefits and an outline of the milestones. The summary should usually be 1page or less in length, 2 pages at most, depending on the size of the project. Guidance boxes like this are displayed in MS Word Print View (not in Normal View). They should be deleted when you have finished with the contents: position the cursor on the border, left click when a cross appears and press delete.
3.1 Major Changes From Project Proposal If significant changes are required from the Project Proposal, use the table below to indicate changes needed across the specific key project areas and the adjustments within each area to accommodate the requested changes. If no significant changes have taken place, delete 3.1 and 3.2. To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
Category
Reason for Variance from Project Proposal
Proposed Changes (From Project Proposal)
Scope Time Cost Quality Risk Management Communications
3.2 Detailed Description and Justification for Project Changes Where required, a detailed description and justification for the project changes from which the Steering Committee and the governing authority (the DVC (TILS) for AMP (IT) projects) can make the decision whether or not to approve the changes. Type in your project information below, then delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
PROJECT PLAN NAME OF PROJECT
Table Of Contents Regenerate the Table of Contents as required. 1
PROJECT PLAN DISTRIBUTION LIST ..................................................................................... II
2
VERSION CONTROL ............................................................................................................ II
3
MANAGEMENT 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 ...................................................................................................................... 2
7
SCOPE, CONSTRAINTS, ASSUMPTIONS ............................................................................... 2
8
INTERDEPENDENCIES WITH BUSINESS ACTIVITIES, SYSTEMS AND OTHER PROJECTS ............ 3
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 MANAGEMENT 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.
Project Number (if applicable): Project Name: A brief name to describe the project Date: Date of current plan Project Ownership: Area responsible for project Project Contacts: Name
Position
Phone
Primary Other Other
Project Approval: Authority for project funding (example, Information Technology Governance Committee through the AMP (IT) budget)
5
INTRODUCTION AND BACKGROUND A commentary on the circumstances leading up to the need for and decision to fund the project. 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.
PMFPROJECTPLANV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
PAGE 1
PROJECT PLAN NAME OF PROJECT
6
OBJECTIVES 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.
7
SCOPE, CONSTRAINTS, ASSUMPTIONS The activities and tasks contained in the project, showing the boundaries of the project. This section should outline activities outside the project scope and any assumptions that the project is based on. Whoever is preparing the project proposal should make considerable efforts to establish the scope with the stakeholders. Scope verification and clear user requirements are important aspects to gain agreement with the stakeholders. The better the outcomes are defined, the less probability of dramatic scope changes or scope creep. Projects should be broken out into “chunks” or stages. Multi-year projects should show annual objectives. 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
Constraints
Assumptions
PMFPROJECTPLANV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
PAGE 2
PROJECT PLAN NAME OF PROJECT
8
INTERDEPENDENCIES WITH BUSINESS ACTIVITIES, SYSTEMS AND OTHER PROJECTS A table of interdependencies and possible impacts to draw attention to QUT integration issues in the complex University environment. To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
Interdependent Activity
9
Possible Impact
BUSINESS CASE AND BENEFITS REALISATION The plan should present the approving authority with firm business reasons for carrying out the project. The business case shows the benefits and added value of the project for the business area and to QUT. Clear strategic alignment and financial benefits are increasingly required. List only those benefits contained within the scope of the project. Guidelines for benefits: 1) A method for measuring the improvement or value should accompany each benefit. The monitoring and measuring will take place throughout the life of the system or service, long after the project and its Post Implementation Review are completed. 3) During the project the project team should establish baselines for measurements that continue into the operational phase for comparison. 2) Details on the method of measurement after the project ends should be handed over to the service or product owner at the time of transition from project status to operational. 4) Quick wins during the project and immediately after should also be identified if possible. Strategic Alignment: Use the QUT Blueprint and top-level plans located through the FRP web page to demonstrate the value of implementing the project, for example, improves research outcomes by â&#x20AC;Śâ&#x20AC;Ś.. Financial Benefits: Include the measure of determining savings or increase in revenue. How to use standard techniques like Return On Investment and Net Present Value are easily available on the Internet and in textbooks, if required. To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
Benefits
How to Measure
Strategic alignment with QUT Blueprint & University Plans
Financial: quantitative, for example, saves money, increases revenue
Other, for example, legislative compliance, infrastructure refresh, local benefit
PMFPROJECTPLANV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
PAGE 3
PROJECT PLAN NAME OF PROJECT
Benefits
How to Measure
10 WORK BREAKDOWN STRUCTURE (WBS) The WBS is a separate, foundation project document and may be a diagrammatic representation of the project activities. MS Project may also be used to prepare a WBS. Refer to the section on WBS in the PMF Guide. Indicate below where the WBS for this project can be found. 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.
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.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
PAGE 4
PROJECT PLAN NAME OF PROJECT
12 COSTS AND RESOURCES The proposal should provide an overview of the project costs and resources in the table below, which aligns with Oracle Financials reporting. Overview: Projects should be broken out into logical “chunks” or stages. Funding may be reserved for multiple stages or for a single stage with new submissions for later stages as the project progresses. If alternative approaches to the project are possible, break out into Option 1 and Option 2 (or more) with a recommendation on the choice to make. (Delete option table if unused.) Salaries: These should be calculated using the HR Salary Scales - Professional Staff table and the Costing Schedule from FRP. 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, removing the staff development allowance from a short 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.
12.1 Costs and resources during the life of the project
#
Category
Details
Length of Time
Funding Source
(as applicable)
(eg, Op Grant or AMP (IT))
Amount
Recommended Option 1 Salaries
PMFPROJECTPLANV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
PAGE 5
PROJECT PLAN NAME OF PROJECT
#
Category
Details
Length of Time
Funding Source
(as applicable)
(eg, Op Grant or AMP (IT))
Amount
Non-Capitalised Expenditure, including Hardware <$5K and Software <$100K
Travel & Related Staff Development & Training
Other, Including General Consumables, Printing and Stationery, Telecommunications, Consultancy and Contractors
Capitalised Expenditure, including Hardware >$5K, Software >$100K
Grand total (all costs) Total from Operating Grant Total from other funding (eg, faculties, carry forwards) Total project funds requested, (eg, from AMP (IT)) Year(s) to receive above requested funding (eg If total requested = $100K, then, 2008: $40K, 2009: $60K)
Year 1 – 200x: amount Year 2 – 200x: amount
12.2 Basis for estimated project costs An explanation of the basis of estimated costs above. Type in your project information below, then delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
PMFPROJECTPLANV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
PAGE 6
PROJECT PLAN NAME OF PROJECT
12.3 Ongoing costs after project completes
Ongoing Maintenance
Detail
Funding Source after Project Ends
Annual Amount
Name of Delegate of Funding Source Who Agreed
Salaries
Equipment
Software
Other
Total
12.4 Basis for estimated ongoing costs An explanation of the basis of estimated costs above. Type in your project information below, then delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
13 TIMELINES The project plan should detail timing with milestones for implementation of the projectâ&#x20AC;&#x2122;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.
Activity or Deliverable
PMFPROJECTPLANV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
Timeframe
Kill/Milestone Date
PAGE 7
PROJECT PLAN NAME OF PROJECT
Activity or Deliverable
Timeframe
Kill/Milestone Date
14 QUALITY This section deals with strategies for ensuring high quality for the project As a minimum, the Project Plan should include the quality measures and acceptance criteria to be used or a separate Quality Plan may be produced, as described in the PMF Guide using the Quality Plan form. If a separate Quality Plan is produced, indicate below where the plan can be found To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
15 PROJECT MANAGEMENT STRUCTURE The Project Plan should list the names of the sponsor, steering committee members and project manager. These key project members must understand their duties and responsibilities for a project to be successful. The standard duties and responsibilities of the sponsor, steering committee members and project manager are detailed in Appendix B of the PMF Guide. The project plan lists customised changes or extra duties from the standard roles and responsibilities. General guidelines are that the steering committee should work at a strategic level, while the project manager deals with operational matters and reports to the steering committee on project progress, including strategic issues. An operational reference group may be included in the project structure. To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
Name
QUT Position
Interest in Project
Project Role Sponsor Client Leader Project Manager Expert/Specialist Steering Committee member (general) DVC (TILS) or nominee PMFPROJECTPLANV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
PAGE 8
PROJECT PLAN NAME OF PROJECT
Name
QUT Position
Interest in Project
Project Role Internal Audit representative
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 should be addressed. A checklist is provided in Appendix C of the PMF Guide. 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â&#x20AC;&#x2122;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.
Stakeholder
Communication Strategy
Training Strategy
Group
.
PMFPROJECTPLANV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
PAGE 9
RISK MANAGEMENT PLAN NAME OF PROJECT
Risk Management Plan A separate Risk Management Plan (RMP) is required for all but very small or limited scope projects to identify project risks. The RMP shows the elements of risk to a project and is a dynamic document. The plan should be reviewed and revised throughout the life of project. High risks, otherwise notable risks and changes in risks should be included by copying them into the project Status Reports. See the example of a completed Risk Management Plan. Guidance boxes like this are displayed in MS, left click when a cross appears and press delete.
1 PROJECT INFORMATION Project Number (if applicable): Project Name: The project name Date: Todayâ&#x20AC;&#x2122;s date Project Ownership: Area responsible for the project Prepared by: Name and project position Project Contacts: Name
Position
Phone
Primary Other Other
2 VERSION CONTROL/ RISK CHANGE LOG This table should be maintained as a complete log of changes in risk. The changes should be reflected in the main risk table as they occur. This log is a cumulative record of the changes in existing risks and new risks for the life of the project. See the example of a completed Risk Management Plan. Delete this box when you have finished with the contents: position the cursor on the border, left click when a cross appears and press delete.
Add new rows to the table as necessary. Version Number
Date
PMFRISKMANAGEMENTPLANV4.2 RISK_MANAGE_PLAN_TEMPLATE.DOC CRICOS INSTITUTION CODE 00213J
Description, Reasons, Comments Approvals
PAGE 1
RISK MANAGEMENT PLAN NAME OF PROJECT
3 RISK ASSESSMENT AND MANAGEMENT TABLE Risk management is already a significant consideration in project management at QUT and is gaining in importance. Refer to the QUT Risk Management Framework, as needed. The framework supplies valuable information on dealing with risks and producing a risk management plan. This table is IT-oriented, but can be adapted to fit the circumstances of individual projects, including non-IT projects. The project manager should retain the 6 category headings in the RMP 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. 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. To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
#
Risk
Description of Risk
Adequacy of Likelihood Existing Controls
Consequence Risk Rating
5 - Excellent • Probable 4 - Good • Improbable 3 - Fair 2 - Marginal 1 - Poor or Non-existent
• Major • Minor
Mini-table Probable M Improbable
1. Project Management Risks Inadequate project definition Availability of expert staff/resources
PMFRISKMANAGEMENTPLANV4.2 RISK_MANAGE_PLAN_TEMPLATE.DOC CRICOS INSTITUTION CODE 00213J
PAGE 2
H
L
M
Minor
Major
Risk Treatment
Residual Risk Rating
A – Avoid the risk L – Change the likelihood C – Change consequences S – Share the risk R – Retain the risk
H – High M – Medium L – Low 0 – None
Owner of Risk
RISK MANAGEMENT PLAN NAME OF PROJECT
#
Risk
Description of Risk
Adequacy of Likelihood Existing Controls
Consequence Risk Rating
5 - Excellent • Probable 4 - Good • Improbable 3 - Fair 2 - Marginal 1 - Poor or Non-existent
• Major • Minor
Mini-table Probable M Improbable
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 Breach of privacy Others 3. Resource Risks Staff turnover
PMFRISKMANAGEMENTPLANV4.2 RISK_MANAGE_PLAN_TEMPLATE.DOC CRICOS INSTITUTION CODE 00213J
PAGE 3
H
L
M
Minor
Major
Risk Treatment
Residual Risk Rating
A – Avoid the risk L – Change the likelihood C – Change consequences S – Share the risk R – Retain the risk
H – High M – Medium L – Low 0 – None
Owner of Risk
RISK MANAGEMENT PLAN NAME OF PROJECT
#
Risk
Description of Risk
Adequacy of Likelihood Existing Controls
Consequence Risk Rating
5 - Excellent • Probable 4 - Good • Improbable 3 - Fair 2 - Marginal 1 - Poor or Non-existent
• Major • Minor
Mini-table Probable M Improbable
Unclear roles and responsibilities Level of project team expertise Insufficient funding Others 4. Client Risks Inadequate business requirements Dissatisfaction with product in acceptance tests Training of clients/users Resistance to change
PMFRISKMANAGEMENTPLANV4.2 RISK_MANAGE_PLAN_TEMPLATE.DOC CRICOS INSTITUTION CODE 00213J
PAGE 4
H
L
M
Minor
Major
Risk Treatment
Residual Risk Rating
A – Avoid the risk L – Change the likelihood C – Change consequences S – Share the risk R – Retain the risk
H – High M – Medium L – Low 0 – None
Owner of Risk
RISK MANAGEMENT PLAN NAME OF PROJECT
#
Risk
Description of Risk
Adequacy of Likelihood Existing Controls
Consequence Risk Rating
5 - Excellent • Probable 4 - Good • Improbable 3 - Fair 2 - Marginal 1 - Poor or Non-existent
• Major • Minor
Mini-table Probable M Improbable
Others 5. Technical Risks Procurement issues, including tendering Hardware inadequate Software unavailable Technical problems Others 6. Other Risks Interdependencie s with other systems, etc Level of ongoing support
PMFRISKMANAGEMENTPLANV4.2 RISK_MANAGE_PLAN_TEMPLATE.DOC CRICOS INSTITUTION CODE 00213J
PAGE 5
H
L
M
Minor
Major
Risk Treatment
Residual Risk Rating
A – Avoid the risk L – Change the likelihood C – Change consequences S – Share the risk R – Retain the risk
H – High M – Medium L – Low 0 – None
Owner of Risk
QUALITY PLAN NAME OF PROJECT
Quality Plan The Quality Plan contains the quality standards, quality assurance processes and quality control activities for a project. See the example of a completed Quality Plan. 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
Primary Other Other
2 VERSION CONTROL Add new rows to the table as necessary.
Version Number
Date
Reason/Comments/Approvals
3 QUALITY PLANNING AND STANDARDS Identification of the quality standards that will be used for the deliverables and how to satisfy them, for example, the best practices identified in the PMF and the Project Management Body of Knowledge â&#x20AC;&#x201C; PMBOK Guide 2000 Edition. 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.
PMFQUALITYPLANV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
PAGE 1
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.
Activity
Measure
Possible Rectification
6 QUALITY PLAN RECORD 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.
Date
Activity
Issue
PMFQUALITYPLANV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
Outcome
PAGE 2
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â&#x20AC;&#x2122;s Change Management policy. 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: Name
Position
Phone
Primary Other Other
2 VERSION CONTROL Add new rows to the table as necessary.
Version Number
Date
Reason/Comments/Approvals
PMFCommunicationPlanV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
PAGE 1
COMMUNICATION PLAN NAME OF PROJECT
3 MARKETING AND COMMUNICATION STRATEGIES These strategies may be for “selling” the project or for providing project details to selected stakeholders, for example, to steering committee members. Refer to Appendix C in the PMF Guide for additional information. To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
(Who are you informing? Who are you selling the service to?
Action
Timing
Frequency
(What is the message? What is the method? What do you need to do? What steps are involved?)
(What time in the project?)
(How often?)
Stakeholder1 or Group1 Stakeholder2 or Group2 Stakeholder3 or Group3
PMFCommunicationPlanV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
PAGE 2
Costs
Actioned By (Who is responsible for this action?)
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.
Audience (Who are you training?)
Type of Training (Will you be using class room, online, streaming media, seminar, etc)
Action (What do you need to do, what steps are involved?)
Timing and Frequency (What time? How often?)
Stakeholder1 or Group1 Stakeholder2 or Group2 Stakeholder3 or Group3
PMFCommunicationPlanV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
PAGE 3
Costs
Actioned By (Who is responsible for this action? Who will be doing the training?)
PROJECT STATUS REPORT NAME OF PROJECT
Project Status Report The Project Status Report is a tool used throughout the life of a project to supply information on how the project is proceeding. The report is a vital communication tool aimed at the sponsor/steering committee. The report will also be distributed to other appropriate stakeholders. A Work Breakdown Structure showing progress may be distributed at the same time. For major projects, the complete Risk Management Plan may be included. The report includes a Review of Risks at the end, required for all projects, showing all high and changed or otherwise notable risks. After the date, add the sequential report number, eg, 1 for the first project Status Report All AMP (IT) project Status Reports should include the Project Portfolio Office in the distribution list, at project_portfolio@qut.edu.au. See the example of a completed Project Status Report: http://www.its.qut.edu.au/pp/framework/pmfexamples.jsp 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
1 PROJECT INFORMATION Project/Program Number (if applicable): Project Name: A brief name to describe the project Report Number: (1, 2, 3, etc) Date: Date of current Project Status Report 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
2 RECENT PROJECT ACTIVITIES AND HIGHLIGHTS Details of project 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
3 PROJECT PERFORMANCE Details of project progress, including and overview, timeline, budget and any other issues. Please indicate the performance of each important area of the project, and of the project overall, by assigning the appropriate colour. 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.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
PAGE 1
PROJECT STATUS REPORT NAME OF PROJECT
No changes/issues
Potential changes/issues
G
Changes/issues
Y
R
In the table below report the performance of the project for each reporting period throughout the course of the project. Continue to add rows as required so that ALL reporting periods are shown. To select colour: 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 Add the appropriate letter to the cell for people who print in black and white and those who are visually impaired. The first line in the table below is an example only.
Date
Timeline
dd/mm/yy
G
Budget
Y
Communication
G
Scope
R
Resources
R
Risks
Y
Overall Project
Y
3.1 Overview
An overview of project progress during this period. 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.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
PAGE 2
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
Milestones
Deliverables
Due Date
Actual Completed Reason for Slippage Date
Actions and Resolutions
3.3 Budget Status An accounting of the current state of the actual expenditure to date compared with the planned budget. A notable variance should be addressed. Budget categories include salaries, equipment and software. 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 Category Project Plan by Category
PMFSTATUSREPORTV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
Amount Spent to Date
On Track Y/N?
Explanation if Necessary
PAGE 3
PROJECT STATUS REPORT NAME OF PROJECT
3.4 Other Issues
This section is a summary of any issues or potential issues that have arisen with regard to communication, scope, resources and risks. It should include a description of what the issue or potential issue is and any actions planned or lessons learnt from the issue. For actions note the date the action was taken or is planned to be taken. 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
Performance Areas
Major Issues / Concerns
Communication Scope Resources Risks
4 PLANNED ACTIVITIES/DELIVERABLES FOR NEXT TIME PERIOD A list of forthcoming, notable activities that can be reviewed in the next Status Report. Include comments where appropriate. 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
Activity
Deliverables
Due Date
Comments
(See Review of Risks on next page.)
PMFSTATUSREPORTV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
PAGE 4
PROJECT STATUS REPORT NAME OF PROJECT
5 REVIEW OF RISKS The table should include all high risks, otherwise notable risks and new or changed risks for review. 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 Risk
PMFSTATUSREPORTV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
Adequacy of Likelihood Existing Controls
Consequence Risk Rating
PAGE 5
Risk Treatment
Residual Risk Rating
Owner of Risk
PROJECT CHANGE REQUEST NAME OF PROJECT
Project Change Request The Project Change Request Form is used to request approval of notable, strategic changes in a project from its Steering Committee. Projects are dynamic and changes are inevitable. Good project management ensures that the changes are recognised, documented and dealt with at the right level. Every change should have a separate request form. The steering committee has authority to approve most changes. For AMP (IT) projects, requests for significant changes (a call of judgement) and all requests for additional funding should first be approved by the steering committee, then go to the DVC (TILS) for approval. Requests for major additional funding may involve ITGC. Project Change Request Forms approved by the steering committee should be copied to the Project Portfolio Office and recorded in the projectâ&#x20AC;&#x2122;s next Project Registry update. The Project Portfolio Office will advise the DVC (TILS) and ITAC of notable changes approved by steering committees, as appropriate. See the example of a completed Project Change Request. Guidance boxes like this are displayed in MS Word Print View (not in Normal View). They should be deleted when you have finished with the contents: position the cursor on the border, left click when a cross appears and press delete.
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
2 DESCRIPTION OF REQUEST WITH REASON(S) A full description of the change request and the basis for the change. Include expected outcomes and benefits. 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 CHANGES IN KEY PROJECT AREAS A table showing the changes needed across the specific key project areas and the adjustments within each area to accommodate the requested change. To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
PMFPROJectChangeRequestV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
PAGE 1
PROJECT CHANGE REQUEST NAME OF PROJECT
Category
Reason for Variance from Project Plan
Proposed Change (Against Project Plan)
Scope Time Cost Quality Risk Management Communications
4 PROJECT PLANS TO BE REVIEWED AND SUITABLY MODIFIED? Indicate Y/N. If Y, give details, including time frame, etc. If N, give reason. 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 DISPOSITION OF CHANGE REQUEST This section to be completed on behalf of the Steering Committee. Upon approval by the steering committee, a Project Change Request for significant changes and all requests for additional funding should be forwarded to Project Portfolio Office for the approval of the DVC (TILS) (and to ITGC if required). Indicate the decision on the request for change and resulting actions. This information is for tracking purposes. To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
Date of Decision
Approved Y/N?
Reason for Approval or Rejection
PMFPROJectChangeRequestV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
Resulting Action
PAGE 2
ACTIVITY COMPLETION REPORT NAME OF PROJECT
Activity Completion Report The Project Activity Completion Report advises that the project has ended, either at the end of the closing phase or for another reason in an earlier phase. For AMP (IT) projects a Post Implementation Report will also be required for major projects and for other projects at the discretion of the DVC (TILS). Usually, the Project Manager will complete the Activity Completion Form. See the example of a completed Project Activity Completion Report. The Project Activity Completion Report should be approved by the steering committee, then sent to the Project Portfolio Office at project_portfolio@qut.edu.au. 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: Todayâ&#x20AC;&#x2122;s date Project Ownership: Areas responsible for project Prepared by: Name and project position Contact Names: Name
Position
Phone
Primary Other Other
2 REASON FOR CLOSURE Includes successful completion of project or termination before completion. 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 CLOSING ACTIVITIES
PMFActivityCompletionFormV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
PAGE 1
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.
4 OVERVIEW OF CLOSING PROJECT A table indicating the status of key factors when the project closed. Indicate how the project had met these factors upon closing. Add more rows as required for additional objectives, benefits and milestones. Type in your project information below, then delete this guidance box: position the cursor on the border, left click
Key Factor
Description
Achieved Upon Closing
Objective 1 Objective 2 Scope Benefit 1 Benefit 2 Costs and Resources Schedule overall Milestone 1 Milestone 2
5 LESSONS LEARNED List the lessons learned from your project. The idea is to be positive. How can these lessons be applied to other projects? 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
No.
Lesson
Where/How to be used
6 RECOMMENDATIONS ARISING FROM THE PROJECT List the recommendations derived from your project. The idea is to be positive. What could have been improved? How will these lessons/recommendations be applied to other projects? 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.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
PAGE 2
ACTIVITY COMPLETION REPORT NAME OF PROJECT
No.
Recommendation
Where/How to be used
7 ADDITIONAL INFORMATION Any information not already shown in the report, for example, a note that the project may have a subsequent phase as a result of additional client expectations. 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.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
PAGE 3
PIR REPORT NAME OF PROJECT
Post Implementation Review Report The Post Implementation Review (PIR) Report is used to supply information about the outcomes and success of a project. The PIR lists the expected outcomes as specified in the Project Plan, reports on variances from that plan and then asks for recommendations and how they will be used, as well as lessons learned. All projects require a Project Activity Completion Report to be completed. Additionally, for AMP (IT) projects a PIR is required for all major projects. A PIR for other projects may also be requested by the DVC (TILS). The PIR should be approved by the steering committee and sent to the Project Portfolio Office at project_portfolio@qut.edu.au. See the example of a completed Post Implementation Report. 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: 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 A brief history of the project to give context. 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 MEMBERS OF PIR TEAM List those involved in the PIR, including identification of the Chair or organiser. â&#x20AC;˘
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
â&#x20AC;˘
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.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
PAGE 1
PIR REPORT NAME OF PROJECT
Name
QUT Position
Role in Project
Phone
:
PMF_PIRV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
PAGE 2
PIR REPORT NAME OF PROJECT
4 OUTCOMES IN KEY PROJECT AREAS A table showing information about key project areas. Include a reference for evidence where appropriate. 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 Evidence
(as in Project Plan) Scope Time Cost Quality Risk Management Communication
PMF_PIRV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
PAGE 3
Reason for Variance from Project Plan
PIR REPORT NAME OF PROJECT
5 OBJECTIVE OUTCOMES A table showing information about project objectives. To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
Objective
Objective Met?
(as in Project Plan)
(Score 1-5 1=Not at all 5= Completely)
Outcome
Reference for Evidence
Reason for Variance from Project Plan
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?
(as in Project Plan)
(Score 1-5 1=Not at all 5= Completely)
PMF_PIRV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
Outcome
Reference for Evidence
PAGE 4
Reason for Variance from Project Plan
PIR REPORT NAME OF PROJECT
Benefits Realised
Benefit realised?
(as in Project Plan)
(Score 1-5 1=Not at all 5= Completely)
Outcome
Reference for Evidence
Reason for Variance from Project Plan
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 Requirements (as in Specifications)
PMF_PIRV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
Requirement met?
Outcome
Reference for Evidence
(Score 1-5 1=Not at all 5= Completely)
PAGE 5
Reason for Variance from Specifications
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
No.
Lesson
Where/How to be used
9 RECOMMENDATIONS ARISING FROM THE PROJECT List the recommendations derived from your project. The idea is to be positive. What could have been improved? How will these lessons/recommendations be applied to other projects? 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
No.
Recommendation
Where/How to be used
10 MECHANISMS USED TO GATHER INFORMATION FOR PIR Provide information on how information for PIR was gathered, eg, focus group, individual interviews, log reports, status reports. List names and other details for focus groups and interviews. Designated stakeholders, business clients, steering committee members, impacted areas, etc, should be consulted as necessary for the project. To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
Type of Information Gathering (eg, focus group, interview)
All Names
PMF_PIRV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
Position at QUT
Interest or Role in Project
PAGE 6
PIR REPORT NAME OF PROJECT
Type of Information Gathering (eg, focus group, interview)
All Names
Position at QUT
Interest or Role in Project
11 APPENDICES AND SUPPORTING DOCUMENTATION (OPTIONAL) List attached appendices and supporting documentation. This information is optional, depending on project size and outcomes. For example, appropriate records from a project that encountered significant problems could well be useful. Similarly, information that demonstrates a lesson to be learned from a project could be included. Logs of changes and incidents should be included here. Original documentation may also be included, for example, a report on lower level specification success. To delete this guidance box: position the cursor on the border, left click when a cross appears and press delete.
•
Appendix A - document 1
•
Appendix B - document 2
PMF_PIRV4.2 ENTER FILENAME WITH VERSION NUMBER CRICOS INSTITUTION CODE 00213J
PAGE 7
AMP (IT) Support & Maintenance Activity Request PPO Activity No. (if known) Activity Name: Contact Person: Type:
Phone:
New Request / Request for increase in allocation (delete inapplicable choice)
Category: Staffing / Hardware / Software / other ____________ (delete inapplicable choices) Date: (of submission of the proposal) Brief Description: (Outline a description of the activity here – attach activity specific supporting documentation separately, e.g., equipment roll-over schedules. If request is for an increase in current projected funding, provide a justification for the increase.)
If proposal is for an increase in allocation, show current funding and projections in ($,000): 2008:
2009:
2010:
Requestor’s Proposed Funding ($,000): 2008:
2009:
2010:
Confidence in funding figures: Definite / Informed / General estimate
(delete inapplicable
choice) Rationale and Benefit of doing: Compliance /Service Improvement / Effectiveness (delete inapplicable choices) (Supply supporting text here. Indicate reasons and, specifically, who benefits (staff, students, QUT…). Explain how each benefits.)
Impact of not doing: Descriptive text here.
(see next page) Should insufficient funds be available…. Proposed Fallback Position Funding ($’000): 2008:
2009:
2010:
Impact of fallback position funding rather than full funding: (Descriptive text here.)
CRICOS INSTITUTION CODE 00213J
Page 1