Your SlideShare is downloading. ×
Project Management Framework
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Project Management Framework

4,046
views

Published on

Published in: Business, Technology

1 Comment
3 Likes
Statistics
Notes
  • You can get PMBOK 5th edition based complete & 'brain-friendly' PMP exam notes for free on www.PMExamSmartNotes.com. Also, sign up for your free PMP Study Blueprint to fast track your PMP preparation efforts.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
4,046
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
323
Comments
1
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Project Management Framework Project Management Framework Guide The framework comprises this guide and a set of project management templates, as referenced within this guide. Updated by Michele Berrie and Robyn Warren Project Portfolio Office Version 4.3 December 2008 CRICOS Institution Code 00213J
  • 2. PROJECT MANAGEMENT FRAMEWORK PROJECT MANAGEMENT FRAMEWORK GUIDE Version Control Version Number Date Reason/Comments 1.0 14 March 2003 Additions and edits to document 1.1 1 April 2003 Additions and edits 1.2 16 April 2003 Additions and edits 1.3 28 April 2003 Additions and edits 1.4 12 May 2003 Additions and edits 1.5 19 May 2003 Additions and edits for SC, deletion of forms category information 2.0 26 May 2003 Final edits and changes – to go to SC 2.1 30 May 2003 SC edits and changes 2.2 24 February 2004 Revision of PMF Guide for 2004, including BCF and Internal Audit changes 3.0 1 May 2005 Post Implementation Review Report with change in process for PIR and Activity Completion Report, plus continuous improvement changes to templates and PMF Guide 4.0 19 May 2006 Revised version of the Risk Management Plan to adhere to changes in the University Risk Management Framework. Revised version of the Project Proposal to strengthen benefits realisation, more closely aligned costings tables to reports from the finance system and deliverables in time frames. Change Project Proposal to allow use for Feasibility Study and Project Specifications document, etc, also PMF Guide. Workflow Approval Diagrams added to PMF Guide. Incorporation of a new Feasibility Study Report to capture findings and encourage PM’s to use this option to make the best use of AMP (IT) funds. Communication Plan revamped. More generic PMF Guide, breaking out AMP (IT) specifics Plus continuous improvement changes to templates and the PMF Guide 4.1 21 July 2006 Removal of the Business Case Framework section 4.2 8 January 2008 Updated references to IT Governance groups and process for project status reporting. Also updated all project templates. See Key Changes document for full details. 4.3 23 December 2008 New link to Risk Management Framework Example of Project Registry with new colour coding Updated html links for QUT web sites
  • 3. 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
  • 4. 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
  • 5. 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.3 PAGE 1 23 DECEMBER 2008 CRICOS INSTITUTION CODE 00213J
  • 6. 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.3 PAGE 2 23 DECEMBER 2008 CRICOS INSTITUTION CODE 00213J
  • 7. 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 / Standard to Highly Complex Project Standard to Highly Complex Project Streamlined Project with Known Product/Process with Unknown Product/Process Notification Notification Notification Project Proposal Project Proposal Project Proposal Project Proposal (Project (Feasibility Study) Specifications) Project Plans Activity - Risk Feasibility Study Completion Report - Quality Report - Comm’n Project Proposal (on Activity the basis of FS or Completion Report PS findings) Project Plans Post - Risk Implementation - Quality Review (For major projects) - Comm’n Activity Completion Report Post Implementation (For major projects) Review PMF_GUIDE_V4.3 PAGE 3 23 DECEMBER 2008 CRICOS INSTITUTION CODE 00213J
  • 8. 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.3 PAGE 4 23 DECEMBER 2008 CRICOS INSTITUTION CODE 00213J
  • 9. 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.3 PAGE 5 23 DECEMBER 2008 CRICOS INSTITUTION CODE 00213J
  • 10. 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.3 PAGE 6 23 DECEMBER 2008 CRICOS INSTITUTION CODE 00213J
  • 11. 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.3 PAGE 7 23 DECEMBER 2008 CRICOS INSTITUTION CODE 00213J
  • 12. 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.3 PAGE 8 23 DECEMBER 2008 CRICOS INSTITUTION CODE 00213J
  • 13. 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 Initiating Processes Processes Controlling Processes Retired Time Project Templates Notification Form Project Proposal Project Plan Work Breakdown Structure Risk Management Plan Quality Plan Communication Plan Change Management Plan (optional) Project Status Report Project Change Request Form Project Activity Completion Report Post Implementation Review Report Project Approval Project Confirmation Resources Reserved Resources Governance Sign-off PMF_GUIDE_V4.3 PAGE 9 23 DECEMBER 2008 CRICOS INSTITUTION CODE 00213J
  • 14. 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.3 PAGE 10 23 DECEMBER 2008 CRICOS INSTITUTION CODE 00213J
  • 15. 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.3 PAGE 11 23 DECEMBER 2008 CRICOS INSTITUTION CODE 00213J
  • 16. 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.3 PAGE 12 23 DECEMBER 2008 CRICOS INSTITUTION CODE 00213J
  • 17. 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.3 PAGE 13 23 DECEMBER 2008 CRICOS INSTITUTION CODE 00213J
  • 18. 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. The framework is in line with the Risk Management Standard (AS/NZS 4360:2004). An overview of the risk management process from the QUT Risk Management Framework follows: 1. Establish the context: start the risk management process with a clear understanding of the operating environment. In establishing the context it is essential to identify and scope all influences (internal and external) which may reasonably impact on QUT. The context includes financial, operational, competitive, political (public perceptions/ image), social, client, cultural and legal aspects of QUT’s functions. 2. Identify the risks: look at possible risks from all sources that will impact on all stakeholders. Realise that unidentified risks may present major threats. 3. Analyse the risks: do to provide an input to decisions on whether risks need to be treated and the most appropriate and cost-effective risk treatment strategies. 4. Rate and evaluate the risk: make decisions, based on the outcomes of the risk analysis, about which risks need treatment and treatment priorities. 5. Treat risks: follow five options: avoid the risk, change the likelihood of the risk, change the consequences of the risk, share the risk, or retain the risk. 6. Monitor and review: follow through with regular monitoring and reviewing and raise awareness as risks invariably change during the course of a project. Opportunities may also be included in the above processes. A similar set of five options may be applied for treating risks with positive outcomes, that is, opportunities. Quality Plan A separate quality plan may be provided, using the Quality Plan template, as appropriate. Both the quality of the management of the project and the “product” of the project must be addressed. Quality is the “totality of features and characteristics of a product or service that bear on its ability to satisfy stated or implied needs” (ISO8402). Three aspects of quality are taken into consideration: quality planning and standards, quality assurance and quality control. Each aspect is addressed in the quality plan specific categories. As a minimum, the Project Plan should include the quality measures and acceptance criteria. If problems occur with quality, changes in other areas of the project may need to take place, according to the integrated nature of projects. PMF_GUIDE_V4.3 PAGE 14 23 DECEMBER 2008 CRICOS INSTITUTION CODE 00213J
  • 19. 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.3 PAGE 15 23 DECEMBER 2008 CRICOS INSTITUTION CODE 00213J
  • 20. 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.3 PAGE 16 23 DECEMBER 2008 CRICOS INSTITUTION CODE 00213J
  • 21. 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.3 PAGE 17 23 DECEMBER 2008 CRICOS INSTITUTION CODE 00213J
  • 22. 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.3 PAGE 18 23 DECEMBER 2008 CRICOS INSTITUTION CODE 00213J
  • 23. 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 Chair (Not usually the project manager) o 1 steering committee member o 1 independent member from the client area o 1 project team member • Composition of a typical PIR team for a minor project: o Project manager as organiser and leader o 1 independent member The review should take place within a time frame appropriate to the nature of the project, often within three months, but as long as six months for a large project. The Post Implementation Review Report form provided in the PMF templates should be used. PMF_GUIDE_V4.3 PAGE 19 23 DECEMBER 2008 CRICOS INSTITUTION CODE 00213J
  • 24. 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.3 PAGE 20 23 DECEMBER 2008 CRICOS INSTITUTION CODE 00213J
  • 25. PROJECT MANAGEMENT FRAMEWORK GUIDE 18 APPENDIX A – PROJECT REGISTRY An example of the Project Registry: Key Red Serious significant issues Phase I Initiating Yellow Noteworthy minor issues P Planning Green No changes or issues E Executing/Controlling White Closing C Closing Purple Halted H Halted Grey No report submitted -- -- Communication Overall Project Report Date Resources Project Name (A-Z) Timeline Budget Scope Phase Risks AMP (IT) Funded Non AMP (IT) funded Example 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 I Gr Gr Gr Gr Gr Gr Gr documentation PMF_GUIDE_V4.3 PAGE 21 23 DECEMBER 2008 CRICOS INSTITUTION CODE 00213J
  • 26. 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.3 PAGE 22 23 DECEMBER 2008 CRICOS INSTITUTION CODE 00213J
  • 27. 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.3 PAGE 23 23 DECEMBER 2008 CRICOS INSTITUTION CODE 00213J
  • 28. 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.3 PAGE 24 23 DECEMBER 2008 CRICOS INSTITUTION CODE 00213J
  • 29. 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/trarhining/checklist.pdf PMF_GUIDE_V4.3 PAGE 25 23 DECEMBER 2008 CRICOS INSTITUTION CODE 00213J

×