Project Management Methodology

Project Management @ Monash

A guide to the approval, planning and management of IT projects at Monash

Table of Contents 1. Introduction ………………………………………………………..1 2. Strategic Planning and Project Approval .................... ............................. .................. .........2 2 3. Project Management Methodology .................. ............................ .................... ................... ........... 4 Phase 1: Project Planning……………………………………………… 6 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 1.10 1.11 1.12 1.13 1.14 1.15 1.16 1.17 1.18 1.19 1.20 1.21

Appoint Project Sponsor .......................................................................... ...................................................................................... ............ 8 Appoint Project Manager ......................................................................... ..................................................................................... ............ 8 Establish Steering Committee .............................................................................. .............................................................................. 8 Review Project Concept ........................................................................... ....................................................................................... ............ 8 Define Detailed Scope and Objectives ................................................................. 9 Define Benefits ............................................................................. ..................................................................................................... ........................ 9 Develop Benefits Realisation Plan ....................................................................... 9 Identify Success Criteria .......................................................................... ...................................................................................... ............ 9 Identify Constraints and Assumptions ................................................................ 10 Define Technical Framework ................................................................... ............................................................................. .......... 10 Identify Support Arrangements .......................................................................... 10 Define Project Approach ......................................................................... ................................................................................... .......... 10 Develop High Level Project Schedule ................................................................ 10 Allocate Project Personnel ...................................................................... ................................................................................ .......... 11 Review Project Cost Estimates Estimates .......................................................................... 11 Develop Risk Management Plan ........................................................................ 11 Establish Reporting Procedures Procedures ........................................................................ 12 Develop Quality Plan .................................................................. ......................................................................................... ....................... 12 Develop Communications Plan .......................................................................... 12 Complete Project Charter ........................................................................ .................................................................................. .......... 12 Approve Project Charter .......................................................................... .................................................................................... .......... 13

Phase 2: Project Execution ................... ............................ ................... .................... .................... ................... .........14 14 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14 2.15

Set Up Project Environment .............................................................................. 14 Conduct Kick-off Meeting ........................................................................ .................................................................................. .......... 14 Develop Project Execution Plan ........................................................................ ........................................................................ 14 Establish Issues Management Process ............................................................... 15 Define Detailed Requirements ........................................................................... ........................................................................... 15 Develop Technical Specifications ...................................................................... 15 Develop IT Continuity Plan Plan ..................................................................... ............................................................................... .......... 15 Establish Change Control Process .................................................................... 15 Perform Project Tasks ....................................................................................... ....................................................................................... 16 Develop Testing Plan .................................................................. ......................................................................................... ....................... 16 Develop Training Plan ............................................................................. ....................................................................................... .......... 16 Develop Implementation Plan .................................................................. ............................................................................ .......... 16 Plan Production Support Framework ............................................................... 17 Implement Project ........................................................................ .............................................................................................. ...................... 17 Obtain Final Sign-off .................................................................. ......................................................................................... ....................... 17

Phase 3: Project Conclusion .................... .............................. ................... ................... .................... ................ ......18 18 3.1 3.2 3.3 3.4 3.5

Decommission Obsolete Systems ....................................................................... 18 Perform Post-implementation Review ................................................................ 18 Monitor Benefits Realisation Realisation ................................................................... ............................................................................. .......... 18 Implement Service Statement ............................................................................. ............................................................................. 18 Celebrate Project Completion……..……………………………………………. 18

Appendix .................... .............................. ................... ................... .................... .................... ................... ................... ................... .........19 19 Glossary ........................................................................ ....................................................................................................................... ............................................... 19

1.

Introduction

This guide to project management at Monash aims to promote an understanding of the key requirements for the successful management of information technology (IT) projects at Monash. Each year Monash University invests significant funds in IT Projects. Well-managed projects, employing best practice processes and techniques, are more likely to be successful and not experience delays and budget overruns. This guide is based on the thomsett organisation’s ‘third wave’ project management process, in which a wide cross-section of Monash staff staff have been trained. It is intended to set a Monash standard for project management, and certain aspects of the thomsett process have been modified to suit Monash’s environment and structure. Section 2 contains a brief description of the strategic planning and project approval process. It outlines the steps that are taken in the initiation, definition and approval of a project. The methodology outlined in Section 3 comprises a set of tasks that provide a ‘roadmap’ or check list for developing and implementing IT projects at Monash. It includes a core of prescriptive actions actions that should be adhered to in the normal course of project management. However, it is also intended to be flexible, allowing the project management model to be adapted to each individual project. What constitutes an IT project at Monash? In broad terms, an IT project at Monash is one that involves a significant amount of IT activity and has its objectives aligned with the University-wide IT Strategic Plan. The project should be cost beneficial, i.e. the benefits outweigh the project costs. costs. It may involve the introduction of a new service, the enhancement of an existing service service or the improvement of efficiencies of current processes. In some cases however, projects may be initiated due to extern al requirements (e.g. government legislation) or to address increased growth and usage of services, as is the case with many infrastructure projects. A project has a set of activities or steps, from which a project plan is developed, forming the basis for monitoring and control of progress and costs. There is an associated budget, defined scope and allocated allocated resources. IT projects at Monash generally have a range of stakeholders or client groups, and on completion should have a positive impact on the operations of the University. Projects can span any length of time, but usually one month is the minimum. Anything less than this is generally considered too small to warrant the use of the project methodology. What is project management? Project management is a professional discipline combining systems, techniques and people to achieve a business objective within defined parameters of time, budget and quality. It employs creative creative problem solving processes designed to recognise and solve pr oblems as they arise, and also to proactively anticipate and avert potentially detrimental detrimental situations. It is based on ethical and honest behaviour using best practice techniques. An important aspect of project management is the building and maintaining of effective relationships with all those involved in the project through a participative and open communication process.

