You are on page 1of 22

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
3. Project Management Methodology ................................................ 4
Phase 1: Project Planning………………………………………………6
1.1 Appoint Project Sponsor ...................................................................................... 8
1.2 Appoint Project Manager ..................................................................................... 8
1.3 Establish Steering Committee .............................................................................. 8
1.4 Review Project Concept ....................................................................................... 8
1.5 Define Detailed Scope and Objectives ................................................................. 9
1.6 Define Benefits ..................................................................................................... 9
1.7 Develop Benefits Realisation Plan ....................................................................... 9
1.8 Identify Success Criteria ...................................................................................... 9
1.9 Identify Constraints and Assumptions ................................................................ 10
1.10 Define Technical Framework ............................................................................. 10
1.11 Identify Support Arrangements .......................................................................... 10
1.12 Define Project Approach ................................................................................... 10
1.13 Develop High Level Project Schedule ................................................................ 10
1.14 Allocate Project Personnel ................................................................................ 11
1.15 Review Project Cost Estimates .......................................................................... 11
1.16 Develop Risk Management Plan ........................................................................ 11
1.17 Establish Reporting Procedures ........................................................................ 12
1.18 Develop Quality Plan ......................................................................................... 12
1.19 Develop Communications Plan .......................................................................... 12
1.20 Complete Project Charter .................................................................................. 12
1.21 Approve Project Charter .................................................................................... 13
Phase 2: Project Execution ................................................................... 14
2.1 Set Up Project Environment .............................................................................. 14
2.2 Conduct Kick-off Meeting .................................................................................. 14
2.3 Develop Project Execution Plan ........................................................................ 14
2.4 Establish Issues Management Process ............................................................... 15
2.5 Define Detailed Requirements ........................................................................... 15
2.6 Develop Technical Specifications ...................................................................... 15
2.7 Develop IT Continuity Plan ............................................................................... 15
2.8 Establish Change Control Process .................................................................... 15
2.9 Perform Project Tasks ....................................................................................... 16
2.10 Develop Testing Plan ......................................................................................... 16
2.11 Develop Training Plan ....................................................................................... 16
2.12 Develop Implementation Plan ............................................................................ 16
2.13 Plan Production Support Framework ............................................................... 17
2.14 Implement Project .............................................................................................. 17
2.15 Obtain Final Sign-off ......................................................................................... 17
Phase 3: Project Conclusion ................................................................. 18
3.1 Decommission Obsolete Systems ....................................................................... 18
3.2 Perform Post-implementation Review ................................................................ 18
3.3 Monitor Benefits Realisation ............................................................................. 18
3.4 Implement Service Statement ............................................................................. 18
3.5 Celebrate Project Completion……..……………………………………………. 18
Appendix ................................................................................................. 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 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 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. It may involve the introduction of a new service, the
enhancement of an existing service or the improvement of efficiencies of current processes. In some
cases however, projects may be initiated due to external 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
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 problem
solving processes designed to recognise and solve problems as they arise, and also to proactively
anticipate and avert potentially 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 in response to changes in
university objectives or to accommodate changes in legislative requirements etc. However, there is no
project until the project is approved and funded by 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 priorities of proposed projects and determine
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 this 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

____________________________________________________________________________________________
Project Management @ Monash Page 2
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 Project 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 with Faculties and Divisions

Priorities from IT Strategic IT Development Prioritise


University-wide Development
Planning Plan Portfolio Development
Support Priorities Portfolio Budget
Conference Update Portfolio
(for next year)

University Support Services


University IT Strategic IT Service
Planning Planning
Plans Planning Seminar Impact Report
Conference Workshop

CHEQ
IT Developments ITS Divisional ITS Operational ITS Operational
Review of
in Progress Issues Plan Budget
Services

____________________________________________________________________________________________
Project Management @ Monash Page 3
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. 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. in-
house 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: Phase 2: Phase 3:


Project Planning Project Execution Project Conclusion

Project Execution
Project Charter Service Statem ent
Plan
Post
Benefits Technical
Im plem entation
Realisation Plan Specification
Review
Risk Managem ent
IT Continuity Plan
Plan

Quality Plan Testing Plan

Com m unications Training Plan


Plan

Im plem entation
Plan

Production
Support Plan

Figure 2: Project Plans/Documents

____________________________________________________________________________________________
Project Management @ Monash Page 4
Project Management @ Monash
Phase 1:
"A three phased approach".
Project Planning

Figure 3: A roadmap expanding the


planning, execution
1.1 Appoint Project Sponsor
and conclusion
1.2 Appoint Project Manager phases
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: 1.15 Review Project Cost Estimates
Project Execution 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: 2.15 Obtain Final Sign-off

