Project Management at Monash: A Guide To The Approval, Planning and Management of IT Projects at Monash
Project Management at Monash: A Guide To The Approval, Planning and Management of IT Projects at Monash
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.
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.
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.
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.
Project Description
A broad overview of the project
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
Risk Assessment
A summary of the major risks that may impact the project’s success
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.
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.
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.
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
Im plem entation
Plan
Production
Support Plan
____________________________________________________________________________________________
Project Management @ Monash Page 4
Project Management @ Monash
Phase 1:
"A three phased approach".
Project Planning
Project Conclusion
____________________________________________________________________________________________
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
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
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 [email protected].
____________________________________________________________________________________________
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.
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.
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.
____________________________________________________________________________________________
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.
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.
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.
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.
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.
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.
____________________________________________________________________________________________
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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?).
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.
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.
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.
____________________________________________________________________________________________
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.
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.
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