____________________________________________________________________________________________ Project Management @ Monash Page 1

2.

Strategic Planning and Project Approval

How does a project start? The majority of projects undertaken each year are identified during the annual IT Strategic Planning process. From time to time projects are approved outside of this process process in response to changes in university objectives or to accommodate accommodate changes in legislative requirements etc. However, there is no project until the project is approved and funded by management. management. To achieve this the proposed project must be embodied in a structured way. It is imperative that the business objectives of the project are in line with the Monash Vision. How is a project defined? A Project Concept document must be completed for all intended projects. The information provided will enable senior management to review the relative merits and pr iorities of proposed projects and deter mine whether or not they should proceed. The Project Concept contains an outline of the project detailing the scope and objectives, strategic impact and benefits, a high-level risk assessment and estimated on-going production costs of the project to the University. What information is contained in the Project Concept? The following sections of the Project Concept must be completed: Project Description A broad overview of the project Scope and Objectives A description of the proposed boundaries of the project, e.g. pilot project, functionality delivered, client base, technical architecture and the business or technical goals the project aims to achieve Benefits A summary of expected benefits to be achieved Status The stage of the project relative to the service life-cycle i.e. a new initiative or the project is building upon the work of previous projects Stakeholders / Clients The client group for which the project is being undertaken and the main beneficiaries of the project Resources A brief summary of required skill sets, estimated time requirements, team structure (internally staffed or additional external contract staff and/or consultants required) and their roles Project Cost Estimate An initial estimate of one-off project costs plus recurrent operational costs Risk Assessment A summary of the major risks that may impact the project’s success Related Projects / Systems A list of other projects or existing systems that have a relationship to th is project Other comments Any other information that is relevant in supporting the case for project funding and prioritisation including any known constraints and assumptions, i.e. information that is uncertain at this stage, but assumed as fact for planning purposes


How is a project approved? In the normal course of events projects are identified as part of the annual IT strategic planning process. These projects are documented using the P roject Concept template and included in the annual IT Programme Portfolio. The Project Concept is initially reviewed by the Project Office to ensure its contents are complete and contains a sound business case and is then included in the Programme Portfolio and qualifies for prioritisation. Project Concepts within the Programme Portfolio are prioritised and ranked by deans, divisional heads and IT Services Directors based on their strategic and operational importance. Review of the prioritised Programme Portfolio is then undertaken by the Vice-Chancellors’ Group, who approves the annual IT development project budget taking into account wider university funding priorities. Once the budget is approved the project is ready to be planned in more detail in line with the first phase of the project management methodology outlined in Section 3.

Inputs to the IT Strategic Planning Process

Consult Consult with Faculties Faculties and Divisions Divisions

Priorities from Planning Conference

University Plans

University-wide Support Priorities

University Planning Conference

Support Services Planning Workshop

IT Strategic Planning Seminar

IT Developments in Progress

ITS Divisional Issues

CHEQ Review of Services

IT Strategic Plan Update

IT Development Portfolio

ITS Operational Plan

ITS Operational Budget

(for next year)

Prioritise Development Portfolio

Development Portfolio Budget

IT Service Impact Report


3.

Project Management Methodology

What is a project management methodology? A project management methodology is a structured set of activities and processes that provides a checklist for developing and implementing projects in a standard, consistent manner. manner. Methodologies are aligned with best practice techniques and methods, and contribute to the achievement of quality deliverables. What is Monash’s Project Management Methodology? Whilst there are different methodologies with associated tasks according to the type of project (e.g. inhouse developed system, SAP implementation, infrastructure upgrade), this guide outlines a common framework that can be followed for most Monash IT projects. The project management methodology comprises three phases: Phase 1: Project Planning Development of a Project Charter and various project plans. Phase 2: Project Execution Development and implementation of the project deliverables. Phase 3: Project Conclusion Post-implementation activities and benefits realisation monitoring.

Phase 1: Project Planning

Phase 2: Project Execution

Phase 3: Project Conclusion

Project Execution Plan

Project Charter Benefits Realisation Plan Risk Management Plan Quality Plan

Service Statement Post Implementation Review

Technical Specification IT Continuity Plan

Testing Plan

Communications Plan

Training Plan

Implementation Plan Production Support Plan

Figure 2: Project Plans/Documents


Project Management @ Monash

Phase 1: Project Planning

"A three phased approach". Figure 3: A roadmap expanding the planning, execution and conclusion phases

1.1 Appoint Project Sponsor 1.2 Appoint Project Manager 1.3 Establish Steering Committee 1.4 Review Project Concept 1.5 Define Detailed Scope & Objectives 1.6 Define Benefits 1.7 Develop Benefits Realisation Plan 1.8 Identify Success Criteria 1.9 Identify Constraints and Assumptions 1.10 Define Technical Framework 1.11 Identify Support Arrangements 1.12 Define Project Approach

