 An Overview of the EPM Methodology |
Document Control
| Version: | 4.0 |
| Date: | |
| Status: | Final |
| Confidentiality: | Confidential |
Document change control:
| Version # | Change Description | Date | Author |
| 0.1 | Initial Draft | | Rhian Saunders |
| 0.2 | Include UoN specific information | | David O’Leary, Marina Bernard |
| 1.0 | Include reporting conventions | | David O’Leary |
| 2.0 | Remove project prioritisation. Include Project Charter and Test Summary Report. | | Marina Bernard Rhian Saunders |
| 3.0 | Include use of new Enterprise Risk Management System | | Marina Bernard |
| 4.0 | Include Communications Plan to Planning phase. Change Support Plan to Release to Operational Support Document. Include in list of templates Remove reference to SPO Charter Updated phases and related documents table. | | B. Nelson |
| |
| |
Approved by:
| Signed by: | | | DATE: | / / |
| Name: | | | Dept: | |
| Position: | | | | |
| |
Table of Contents
1. Document Information, Content & Purpose
The purpose of this document is to introduce the University of Newcastle Enterprise Project Management Methodology (EPMM) providing an overview of the project management processes, templates and guidelines required for all business related and IT projects. The document additionally examines a standard process flow detailing the roles and responsibilities of each of the participating bodies involved in the EPMM process.
The EPMM is designed for general use across the University, however, the primary users will be:
§ All Project Managers
§ Business staff who coordinate projects
§ Business staff who contribute to projects
The following terms and abbreviations are used in this document for the purpose of brevity:
| Term/Abbreviation | Definition |
| DVC | Deputy Vice-Chancellor |
| EPMM | |
| EPMS | |
| ITGC | IT Governance Committee |
| IT POW | IT Program of Work |
| PM | Project Manager |
| PMP | Project Management Plan |
| PLC | Project Lifecycle |
| PSC | Project Steering Committee |
| RMU | Risk Management Unit |
| | Services’ Directors Committee |
| PMO | Project Management Office |
| UoN | |
2. EPMM Overview
The EPMM has been developed to provide an organisational approach and system to the management of projects within the University. It is a high level project management method that offers a set of tools (documents) and techniques (guidelines) that are scalable and adaptable to all levels of projects.
The EPMM is designed to be a high level methodology and assumes a level of knowledge consistent with participation in a 2 day project management education workshop.
The University of Newcastle
The EPMM leverages standard best practice techniques and offers a consistent way of working. This provides the following key benefits:
§ Consistent standard methodology across the University
§ Encompasses different categories of projects (e.g. IT and Business projects)
§ Increased project controls
§ Clear areas of responsibility
§ Consistent clear templates, guidelines and checklists
§ Encourages best practice adherence in all size projects (minor, medium, and major)
§ Provides a basis for continuous improvement.
Additionally, a consistent approach to the delivery of projects provides business value by saving time, reducing costs and will quickly become valuable intellectual property for the University.
The contents of the EPMM will be as follows:
§ EPMM Overview (this document) including the PM Lifecycle, deliverables per project phase and project accountabilities
§
§ Templates and checklists to be used during each phase of the PM Lifecycle.
UoN seeks to apply varying levels of project management rigour and governance to the delivery of projects, in proportion to the project’s value, complexity and impact on the business.
The Program Management Office and assigned Project Manager will determine a project complexity rating to all IT Program of Work projects based on a project Category Assignment Matrix. The rating determines the appropriate level of project management methodology to be applied as outlined in the table below.
| Project Level – Minor | Low risk, <$50k project value |
| Description | A simple project that is less than 80 hours in duration, impacts only one business area / system and has minimal dependencies. |
| Project Manager Allocation | Project Lead to be appointed. |
| PM Methodology Application | The following items must be completed: § Project Initiation Document § Minor Projects Checklist § Project Schedule § Customer Acceptance Sign-off § Handover Document and Sign-off |
| Project Level – Medium | Moderate risk, $50- $100k project value |
| Description | A standard project that is less than 3 months in duration, impacts on 1-5 business areas / systems and has less than three dependencies. |
| Project Manager Allocation | Project Manager (any level) to be appointed. |
| PM Methodology Application | A mandatory set of documents must be completed (to be defined in method development) along with optional documents agreed by the Project Manager at the beginning of the project initiation phase in consultation with the PMO. |
| Project Level – Major | Extreme risk, >$100k project value |
| Description | A complex project that is greater than 3 months in duration, impacts on more than 5 business areas / systems, and has more than three dependencies. |
| Project Manager Allocation | Senior Project Manager to be appointed. |
| PM Methodology Application | Full EPMM to be applied. Tender process to be followed. |
3. The Project Management Lifecycle
This section describes the PM Lifecycle, key deliverables, and process flow for projects that apply the full EPMM*.
The EPMM aims to progress projects through the phases of the project lifecycle, providing clear checkpoints and approval mechanisms prior to proceeding to the next phase.
A complete list of templates for each phase is listed in Appendix 1 of this document.
* Minor projects generally follow the lifecycle (from Initiation to Close) but do not include all checkpoints / deliverables. The Minor Projects Checklist document should be referred to for checkpoints associated with minor projects
Key deliverables within the PM Lifecycle phases are as follows:
| Phase | Deliverable | Responsibility | Sign off |
| Initiation | § Project Initiation (Minor project) § Project Idea § Project Proposal § Project Charter | § Project Manager § Business Unit § Project Manager § Project Manager | § Business Owner § Business Owner § Business Owner, Project Sponsor § Business Owner |
| Discovery | § Minor Projects Checklist (Discover Phase) § Business Requirements Document § Business Case | § Project Lead § Project Manager, Business Analyst § Project Manager, Business Analyst | § Project Lead § Business Owner, Project Manager § Business Owner |
| Planning | § Minor Projects Checklist (Planning Phase) § Project Management Plan § Tender Documentation (where applicable) § Communications Plan | § Project Manager § Project Manager, Org Development | § NA § Business Owner, Project Manager § Business Owner, Project Manager, Organisational Development |
| Delivery | § Minor Projects Checklist (Delivery Phase) § Training Plan and associated Documentation (e.g. user guides) § Deployment Plan § Deliverables as specified in the Project Management Plan (e.g. building work, software upgraded) § Test Plan and associated Documentation (e.g. test cases) § Test Summary Report § Release to Operational Support Document § Test Acceptance Sign-off | § Project Manager § Project Manager § Test Analyst, Business Analyst § Test Lead § Working Party § Project Manager | § NA § Business Owner and other relevant parties § Business Owner, Organisational Development § Business Owner, Change Manager § Project Manager, Business Owner, Test Manager § Test Lead, Project Manager § Project Manager, Business Owner, IT Operations representative § Business Owner, Project Manager |
| Deploy & Handover | § Production Checklist § Handover Sign-Off | § Project Manager | § Business Owner, Support/ Maintenance representative § Business Owner, Support/ Maintenance representative |
| Close | § Project Close-Out Sign-Off § Post Implementation Report | § Project Manager § Project Manager | § Business Owner, Project Manager § Business Owner |
| Benefits Realisation | § Benefits Realisation Report | § Business Owner | § Business Owner |
4. Project Roles & Responsibilities
The roles and responsibilities of each of the key Project stakeholders and governance groups within the project process are specified below:
Business Owner
A business project can be proposed by anyone in the business and can be viewed as the ‘customer’ in project terms. Projects can also be identified by a Project Sponsor, who will then nominate a Business Owner. The Business Owner is responsible for:
§ Owning and signing off the Project Proposal document
§ Present the Proposal to the Services’ Directors Committee (is this correct) for evaluation
§ Signing off each phase of the project
§ Act as an escalation point for the Project Manager
§ Own the outcome of the business case and project
§ Manage and measure benefits to ensure the project delivers the benefits specified in the Business Case
Project Sponsor
The Project Sponsor owns the funds / budget and is ultimately accountable for the project and its end result. Within UoN, the Project Sponsor is the Deputy Vice Chancellor of the relevant Division. The role responsibilities of the Project Sponsor are to:
§ Sign off the Project Proposal along with the Business Owner
§ Act as an escalation point for the Business Owner
IT Governance Committee
The IT Governance Committee oversees all projects run in UoN and is required to:
§ Ensure all projects are aligned to the UoN Strategic Plan and Operational Plans
§ Approve funding for all projects
§ Manage enterprise risks
§ Analyse project portfolios from a strategic, funding and status perspective
§ Evaluate and prioritise projects across UoN based on business benefits
The Project Management Office (PMO)
The PMO perform a range of functions. Key functions are listed below:
§ Support the selection and prioritisation of strategic projects
§ Assess and categorise projects according to project complexity
§ Assist in the allocation of a Project Manager (where required)
§ Register and track the status of all PMO projects
§ Mentor
§ Own the EPMM documentation and associated tools (e.g. EPMS, templates)
§ Keep UoN management teams and staff informed
Project Steering Committee
A Project Steering Committee may be established for medium to major projects and comprises of those Directors who are affected by the project, including the Project Sponsor where necessary. The responsibilities of the Project Steering Committee are to:
§ Clear organisational obstructions and help resolve project issues escalated by the Working Party
§ Be generally chaired by a Business Owner
§ Monitor the progress of the project
Project Manager
The Project Manager’s role is to manage the project on a day-to-day basis delivering the project in accordance with the approved Project Management Plan. The responsibilities of the Project Manager are to:
§ Identify key stakeholders
§ Registering the project with the PMO
§ Manage all stakeholder communications through the life of the project.
§ Define resource requirements and allocate resources accordingly
§ Plan, manage and execute the project within the specified constraints of time and resources
§ Report project status to Project Steering Committee, Project Management Office, and others where required
Working Party
A Working Party is generally established for all projects. This generally consists of the Project Manager, a Business Analyst, Project Team Members, key stakeholders from the business and the Business Owner (as required). The responsibilities of the Working Party are to:
§ Provide clear business requirements for the project
§ Identify high level risks and project dependencies
§ Review project status and work together to resolve any problems that are identified
§ Escalate any unresolved items to the Project Steering Committee
§ Ensure resources are available for user acceptance testing (UAT)
§ Formally accept and sign off the completed project
Project Team
The project team can include internal staff from the business, customer representatives, suppliers, vendors and subject matter experts. The role responsibilities of the Project Team are to:
§ Provide subject matter expertise as required
§ Complete all agreed deliverables, assigned by the Project Manager
§ Ensure timely escalation of risks and issues to the Project Manager
Risk and Assurance Unit
The Risk and Assurance Unit is committed to:
§ Developing a Risk Management framework
§ Ensuring the implementation of the risk management framework through training, workshops and providing assistance when required
§ Assisting University managers conduct a risk assessment where necessary
§ Managing the Internal Audit Function of the University
5. Project Document Management Guidelines
All PM Methodology documents including Guidelines, Checklists and Templates are located on the EPMM templates page on the PMO website (http://www.newcastle.edu.au/unit/it-services/project-management-office/)
When a Project Manager is assigned to a project they will establish a project folder. All project folders will be located at S:\UoN_projects\PoW - SPO\Project Documentation . Project folders are within the area set aside for each business area in Services Division.
The centralised storage of projects will allow access to project information by the project team, business owners, and the PMO.
Each project folder should be set up as follows:
| Folder | Example Content |
| Project Name | e.g. name and cost collector |
| 0. Control Documents | Estimates Cost Tracking Minutes & Actions Project Status Reports Change Requests Resource Planning |
| 1. Initiation | Project Idea Project Initiation Document (for minor projects) Project Proposal Project Charter |
| 2. Discovery | Minor Projects Checklist (for minor projects) Business Requirements Business Case |
| 3. Planning | Minor Projects Checklist (for minor projects) Project Management Plan Communications Plan |
| 4. Delivery | Training, Deployment, Test, Support Plans Testing and UAT Tracking logs Test Summary Report Release to Operational Support Test Acceptance Sign-Off |
| 5. Deploy & Handover | Production Checklist Handover Sign-Off |
| 6. Close | Project Close-Out Sign-Off Post Implementation Report |
| 7. Benefits Realisation | Benefits Realisation Report |
The file name and version of the document is to be inserted into the footer of each project document to maintain version control. The recommended convention is for Draft documents to start at V0.01 and increase in increments of 0.01, eg to V0.02.
When the document is completed and signed-off the version number is to start from V1.0 and increase in increments of 1.0, eg to V2.0 etc. For example: Project 123 Business Requirements_V1.0.
Within each document used, the version and change control table at the front of the document should be completed to inform the reader of recent changes.
| Version # | Change Description | Date | Author |
| | | | |
6. ADAPTING THE METHODOLOGY TO A PROJECT
One of the major problems facing any project is the extent to which the templates, guidelines and other related documents are used and the level of detail required to successfully complete the project.
Who determines Project Sizing?
The Project Leader or Project Manager preparing the Project Proposal makes an initial determination of the project size in consultation with the PMO. Once the Project Proposal has been signed off by the Business Owner and approved by the IT Governance Committee the project size is formally determined.
How to determine the Project Size
The table below illustrates the criteria to use:
| Project Size | Project Risk | Project Cost | Project Duration | Business Impact | Dependencies |
| Minor | Low | < $50K | < 80 hours | 1 business area / system | 0 – 1 |
| Medium | Moderate | $50 - $100K | < 3 months | 1-5 business areas / systems | 2 – 3 |
| Major | High | > $100K | > 3 months | > 5 business areas / systems | > 3 |
A Category Assignment Matrix (Excel tool) is available to help with determining the project size an can be found on the Project Management Office website under Templates and Guildelines.
7. Project Reporting
Monitoring of project progress and providing status reports to key stakeholders is essential for good communications and is a necessary control process within any project. The Status Report provides stakeholders with a view on project performance and on any issues that could affect the successful delivery of the project.
Frequency of the Status Report varies for projects of different size:
§ Minor Projects must have at least one status report. If the duration of the project exceeds 80 hours then a monthly status report is required.
§ Medium Projects must have as a minimum a fortnightly status report.
§ Major projects must provide a status report on a fortnightly basis.
§ Status Reports for Medium and Major projects are to be emailed to the Steering Committee, and can be copied to the project team.
§ Status reports should be saved in the project folder with the following convention project name <yyyymmdd>
§ Copies of all status reports are to be mailed to PMO@newcastle.edu.au.
The IT Governance Committee ensures all projects are aligned to the UoN business strategy, approves funding for projects, and monitors project progress and project risk.
A summary status report of all active projects is submitted to the IT Governance Committee on a monthly basis. This report is prepared by the Program Manager, Program of Work. A risk report is also prepared each month by the Program Manager, Program of Work for high and extreme project risks, and provides statistics about risks currently open by category and risks closed in the previous month.
The Finance and Capital Committee is a standing committee of the University Council that provides reports to Council four times per year. Finance and Capital monitor University performance across a number of core business areas, including continuous improvement, business transformation project reporting and new university-wide projects. The PMO provides a report for consideration to Finance and Capital of all active projects.
The Project Costing Model is to be used to prepare cost estimates. Includes estimates by staff, contractor, hardware and training costs. This template is also used throughout the project to provide an updated project forecast to complete. TechnologyOne Financials (TOF) reports provide the Project Manager with the actual and commitment costs for the project.
All project risks and issues are recorded in the Enterprise Project Management System (EPMS). Issues and risks are to be updated by the Project Manager in EPMS on a fortnightly basis.
Any request for changes to the project once the project has commenced is to be managed via Change Requests. Each change requested is to formally documented and approved / rejected on the Project Change Request Form.
The Project Change Request Form is used as a tool to capture, evaluate, and approve / reject all changes that will affect the agreed project baseline. One form should be raised for each change.
The Project Change Register should list all requested change requests whether they are accepted or rejected. The Change Register provides a list of project variance items that can then form part of Project Status Reports or Post Implementation Reviews. Only one register (created in Excel®) should exist per project.
8. Risk & IsSUES Management
Project risks and issues are to be recorded in the Enterprise Project Management System (EPMS). Risks and issues are to be updated in EPMS every fortnight and reported via weekly Project Status Reports. Guidelines are available on how to use EPMS to categorise risks and issues for projects.
9. Enterprise
The Enterprise Project Management system is the central repository for managing and maintaining all project schedules.
§ At the commencement of a project, the EPMS Administrator will create a project schedule template for the Project Manager to checkout and update.
§ All project schedules must be published to EPMS once the Initiation Phase has commenced. The initial schedule may simply contain milestones.
§ Once the Planning Phase of the project has been finalised, the project schedule must be baselined.
§ The project schedule must be updated each week by close of business (5pm ) on Friday.
§ The EPMS will be used for reporting purposes by the PMO.
10. Appendix 1: Templates
In the larger templates, e.g. Project Management Plan, guidelines are provided in a separate section at the beginning of the document to describe the purpose of the template and how to use it. This section should be retained for reference purposes when the template is being completed and deleted prior to submitting for sign-off.
The template is the tool to be used when planning and managing the project. The templates consist of sections and their associated ‘prompts’. These prompts guide the user as to the information required. The prompts, shown in grey italics, should be deleted when the section has been completed.
These templates can be customised to suit the individual project, however, it is important to use the standard template as a starting point for each project to ensure that no sections are inadvertently missed and consistency is maintained.
| EPMM | Project Control Documents | Guidelines |
| | § Project Schedule in EPMS § Project Status Report § Project Costing Model & Tracking Spreadsheet § Project Budget v Actuals Spreadsheet § Agenda § Minutes & Actions § Project Change Request Form § EPMM Template Change Request Form | § EPMM Overview § Category Assignment Matrix |
| Project Phase | Templates | Guidelines & Supporting Documents |
| Initiation | § Project Idea Document § Project Initiation (minor projects) § Project Proposal § Project Charter | § Project Classification Description |
| Discovery | § Minor Projects Checklist § Business Requirements Document § Business Case | § Project Schedule Guideline § |
| Planning | § Minor Projects Checklist § Project Management Plan § Communications Plan | § Planning Phase Kick-off Guideline § Project Estimation |
| Delivery | § Minor Projects Checklist § Training Plan (Major Project) § Deployment Plan § Test Plan § Test Summary Report § Release to Operational Support Plan § Test Acceptance Sign-Off | § Business Requirements Traceability Matrix § UAT Tracking Log |
| Deploy & Handover | § Minor Projects Checklist § Production Checklist § Handover Sign-Off | § Transition to Production Flow Chart |
| Close | § Minor Projects Checklist § Post Implementation Report § Project Close-Out Sign-Off | |
| Benefits Realisation | § Benefits Realisation Report | |
11. Appendix 2: Project Lifecycle - Details
| Phase | Initiation | Discovery | Planning | Delivery | Deploy & Handover | Close | Benefits Realisation |
| Phase Objectives | § Register project proposal and make go / no-go decision | § Investigate project options, define business benefits and justify project | § Plan project detail and agree expectations | § Manage project delivery to plan and obtain customer acceptance | § Manage project deployment to plan and hand over to support / maintenance | § Finalise project and conclude all obligations | § Manage and measure benefits |
| Key Phase Inputs | ∆ Project Idea ∆ Project Proposal ∆ Project complexity assessment | ∆ Output from previous phase ∆ Business Requirements | ∆ Output from previous phase ∆ Stakeholder/team input ∆ Design process ∆ Tender process | ∆ Output from previous phase ∆ Acceptance criteria ∆ Gather deployment, support and training detail | ∆ Output from previous phase | ∆ Output from previous phase ∆ Post Implementation Review Meeting | ∆ Project output ∆ Defined expected benefits |
| General Phase Activities | § Identify idea or concept § Develop project proposal § Proposal registered with PMO § Project assessed for complexity rating § Proposal evaluated for priority § Obtain approval to proceed to next phase | § Form working party § Engage major stakeholders § Investigate requirements and opportunities § Develop Business Requirements document § Define benefits / timing/ scope/ budget § Develop Business Case § Obtain approval to proceed to next phase | § Conduct phase kick off meeting § Establish Project Steering Committee § Verify detailed requirements and acceptance criteria § Execute tender process § Define resourcing requirements § Agree solution § Plan deployment, training, support and handover strategies § Develop PMP § Develop Comms Plan § Obtain approval to proceed to next phase | Execute activities as per PMP including: § Design solution § Conduct any build or development activity § Plan and execute testing activities where required § Manage project elements (scope, risk, time etc) § Detail deployment, training, support and handover activities § Produce training and support documentation (manuals, user guides etc) § Obtain approval to proceed to next phase | § Conduct training § Execute support plan § Execute deployment and handover plan § Manage deployment to agreed plans | § Formally conclude project activities § Review project output § Conclude documentation § Conclude contractual obligations § Release team § Conclude project costs § Review project and document lessons learnt § Notify SPO of completion § Notify Business Owner of benefits realisation stage | § Initiate measurement of benefits |
| Phase Outputs | ∆ Project Proposal Signed Off by GC ∆ Project registered ∆ EPPM level defined ∆ Project Charter | ∆ Requirements agreed ∆ Business Case signed off | ∆ Detail design mapped to requirements ∆ Deployment, training, support and handover strategy ∆ PMP Signed Off | ∆ Delivery managed to plan ∆ Deployment, training, support and handover plan ∆ Customer Acceptance Sign Off | ∆ Production Checklist ∆ Handover signed off | ∆ Documentation archived ∆ Resources released ∆ Lessons learnt captured ∆ Project Close-Out Sign Off | ∆ Specific benefits assigned to individuals ∆ Benefits reported and communicated |
| Accountable | PMO, IT Governance Committee & Sponsor | Business Owner & Project Manager | Project Manager | Project Manager | Project Manager | Project Manager | Business Owner |
ReplyDeleteExecutive Coaching and Mentoring... this is really great way to do such type of management...
Thanks a lot, Sir.
ReplyDelete