Project Conclusion

3.1 Decommission Obsolete Systems

3.2 Perform Post-implementation Review

3.3 Monitor Benefits Realisation

3.4 Implement Service Statement

3.5 Celebrate Project Completion

____________________________________________________________________________________________
Project Management @ Monash Page 5
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 project at a more detailed level than the Project 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 project 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 project, 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

____________________________________________________________________________________________
Project Management @ Monash Page 6
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 Project 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 require 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 project.office@its.monash.edu.au.

____________________________________________________________________________________________
Project Management @ Monash Page 7
1.1 Appoint Project Sponsor
Before a project can commence, a Project Sponsor must be 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. 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 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 day-to-day management and direction of the project
team and retains a ‘dotted line’ responsibility to his or her functional manager.

The skill requirements for the role include the ability to plan, delegate, communicate, influence decision-
making and manage relationships. Practical or theoretical knowledge of the project subject matter is 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, benefits and other key 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-functional
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 various components of it may need to be revised in the Project
Charter.

____________________________________________________________________________________________
Project Management @ Monash Page 8
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 Sponsor’s responsibility to review the measurement of progress 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 form the basis for future planning 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 outcomes 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 to evaluate the success of the project.

____________________________________________________________________________________________
Project Management @ Monash Page 9
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 activities 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 identify a business or functional owner to oversee the maintenance
and management of the 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 approach to the progression of the project 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 primarily 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 approach, usually with a 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 tasks, project milestones and key
deliverables together with their estimated dates, and the scheduled project completion date.

____________________________________________________________________________________________
Project Management @ Monash Page 10
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, 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 to work on the project. Often it may be 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 regularly 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 into a project plan by identifying 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.

____________________________________________________________________________________________
Project Management @ Monash Page 11
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,
objectives, timelines, costs and resources during the prior month. It is also used to 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 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,
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 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 and resource requirements such 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.

____________________________________________________________________________________________
Project Management @ Monash Page 12
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. A copy of the approved Project 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.

____________________________________________________________________________________________
Project Management @ Monash Page 13
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 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 also be worthwhile 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 conflicts
during the course of the project. The kick-off meeting can also be used to resolve any initial issues or
questions regarding the project and clarify reporting lines. The Project Manager should also provide an
outline of the immediate and long-term project 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 resources.

The sequence of activities that determine the project 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 progress 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 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.

C ritic a l P a th

Task A Task B Task D


8 h o u rs e ffo rt 1 2 h o u rs e ffo rt 4 h o u rs e ffo rt
2 days 3 days 1 day

Task C
8 h o u rs e ffo rt
2 days

F ig u re 4 : E x a m p le o f C ritica l P a th

____________________________________________________________________________________________
Project Management @ Monash Page 14
2.4 Establish Issues Management Process
There are nearly always unforeseen issues that arise during the 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 to ensure that these are documented, analysed
and resolved satisfactorily to avoid any delays to the progress of the project. When issues are addressed,
then the project risk is usually reduced and the chance of 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 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 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. 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 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.

____________________________________________________________________________________________
Project Management @ Monash Page 15
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 to 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 before
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 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 of communications to 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.

____________________________________________________________________________________________
Project Management @ Monash Page 16
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 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 Project 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 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 implemented 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.

____________________________________________________________________________________________
Project Management @ Monash Page 17
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 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, 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.

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
once the project has been implemented. Monitoring should begin soon after project 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 form the basis for future planning 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 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.

____________________________________________________________________________________________
Project Management @ Monash Page 18
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 service to clients or 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. It usually
highlights milestones, dependencies and resources associated with particular tasks.

Milestone A major checkpoint in a project. Examples of milestones 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 result 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- An evaluation of the project’s goals and activity achievement as measured against the
Implementation project plan, budget, timelines, quality of deliverables, specifications and client
Review 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 The approach to the way a project will be conducted eg. fast-track (minimum set of
Approach 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.

____________________________________________________________________________________________
Project Management @ Monash Page 19
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 A professional discipline combining systems, techniques and people to achieve a business
Management objective within defined parameters of time, budget and quality.

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

Project The person responsible for the day-to-day management of a project to ensure that the
Manager 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 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 session.

Related Project A related project is a project that is either dependent on, interdependent with or is pre-
requisite to the project.

Risk A process of identifying factors that may impact on the success of the project.
Assessment

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

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 Computer software that provides automated support for developing schedules, Gantt
Tools 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 effort 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 A representative group of senior managers who are responsible for approving major
Committee changes to the project's scope, objectives, timelines, 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 @ Monash Page 20

You might also like