1.13 Develop High Level Project Schedule 1.14 Allocate Project Personnel

Phase 2: Project Execution

1.15 Review Project Cost Estimates 1.16 Develop Risk Management Plan 1.17 Establish Reporting Procedures 1.18 Develop Quality Plan

2.1 Set Up Project Environment

1.19 Develop Communications Plan

2.2 Conduct Kick-off Meeting

1.20 Complete Project Charter

2.3 Develop Project Execution Plan

1.21 Approve Project Charter

2.4 Establish Issues Management Process 2.5 Define Detailed Requirements 2.6 Develop Technical Specifications 2.7 Develop IT Continuity Plan 2.8 Establish Change Process

2.9 Perform Project Tasks 2.10 Develop Testing Plan 2.11 Develop Training Plan 2.12 Develop Implementation Plan 2.13 Plan Production Support Framework 2.14 Implement Project

Phase 3: Project Conclusion

2.15 Obtain Final Sign-off

3.1 Decommission Obsolete Systems 3.2 Perform Post-implementation Post-implementation Review 3.3 Monitor Benefits Realisation 3.4 Implement Service Statement 3.5 Celebrate Project Completion


Phase 1: Project Planning Once the Project Concept has been approved, the detailed planning of the project commences. The major deliverable of this phase is the Project Charter, which defines the scope, objectives, plans and other significant aspects of the proj ect at a more detailed level than the Pro ject Concept. The Project Charter defines the terms of reference of the project and acts as a ‘contract’ between the Project Manager and Project Sponsor. It also forms the basis for future change control. The following sections of the Project Charter should be completed. The Project Concept should be used as a starting point in developing the Project Charter with additional information added where required: Project Responsibilities •

A list of senior project personnel, viz. Project Sponsor, Project Manager, IT Director, Steering Committee members

Service Responsibilities •

A list of people responsible for various areas of the completed product or service, e.g. ITS Service Manager, IT support, benefits monitoring, business support

Background / Overview •

A broad overview of the key business issues that the project will address and the main driver(s) of the change

Strategic Objectives •

The Monash strategic objectives with which the p roject is aligned

Project Objectives •

The business or technical goals the project aims to achieve

Benefits •

The returns or payback expected to be obtained from the successful completion of the project

Scope •

The functional, technical and other dimensions that determine the project’s size and the effort required

Success Factors •

The factors by which the success of the project will be measured

Stakeholders •

A list of the people who provide expertise, resources or technology to the project team, and the clients of the final product or service

Technical Framework •

Identified technical elements, eg. hardware platform, development software, network protocol, application architecture, interfaces with other systems, security considerations

Related Projects •

A list of projects that are impacted by, or impact on, this project

Approach •

The development strategy for the proj ect, including milestones, deliverables and estimated timelines

Constraints •

Limitations such as specific timing, resource or budgetary issues that may impact the project

Risks •

A summary of the major risks that may impact the project’s success, together with an overall risk rating


Costs •

An estimate of direct resource costs, including personnel, software, hardware and post-project operational costs

Funding Arrangements •

The source of funding for the project, including development work and production support/operations

Quality Plan •

The steps to be taken, and standards to be adopted, to meet agreed quality requirements

Communications Plan •

The plans and methods of communicating project activity (including development plans, progress and status) to stakeholders and the wider university community

Relevant Legislation / Policies •

Government and/or other legislation and policies that must be taken into account

Staff Impact / Change Management •

Major impacts on staff work practices and procedures

Assumptions •

Information that is uncertain at the start of the project, but assumed as fact for planning purposes, eg. availability of resources, successful completion of predecessor projects

3 Year Budget Projection •

The standard costing model outlining the project budget estimates, including operational costs over a three year period

Risk Management Plan •

A formal plan of the strategies for containing and managing project risk

Benefits Realisation Plan •

A formal plan listing the expected benefits and key actions for monitoring their realisation with associated timelines, measures and responsibilities.

It is important that the Pr oject Charter represents a complete and accurate record of the project’s scope, objectives and parameters, and may therefore require a number of iterations until approved. It is also important that the Charter provides a level of detail that is appropriate for the project. A project that has a significant University-wide impact will requir e a detailed communications plan provided as an Appendix to the charter. A project that has few stakeholders and little or no impact may need only a relatively short description contained in the charter document. Give all some sections some consideration and as always if you find yourself struggling over a particular section contact the ITS Planning and Project office via [email protected].


1.1

Appoint Project Sponsor

Before a project can commence, commence, a Project Sponsor must be appointed. appointed. The Project Sponsor should be a senior manager having the financial and organisational power to act quickly and decisively in the overall governance of the project. It is an active, hands-on role, requiring a supportive working relationship with the Project Manager and effective communication with major stakeholders. stakeholders. The Project Sponsor should have a broad knowledge of the University including experience and expertise in the functional areas addressed by the project. The role of the Project Sponsor is critical in ensuring the success of IT projects. An inappropriate choice of Project Sponsor can seriously impact the possibility of success of the overall project. In fact, a project without the appropriate degree of executive sponsorship will almost always fail. For a large project it is often practical to share the project sponsorship role by appointing a 'hands on' sponsor to represent the project at the 'team' level under the guidance of an Executive Sponsor. In this case, the Executive Sponsor would provide the financial support and overall direction to the the project. The Executive Sponsor would be a senior executive of the University (e.g. Deputy Vice-Chancellor, dean, Executive Director), and be responsible for approving the project budget and negotiating the funding arrangements. He or she would select the most appropriate 'hands on' sponsor for the project.

1.2

Appoint Project Manager

Each project is managed by a Project Manager, reporting to the Project Sponsor for the duration of the project. The Project Manager is responsible for the the day-to-day management and direction of the project team and retains a ‘dotted line’ r esponsibility to his or her functional manager. The skill requirements for the ro le include the ability to plan, delegate, communicate, influence decisionmaking and manage relationships. Practical or theoretical knowledge of the project subject matter is also also an advantage. The Project Manager must ensure that the processes of project planning, tracking and reporting are undertaken in a rigorous manner.

1.3

Establish Steering Committee

The Project Steering Committee represents, at an executive level, the critical stakeholder groups (i.e. those most impacted by the objectives of the project) in the overall governance of the project. The chair will usually be the Project Sponsor. Steering Committees would normally be required for projects having a wide cross-section of essential stakeholders, ensuring vital representation and participation in decision making by all groups. The Steering Committee is responsible for directing and assisting the Project Sponsor and Project Manager in defining the scope, objectives, objectives, benefits and other key aspects aspects of the project. It also has the responsibility for approving the completed Project Charter. All subsequent major changes to the project such as significant cost increases, extended timelines, increased scope and changes to objectives must be approved by the Steering Committee. It may also be called upon when significant project business decisions are required, especially of a cross-fun ctional nature. It is recommended that the Steering Committee comprises no more than eight members, including the Project Sponsor and Project Manager.

1.4

Review Project Concept

When the Project Sponsor and Project Manager begin planning the project they should review the original Project Concept that was approved for budget. Considerable time may have elapsed since the Project Concept was developed, and var ious components of it may need to be revised in the Project Charter.


1.5

Define Detailed Scope and Objectives

The establishment of clear objectives or goals is essential for the success of the project. Objectives should be specific, measurable and aligned with the strategic goals of the University. They state what is going to change in the status quo of the business, process, product or system to achieve a desired outcome. When defining objectives, it is often useful to keep in mind the benefits that the project aims to deliver. The project scope defines the boundaries in which the objectives must be achieved. This may include the level of functionality, timelines, locations, client groups, resources, or other dimensions within which the project is undertaken. For clarity, it is also often useful to specify what is out of scope. To ensure a clear and common understanding, the scope and objectives should be defined jointly by the Project Sponsor and Project Manager, with input from stakeholders and the Steering Committee. It may be useful to hold a Rapid Planning or ‘RAP’, session at this stage. The Project Management Framework contains tools for use during RAPs, and the ITS Planning and Project Office is available to assist or suggest how to facilitate such a session.

1.6

Define Benefits

Once the scope and objectives are clearly defined, detailed benefits can be identified. Where possible, benefits should be quantified so that achievement of the benefits can be measured after the project is implemented. It is the responsibility of the Project Sponsor to ensure benefits are defined and processes are implemented to monitor their realisation. Some projects will have strategic or intangible benefits only. These should be clearly identified and aligned with the relevant strategic objectives from Monash’s IT Strategic Plan.

1.7

Develop Benefits Realisation Plan

It is the Project Spo nsor’s responsibility to review the measurement of pr ogress toward achievement of the benefits against the expected outcomes. The Benefits Realisation Plan (BRP) is the one project management document that stays 'live' long after the project has completed (and delivered the primary benefits) and contains the 'contracts' with key stakeholders to monitor the delivery of on-going benefits during the Return On Investment period. The BRP lists key actions with associated timelines, measures and responsibilities. It is important to be able to show as soon as possible how the system or service provided by a project is faring. The degree of realisation of benefits may may form the basis for future planning decisions, decisions, e.g. whether to make further investment in the service. Positive benefit realisation will demonstrate value for money and engender confidence in future IT projects.

1.8

Identify Success Criteria

Project success is determined from the desired o utcomes of delivering quality results, meeting budget and schedule, and providing customer satisfaction. Project success factors should be identified, categorised and weighted by level of importance. Critical success factors should be highlighted, and be associated by measurable outcomes. It is important, where possible, to gather benchmark data before implementation of the project, so that outcomes can be measured against ‘pre-project’ data t o evaluate the success of the project.


1.9

Identify Constraints and Assumptions

Constraints are specific management or technical limits that are part of the environment in which the project must be developed. Typical constraints include fixed deadlines, fixed resources, fixed costs, organisational standards or fixed technology. In the Monash environment specific project project activities may may need to be scheduled around the University Principal Dates and other student-related activities. Key project assumptions should also be documented in the Project Charter, as the project schedule may need to be altered at a later stage due to assumptions being found to be incorrect. Some of the issues related to constraints and assumptions may also need to be reflected in the risk assessment.

1.10

Define Technical Framework

At this stage, once the scope and objectives have been defined, the overall technical framework should be outlined. This will usually be at a high level, as the detailed requirements analysis will not yet have been performed. There are various technical elements that can be agreed on at this point, e.g. hardware platform, development software, network protocol, application architecture, interfaces with other systems, security considerations.

1.11

Identify Support Arrangements

When costing projects, on-going support costs must be taken into account. So before the project commences it is important to identify the level of support required for the system, product or service, and the responsibility for providing the support and meeting its associated costs. For new systems it is important to id entify a business or functional owner to oversee the maintenance and management of the system system in the production environment. They would be responsible for approving major modifications and enhancements to the system.

1.12

Define Project Approach

The selection of the project development strategy is one of the most important decisions made during the planning process. The strategy determines the overall overall approach to the progression of the project and and the delivery of outputs. Various strategies provide alternative approaches that have different dynamics and organisational impact. Options for consideration include concurrent versus sequential development, fast tracking and prototyping. The choice of strategy is dependent pr imarily on three factors: project risk, team size and development time. For example, the fast-track strategy is suitable for projects with a large team and a short time frame. High-risk projects generally take a longer development development approach, usually with a staged staged or sequential strategy. It generally makes sense to structure the project so that interim deliverables can be produced. This increases the visibility of the project’s progress, and has the effect of maintaining a high level of commitment from stakeholders.

1.13

Develop High Level Project Schedule

After the project development strategy has been determined, a high level project schedule can be prepared. This should include the work breakdown structure of major major tasks, project milestones and key deliverables together with their estimated dates, and the scheduled project completion date.


1.14

Allocate Project Personnel

Once the project tasks and required skills have been identified, the appropriate people need to be assigned to the project. There are often difficulties in this process, process, as many people with the necessary skills may not be able to fully devote their time to the project due to other responsibilities. It is useful to obtain a written agreement from the appropriate Manager or Director specifying a particular team member’s availability availability to work on the project. Often it may be necessary necessary to hire contractors to perform certain tasks due to the unavailability of Monash staff or lack of in-house expertise.

1.15

Review Project Cost Estimates

The estimated project costs should be reviewed r egularly as information comes to hand, especially if the preparation of the Project Charter requires a number of iterations. If a revised estimate differs significantly from the approved project budget, the Project Sponsor should be alerted. In some cases aspects of the project may need to be modified, e.g. the project scope reduced, the approach redefined or resources reallocated. The Project Sponsor should provide guidelines to the Project Manager as to the circumstances when they need to be informed, e.g. by indicating a percentage cost overrun. Project budget estimates should be updated using the Project Costing Model, taking into account project and ongoing costs for a 3 year horizon. It is imperative that a rigorous estimate is provided for the full cost of the project at least 3 years ahead to assist in forward budget planning.

1.16

Develop Risk Management Plan

Risk management is intended to introduce rigour in to a project plan by identif ying the risks associated with the project, and by proactively managing them in order to attain the project objectives. Project risk factors should be identified, analysed and prioritised in order to determine the actions required to reduce or constrain the risk before the project commences. The Risk Management Plan should include a description of the risk, the impact of the risk on the project, and the actions that can be taken to mitigate the risk. Risk can change as the project progresses. It is possible for a project initially assessed as low risk to quickly escalate into a high-risk project. Therefore project risks should be monitored and reviewed on an ongoing basis.


1.17

Establish Reporting Procedures

Regular reporting to the project stakeholders is an important aspect of any project. At the outset, the Project Manager and Project Sponsor should agree on the type of reporting and frequency during the course of the project. Formal reporting by the Project Manager to the Project Sponsor or Steering Committee may include the following items: 



   

 

General status including an overview of all phases and streams of activity occurring within the project Tasks completed and milestones achieved, as well as the completed percentage of tasks which are in progress Planned tasks and estimated completion dates Changes in scope, objectives, timelines, costs or personnel Outstanding issues, and any impacts which may result from them The results of action items which may have been identified in the last report, or at the previous Steering Committee meeting The results of any Quality Assurance reviews which have been undertaken Actual costs versus budget allocation.

A Monthly Project Report must also be submitted to the Project Office throughout the project’s development. This report highlights any significant changes that have occurred to the project’s scope, scope, objectives, timelines, costs and resources during the prior month. It is also used to document document any issues that need to be escalated to the ITS Directors’ group.

1.18

Develop Quality Plan

The purpose of a Quality Plan is to ensure the integrity of the project deliverables. The Quality Plan maps out the steps that need to be taken, and standards that need to be adopted, to meet the agreed quality requirements. The Plan should include the frequency and reporting requirements for quality assurance processes such as technical reviews, inspections, walkthroughs and audits.

1.19

Develop Communications Plan

Communications planning involves determining the information and communications needs of the project stakeholders at various stages of the project. The management of expectations amongst stakeholders is a key role of the Project Manager. Where the project will impact on jobs and and work practices, regular and open communication is essential. The Communications Plan should include a list of proposed communication activities and associated timelines and stakeholders. Forms of communication could include presentations to various committees, committees, emailed newsletters, the development of a project web site, article in Monash Memo, etc.

1.20

Complete Project Charter

Once the above tasks have been carried out, the Project Charter can be completed. Some sections of the Project Charter may be developed in in parallel. Sections may require reiteration in the light of development in other sections, e.g. scope and objectives may require adjustment when all stakeholders are identified. This in turn would influence subsequent plans plans and resource requirements such as as the composition of the project team. When the Project Charter has been completed copies are distributed to the personnel indicated in the charter distribution list.


1.21

Approve Project Charter

The Project Charter should be agreed to and formally signed off by the Project Sponsor and/or Steering Committee. Following approval, significant changes to the Project Charter cannot be made without agreement from the Project Sponsor or Steering Committee. Committee. A copy of the approved Project Charter Charter must be filed with the Project Office, along with other key project documents.

Phase 1: Project Planning has now been completed including the development of the Project Charter, Benefits Realisation Plan, Risk Management Plan, Quality Plan and Communications Plan. Once these documents are complete and the Project Charter has been signed off, development work on the project may commence within Phase 2: Project Execution.


Phase 2: Project Execution 2.1

Set Up Project Environment

To facilitate the activities of the project team, its physical and IT environment must be set up ready for work. Accommodation for the project team must be finalised, preferably with all team members within close proximity to one another. Workstations should be purchased or leased, and configured with the necessary software prior to the project team team commencing work. Consideration will need to be given to access rights to shared directories, networks, applications, etc. Administrative guidelines should also be established at the beginning of the project, e.g. naming conventions, storage of documentation, internal procedures. For large teams, it may may also be worthwhile implementing implementing a system to enhance communications between team members, e.g. groupware, document management system, collaborative web publishing system.

2.2

Conduct Kick-off Meeting

A kick-off meeting should be held to formally start the project. This brings the project team together to clarify and confirm the roles and responsibilities of all team members to avoid any potential confl icts during the course of the project. The kick-off meeting can also be used to resolve any initial issues issues or questions regarding the project and clarify reporting lines. The Project Manager should also provide an outline of the immediate and long-term proj ect plans. To reduce project uncertainty, open channels of communication are necessary. This can be achieved by holding regular team meetings. During the kick-off meeting the Project Manager and team should define the meetings schedule.

2.3

Develop Project Execution Plan

For most projects it is useful to hold a RAP (RApid Planning) session as a starting point in developing the Project Execution Plan. As many project team members as possible should attend to gain ‘buy-in’ and promote a feeling of team “ownership” of the project plan. Tasks, estimates and deliverables are identified, from which the Project Manager creates a project schedule or Work Breakdown Structure. This includes identifying task dependencies and allocating r esources. The sequence of activities that determine the pro ject completion date is called the critical path. The critical path is the path of longest duration through the network of dependent tasks. Any delay in critical path activities will delay the completion of the project. Therefore, to keep the project on track, it is especially important to monitor the progr ess of tasks on the critical path. At this point it is also necessary to review the estimated project costs now that more specific information is at hand regarding personnel resources and and timelines. If this estimate proves to be significantly different from that given in the Project Concept and Charter, it should be reviewed by the Project Sponsor.

Critical Path

Task A 8 hours effort 2 days

Task B 1 2 h o u r s e f f o rt rt 3 days

Task D 4 hours effort 1 day

Task C 8 hours effort 2 days

Figure 4: Example of Critical Path


2.4

Establish Issues Management Process

There are nearly always unforeseen issues that arise during the course course of a project. Issues can surface internally from team members or externally from other projects or groups, business units, vendors and management. It is the Project Manager’s responsibility responsibility to ensure that these are documented, analysed and resolved satisfactorily to avoid any any delays to the progress of the project. When issues are addressed, then the project risk is usually reduced and the chance of success success increased. Establishing an issues database is a useful way of logging and tracking the progress of issues.

2.5

Define Detailed Requirements

One of the major activities of a project is the identification, analysis and definition of the functional and/or technical requirements. This is where a significant amount of time and effort is spent with stakeholders in determining the detailed business needs, and then translating them into technical solutions. There often needs to be a balance balance drawn between the delivery of a particular requirement and the complexity, cost and effort in implementing it.

2.6

Develop Technical Specifications

Many IT projects require advanced technical solutions. Issues to be considered in the technical solution include security and controls, hardware platforms, application architecture, database design and sizing, data configuration, development of interfaces, network topology, backup and recovery procedures, etc. The proposed technical solution should be clearly documented and reviewed and signed off by the appropriate ITS managers to enable the groups involved to support its implementation. The Technical Requirements checklist should be used to ensure relevant technical issues are considered.

2.7

Develop IT Continuity Plan

A project implementing a new service must be accompanied by an IT Continuity Plan describing the actions to be taken in the event of the service failing. A project where an existing service is being upgraded or modified in some way should already have an IT Continuity Plan, which may need revising. If a Plan doesn’t already exist, it will need to be developed. The Plan should address the IT components required in the delivery of a service such as the application, hardware, network infrastructure and data. It should include resource needs such as people, hardware, software and data, along with the tasks to be performed and the persons responsible for those tasks. The IT Continuity checklist should be used used as a guide to developing the Plan. The IT Continuity Plan must be signed off by the ITS Continuity Analyst prior to project implementation.

2.8

Establish Change Control Process

It is necessary at the beginning of a project to agree on a mechanism for change control. control. During the Project Execution phase it is often the case that requests are made from various stakeholders to include extra functionality outside the boundaries of the Project Charter. These are usually extra requirements or additional scope, but may also be changes to objectives or technical configuration. A change control process involves evaluating requests that alter the current project plans, and ensuring that those changes are beneficial beneficial and effectively managed so that the project is kept under control. The process would need to incorporate structured approval and communication procedures. Without effective change control, a continuing accumulation of requested changes will have a negative impact on a project’s schedule and cost.


2.9

Perform Project Tasks

Once the specifications have been documented and agreed on, the development project work commences. Depending on the type of project, this could include programming, configuring and implementing a software package, reengineering business processes, building a database, upgrading a network infrastructure, etc. At this stage of the project it is important for the Project Manager to closely monitor the progress in terms of time and cost, and also t o ensure that quality standards are maintained.

2.10

Develop Testing Plan

The implementation of a new product, application or service needs to be comprehensively tested befor e going live. A Testing Plan should be prepared in advance of the testing activity. The Testing Plan should cover the types of testing to be conducted, and will vary according to the type of project. A new system or application will generally need several levels of testing to be conducted, e.g. unit testing, system testing, integration testing, user acceptance testing. The Plan should include a list of all individual tests to be conducted together with the corresponding expected results. For many projects, especially those requiring infrastructure enhancements, there will be a need for stress, volume and/or performance testing. A regression testing plan may need to be developed for use in the production support environment. This would comprise a standard set of functions or paths to be tested. When modifications or enhancements are implemented, the regression test should be conducted to ensure all parts of the system, and other systems that may be impacted, perform as expected.

2.11

Develop Training Plan

When a new product or system is implemented, the clients usually need to be trained in its operations. A Training Plan should be developed to ensure the training is conducted in a timely and effective manner. Training may be conducted externally or in-house, and facilities will need to be organised well in advance. For a large system such as SAP, training may need to be an ongoing activity, so appropriate schedules should be developed.

2.12

Develop Implementation Plan

An Implementation Plan is a detailed schedule of all tasks, responsibilities and sequence of processes that need to be performed when going live. Its focus is on the several days or weeks leading up to to the ‘go live’ date, and is generally at a detailed ‘process’ level. It is advisable to conduct a ‘readiness review’ prior to implementation. This is a checklist of all major project tasks and their outcomes or deliverables. Any outstanding issues should be assessed, and a decision made on whether or not to proceed with the implementation. Items to consider when going live are the selection of a suitable cutover date, the conversion of existing data, the availability of critical resources and the method and timing timing of communications to stakeholders. stakeholders. The Pre-Implementation checklist can be used as a guide to assessing the readiness of the project implementation. Also, a contingency plan may need to be developed in case the production system needs to be rolled back for any reason.


2.13

Plan Production Support Framework

Prior to the system going live, it is essential that the appropriate support structure and procedures be in place. A Support Plan should be developed to identify the skill levels and number number of people required to support the production system, from both a functional and technical aspect. The support hours and level of support should also be defined, e.g. business hours or extended operations, on-site or on-call. If people other than members of the project team provide the support, then a training or handover process will need to be instigated well before the implementation date. At least three months in advance of the implementation of the project, the Proj ect Manager, Finance Manager and Project Office must prepare a submission of the ongoing costs to support the service and the relevant budget implications. If the outcome of the project is a new or enhanced service, then the Project Manager, in consultation with other ITS managers and stakeholders, should draft the service specifications that will govern the maintenance and support of the IT service. This must be done using the Division’s Service Statement form. In addition, an assessment would be required to determine how this service service fits within the ITS Services Catalogue (e.g. is it a new service, in which group of services does it belong, is it an enhancement to an existing service?).

2.14

Implement Project

When the time has come to ‘go live’ it is essential that all key project people are available to perform their allocated tasks, and that a detailed step by step plan has been developed and is followed. Once the system, product or service is installed, a final test should be conducted. As a last resort, the contingency plan may need to be implemented with associated rollback or recovery procedures.

2.15

Obtain Final Sign-off

When the project has been i mplemented successfully, a formal approval must be obtained from the Project Sponsor and Steering Committee. Because the system or service has been moved to the production environment, it does not necessarily mean there is no more required activity on the project.

The next phase (Project Conclusion) outlines several activities that may need to be undertaken post-implementation.


Phase 3: Project Conclusion 3.1

Decommission Obsolete Systems

Often a new system or product replaces another one, so steps need to be taken to decommission the previous system or product. This may mean termination termination of licensing or leasing agreements and disposal of assets associated with the old system. Historical data may need to be archived in accordance with university policy and legislative requirements.

3.2

Perform Post-implementation Review

The Post-implementation Review (PIR) is an evaluation of the project’s goals and outcomes as measured against the Project Plan, budget, t imelines, quality of deliverables, specifications and client satisfaction. The objective of the PIR is to identify the lessons learnt from the project and to share the information to improve the performance of future projects. It is important to hold a PIR soon after implementation, before the project team disperses. This would normally involve participation by the Project Manager, Project Sponsor, critical stakeholders and key team members. The PIR is conducted by the ITS Project Office. The first step is the distribution of a questionnaire to selected project personnel and clients of the final product or system. This will enable important information about the conduct of the project to be quickly collected. Follow up interviews or workshops may be necessary to further explore certain areas or issues. A report will be written by the Project Office consisting of overall information about the project's success, organisation, resourcing, budgeting, problems encountered, ongoing support issues and achievements.

3.3

Monitor Benefits Realisation

The Project Sponsor is accountable for the project delivering the benefits that were identified in the Project Charter. It is the responsibility of the Project Sponsor to monitor the realisation of the benefits benefits once the project has been implemented. implemented. Monitoring should begin soon after project implementation implementation and sign-off, in accordance with the Benefits Realisation Plan. It is important to be able to show as soon as possible how the system or service provided by a project is faring. The degree of realisation of benefits may may form the basis for future planning decisions, decisions, e.g. whether to make further investment in the service. Positive benefit realisation will demonstrate value for money and engender confidence in future IT projects.

3.4

Implement Service Statement

The Service Statement is an ongoing service ‘contract’ between ITS and its client group(s) or organisational unit(s). It provides specifications of what the service entails, its delivery, performance measures, and any other details relevant to the service. It is the responsibility of the designated designated ITS Service Manager to monitor and manage all aspects of the Service Statement, working closely with key managers of the client group.

3.5

Celebrate Project Completion

Whether it be a formal product launch or an informal gathering, a project completion celebration is a great way to mark the end of what may have been a challenging experience for those involved.


Appendix Glossary Benefits

The returns or payback expected to be obtained from the successful completion of the project. Benefits can be tangible or intangible. Tangible benefits include reduced or avoided costs for existing procedures and increased revenue from new or improved products. Intangible benefits may include improved improved service to clients or improved improved competitive position.

Constraint

Any known restrictions or limitations that may impact on the project, eg. insufficient funding, immovable implementation date etc.

Critical Path

The sequence of inter-dependent tasks that aggregate to determine the minimum duration of the project. A delay in any task on the critical path can have a significant impact on the project deadline.

Critical Task

A task on the project's critical path.

Deadline

The expected date upon which the project must have completed the development and implementation of the required outcomes.

Deliverable

An output produced at the end of a task. Examples of deliverables are plans, reports, computer programs, policies and procedures etc.

Estimate

An informed prediction based on formal or documented experience or metrics. In the project context, estimates are made of effort ( people's time), costs and benefits.

GANTT Chart

A chart that shows the duration of tasks against the project time-frame. time-frame. It usually highlights milestones, dependencies and resources associated with particular tasks.

Milestone

A major checkpoint in a project. Examples of milestones are are 'Design Phase Completed ', 'User documentation completed', 'Hardware configured'. Milestones often require sign-offs from the Project Sponsor or Steering Committee before proceeding.

Objectives

A statement of what the project is designed to achieve within the scope. They should be specific, measurable and identify business problems that are being solved. They should be stated with some benefit or end r esult in mind.

PERT Chart

A chart that displays the sequence of tasks that form the project schedule. PERT charts are particularly useful for highlighting a project's critical path.

Post Implementation Review

An evaluation of the project’s goals and activity achievement as measured against the project plan, budget, timelines, quality of deliverables, specifications and client satisfaction. The objective of the PIR is to identify the lessons learnt from the project and to share the information to improve the performance of future projects.

Project

A group of tasks that are inter-related and are designed to change existing organisation structure, procedures, policy, systems or environment.

Project Approach

The approach to the way a project will be conducted eg. fast-track (minimum set of activities undertaken to implement the project quickly), concurrent development (breaking the project down into sub tasks that are developed in parallel).

Project Charter

A formal document that summarises the business, management and financial aspects of a project. It includes scope, objectives, benefits, costs, risks and plans. It is the basis of project change control and serves as a 'contract' between the Project Manager and Project Sponsor.


Glossary cont. Project Concept

The initial project document that provides an outline of proposed projects detailing the scope, objectives, risks, benefits, costs and strategic impact of the project to the University. Project Concepts for proposed projects form the IT Programme Portfolio which is reviewed and prioritised by university management as part of the budget planning process

Project Management

A professional discipline combining systems, techniques and people to achieve a business objective within defined parameters of time, budget and quality.

Project Management Methodology

A structured set of activities and processes that provide a checklist for developing and implementing projects in a standard, consistent manner. Methodologies are aligned with best practice techniques and methods, and contribute to the achievement of quality deliverables.

Project Manager

The person responsible for the day-to-day management of a project to ensure that the outcomes are realised on time and within budget. Typically this involves rigorous planning and tracking, proactive client relationship management, team leadership and dynamic problem resolution.

Project Risk

A measured estimate estimate of the likelihood that a project will fail. The higher the risk, the higher the probability of the project failing. Risk is analysed as part of the project planning process.

Project Sponsor

A senior manager who is the key stakeholder representative for the project. The Project Sponsor may be the initiator of the project and provides the necessary 'business' support for the Project Manager. The Project Sponsor usually signs off various deliverables and milestones.

Rapid Planning

An intensive and participative planning session involving project manager, project team and key stakeholders. Sometimes referred to as RAP RAP session.

Related Project

A related project is a project that is either dependent on, interdependent with or is prerequisite to the project.

Risk Assessment

A process of identifying factors th at may impact on the success of the project.

Risk Management Plan

A formal plan of the strategies for containing and managing project risk.

Schedule

A graphic representation of tasks, dependencies between tasks and task durations against a calendar. Sometimes referred to as the Project Plan or Project Timeline.

Scheduling Tools

Computer software that provides automated support for developing schedules, Gantt Charts, critical paths, resource utilisation and various reports to enable the Project Manager and team to evaluate resource loading, costs and progress.

Scope

The boundaries of the project relating to functional, technical and other dimensions (eg. geographical) that determine the project's size and effor t required.

Stakeholder

A person who provides advice, expertise, resources or technology to the project team and who is outside the direct administrative responsibility of the Project Manager.

Steering Committee

A representative group of senior managers who are responsible for approving major changes to the project's scope, objectives, timelines, costs, costs, etc. The Steering Committee directs and guides the project manager when significant project business decisions are required, especially of a cross-functional nature. The Steering Committee can also be called upon to prioritise activities if necessary.


Project Management Methodology

Recommend Documents