PROJECT MANAGEMENT HANDBOOK

Version 1.3 April 2007

DOCUMENT CONTROL

Author H. Terese Parks

Heliograph Services Pty Ltd
Contributors Paul Campbell, Director, Information Technology and Communication
Services (ITCS)
Rona Brown
MIS Manager, Information Technology and Communication Services
(ITCS)
Barbara Olde
Former Director, Information Technology and Communication Services
(ITCS)
File Name

Last Edited 26.04.07

Record of Amendments
Date Version Changed by Description of Changes
June 2003 1.0 Helen Terese Parks Initial draft of entire Handbook
September 1.1 Helen Terese Parks  Inclusion of cost and benefit analysis methods
2003  Inclusion of IT&T testing terms
 Elaboration of Project Charter instructions
 Inclusion of changes arising from initial review
of draft by Barbara Olde, Former Director,
ITCS and Rona Brown, Manager, MIS, ACU
October 2003 1.2 Helen Terese Parks Inclusion of summary overview at request of
Barbara Olde, Former Director, ITCS
April 2007 1.3 Sean Connell Inclusion of Communications Management
section and template at request of Paul
Campbell, Director, ITCS

Page 2 of 94
Table of Contents
1 Overview .......................................................................................................................................................................................... 7
1.1 Project Initiation ........................................................................................................................................................................ 8
1.2 Project Establishment ............................................................................................................................................................... 8
1.3 Project Planning ........................................................................................................................................................................ 8
1.4 Project Control .......................................................................................................................................................................... 9
1.5 Project Completion.................................................................................................................................................................... 9
2 Introduction .................................................................................................................................................................................... 10
What is a Project? ............................................................................................................................................................................. 10
3 Project Management Phases ......................................................................................................................................................... 11
4 Project Scope ................................................................................................................................................................................ 12
5 Role of the Project Manager........................................................................................................................................................... 13
6 User and project staff interrelationship ........................................................................................................................................... 13
7 Knowledge base ............................................................................................................................................................................ 14
8 Project Charter ............................................................................................................................................................................... 15
9 Business Process Mapping ............................................................................................................................................................ 16
9.1 Fact finding and recording techniques..................................................................................................................................... 16
9.2 Charting .................................................................................................................................................................................. 17
9.2.1 Types of Charts ............................................................................................................................................................... 18
9.2.1.1 Information Flow Charts ............................................................................................................................................ 18
9.2.1.2 Special Purpose Charts ............................................................................................................................................ 19
9.2.1 Entity Relationship Diagram ............................................................................................................................................. 19
9.2.3 Process Flow Chart.......................................................................................................................................................... 20
9.2.3 Analysis of Process Charts .............................................................................................................................................. 21
10 Project Management Life Cycle .................................................................................................................................................. 22
11 Project Initiation .......................................................................................................................................................................... 23
11.1 Define Project Scope and Objectives .................................................................................................................................. 24
11.1.1 Project scope ................................................................................................................................................................... 24
11.1.2 Project objectives ............................................................................................................................................................. 24
11.2 Cost and Benefit Analysis (CBA) ......................................................................................................................................... 24
11.2.2 Internal Rate of Return (IRR) ........................................................................................................................................... 24
11.2.3 Net Present Value (NPV) ................................................................................................................................................. 24
11.2.4 Return on Investment (ROI) ............................................................................................................................................. 25
11.3 Developing a cost/benefit analysis ................................................................................................................................... 25
11.3.1 Identify benefits................................................................................................................................................................ 25
11.3.2 Identify costs .................................................................................................................................................................... 25

Page 3 of 94
 11.3.3 Develop the project cash flow schedule ........................................................................................................................... 25
12 Project Planning ......................................................................................................................................................................... 26
12.1 Change Management Plan .................................................................................................................................................. 27
13 Project organisation .................................................................................................................................................................... 27
13.1 Executive Sponsor .............................................................................................................................................................. 28
13.2 Project Sponsor ................................................................................................................................................................... 28
13.3 Project Manager .................................................................................................................................................................. 29
14 Scope Management ................................................................................................................................................................... 30
14.1 Scope creep considerations: ............................................................................................................................................... 31
14.1.1 Impact analysis ................................................................................................................................................................ 31
14.1.2 Cost analysis ................................................................................................................................................................... 31
14.1.3 Mandatory changes ......................................................................................................................................................... 31
15 Project Status Reporting ............................................................................................................................................................. 32
16 Issue Management ..................................................................................................................................................................... 33
17 Risk Management ...................................................................................................................................................................... 35
18 Communication Management ..................................................................................................................................................... 37
19 Project completion ...................................................................................................................................................................... 39
20 APPENDIX A –DATA MODELLING............................................................................................................................................ 40
19.1 Conceptual data modelling .................................................................................................................................................. 40
19.1.1 Entities. ............................................................................................................................................................................ 40
20.1.1.1 Defining .................................................................................................................................................................... 40
20.1.1.2 Composite entities .................................................................................................................................................... 40
20.1.1.3 Aggregates ............................................................................................................................................................... 40
20.1.1.4 Sub-classification of entities ...................................................................................................................................... 41
20.1.1.5 Physical boundaries .................................................................................................................................................. 41
20.1.1.6 Events ...................................................................................................................................................................... 41
20.1.1.7 Messages ................................................................................................................................................................. 41
19.1.2 Attributes. ........................................................................................................................................................................ 41
19.1.2.1 Attribute names......................................................................................................................................................... 42
19.1.2.1 Domains ................................................................................................................................................................... 42
19.1.2.2 Identifier attributes. ................................................................................................................................................... 42
19.1.2.3 Time-varying attributes. ............................................................................................................................................ 42
19.1.2.4 Optional attributes. .................................................................................................................................................... 42
19.1.3 Relationships ................................................................................................................................................................... 42
19.1.3.1 Number and type of roles .......................................................................................................................................... 42
19.1.3.2 Degree ...................................................................................................................................................................... 43
19.1.3.3 Optionality................................................................................................................................................................. 44

Page 4 of 94
 19.1.3.4 Permanence ............................................................................................................................................................. 44
19.1.3.5 Dependencies ........................................................................................................................................................... 44
19.2 Logical Data Modelling ........................................................................................................................................................ 45
19.2.1 Data Modelling Objects .................................................................................................................................................... 45
19.2.2 Relationship diagrams ..................................................................................................................................................... 45
19.2.3 Attribute diagrams ............................................................................................................................................................... 46
19.2.3.1 Type/Occurrence Distinction ..................................................................................................................................... 46
19.2.3.2 Membership Class (Connectivity Characteristics) ......................................................................................................... 47
19.2.3.3 Degree ...................................................................................................................................................................... 49
19.2.3.4 Attribute Values ........................................................................................................................................................ 50
19.2.3.5 Domains ................................................................................................................................................................... 50
19.3 Physical Data Model ............................................................................................................................................................ 52
19.3.1 Overview.......................................................................................................................................................................... 52
19.3.2 Generating the Data Archive PDM ................................................................................................................................... 52
19.3.3 ISO Data Archive Physical Data Model – example: .......................................................................................................... 53
21 APPENDIX B – PROJECT CHARTER FORMAT ....................................................................................................................... 54
22 APPENDIX C - Critical Path Analysis (CPA) ............................................................................................................................... 57
23 APPENDIX D - Program Evaluation and Review Technique (PERT) .......................................................................................... 59
24 APPENDIX E - Gantt Chart ........................................................................................................................................................ 61
25 APPENDIX F - Work Breakdown Structure (WBS) ..................................................................................................................... 62
24.1 Phase .................................................................................................................................................................................. 62
24.2 Stage................................................................................................................................................................................... 62
24.3 Activity ................................................................................................................................................................................. 62
24.4 Task .................................................................................................................................................................................... 62
26 APPENDIX G - BUSINESS CASE TEMPLATE .......................................................................................................................... 63
TABLE OF CONTENTS .................................................................................................................................................................... 64
Section 1 – Executive Summary ........................................................................................................................................................ 64
Section 2 – Statement of the business issue ..................................................................................................................................... 64
Section 3 – Background and Business Drivers .................................................................................................................................. 64
Section 4 – Project Scope and Objectives ......................................................................................................................................... 64
Section 5 - Evaluation of Alternative Solutions................................................................................................................................... 64
Section 6 – Proposed System Description ......................................................................................................................................... 65
Section 7 – Economic Justification .................................................................................................................................................... 65
Section 8 – Implementation timeline .................................................................................................................................................. 66
Section 9 – Project structure .............................................................................................................................................................. 66
Section 10 – Critical Assumptions and Risk Assessment................................................................................................................... 66
Section 11 – Conclusions and Recommendations ............................................................................................................................. 67

Page 5 of 94
 Section 12 - References & Related Documents ................................................................................................................................. 67
27 APPENDIX H – Project Status Report format ............................................................................................................................. 68
28 APPENDIX I - Issue Log format .................................................................................................................................................. 70
29 APPENDIX J – Risk Management Schedule .............................................................................................................................. 71
30 APPENDIX K – Communication Plan Template.......................................................................................................................... 79
1. Communications Plan Executive Summary ................................................................................................................................ 81
2. Marketing and Communication Strategies .................................................................................................................................. 81
a. Communicating Major Risks, Issues and Changes ................................................................................................................. 81
3. Stakeholder Communication....................................................................................................................................................... 82
4. Training Strategies ..................................................................................................................................................................... 82
31 APPENDIX L – Internal Rate of Return (IRR) ............................................................................................................................. 83
32 APPENDIX M – Net Present Value (NPV) .................................................................................................................................. 85
33 APPENDIX N – Return on Investment (ROI) .............................................................................................................................. 87
34 APPENDIX O – Weekly Project Review Meeting Minutes - Format ............................................................................................ 91
35 APPENDIX P – TESTING INFORMATION TECHNOLOGY APPLICATIONS............................................................................. 92
Terminology....................................................................................................................................................................................... 92
36 BIBLIOGRAPHY......................................................................................................................................................................... 94

Page 6 of 94
1 Overview
This Handbook provides a standard framework to guide project management at ACU National.

Because each Project is a self-contained related group of work activities with a specific predefined deliverable, it is not feasible to
define every detail of work for every Project within a rigid template. However, this Handbook does define a set of documents that must
be included in every Project. Hence, it provides a consistent framework within which to conduct all the work necessary for the success
of each Project, notwithstanding that some of the tasks within the standard framework will vary according to the nature and complexity
of the Project to which it is applied.

The ACU National Project Management methodology is comprised of five phases, each of which results in specific documentation
(refer Section 3). Also note that communication should be a key consideration when drafting and disseminating project documentation.

Initiation Establishment Planning Control Completion

Pro
Project
ject Pro
Project
ject
B usiness Pro ject AAccept ance
Plan St
Stat
atus
us ccept ance
C ase C hart er Plan Sig
RReport
eport ss Sign-
n-of
offf

Post -
Im ple ment at i on
R eview

Communication
Communication

Page 7 of 94
1.1 Project Initiation
Project initiation has the following objectives:

 Identify and document the business need/objectives that the project will address
 Determine and evaluate alternative ways in which the business need can be met and recommend
the best solution
 Assure and establish sponsorship of the project
 Define the objective, approach and controls of the project
 Estimate the project effort, duration and cost
 Ensure a clear and common understanding of the deliverables that will be produced
 Specify what work needs to be completed in order to produce the deliverables
 Determine the type of skills that will be needed to complete the project
 Estimate how long it will take and what it will cost (once-off and ongoing/capital and operating
expenditure)
 Specify what will constitute completion of the project
 Obtain appropriate management approval for effort and cost

Project initiation is completed upon sign-off of the final Business Case. The Business Case is a static
document that is never to be changed after sign-off. The Business Case forms the baseline benchmark
for the post-implementation evaluation of success, against which achievements will be measured.

1.2 Project Establishment

Project establishment has the following objectives:

 Allocate responsibility, assign the project manager, specify the project sponsor and establish an
appropriate steering committee
 Identify project team members (according to skill needs identified in the Business Case), identify
and define the role of stakeholders
 Document the project team structure
 Establish project cost codes and allocate budget to those codes

Project establishment is completed upon sign-off of the Project Charter. The Project Charter is to be
amended as and if any element of the initial Project Charter changes. However, version control is to be
adhered to strictly, so that changes can be tracked in the quality assurance process and as input to the
post-implementation review. Any change to the original Project Charter requires that a new version of the
Project Charter be created and promulgated/published.

1.3 Project Planning

Project planning has the following objectives and deliverables:

 Confirm all previous assumptions regarding skills required, number of project staff, effort and
duration, etc.
 Confirm specific skill requirements, confirm that those resources are available (in-house or by
external contract resources), identify the individuals who will be assigned according to the skill
requirements for various tasks and sub-projects
 Document work breakdown structure, including specific tasks, milestones and deliverables
 Refine estimates of task efforts
 Determine task dependencies

Page 8 of 94
  Determine external dependencies
 Determine interface and interaction dependencies
 Determine milestones that will represent quality assurance checkpoints and their completion dates
 Schedule the work plan, inclusive of constraints
 Prepare and review the project plan
 Submit the initial project plan for approval by the relevant executive sponsor, project sponsor and
steering committee

Project planning is an iterative and ongoing process. However, the initial project plan must be approved
and signed-off before the project commences. At this point, the project plan is to be base lined, to ensure
that any and all variances from that plan are tracked and recorded.

1.4 Project Control

Project control is ongoing throughout the duration of a project. Project status reports must be completed
at intervals agreed in the project planning phase, but no less often than monthly. Project control has the
following objectives:

 Capture actual data and compare that data to the relevant project plan and budget to:
o Analyse performance
o Review estimates of cost and time to complete
o Post actual costs against budgeted costs and explain variances
 Communicate progress of the project
 Review and update the project plan as necessary
 Review and update the original project charter as necessary

1.5 Project Completion

Project completion is a once-off activity. All stakeholders must sign-off their satisfaction with the project
deliverable/s before a project can be deemed to be complete.

Page 9 of 94
2 Introduction

What is a Project?

A project is any related group of work activities which, when completed, will achieve specific objectives.
A project has a stated scope, deliverables, tasks, work steps, duration and budget, as defined in a Project
Charter.

This Handbook is relevant to all related groups of work activities that have a business objective, whether
the solution involves Information Technology and Telecommunications (IT&T) or not. While some
terminology used in this Handbook may cause the reader to infer IT&T system development project
management, the processes apply to all projects, whether technology based or not.

A project:

 Has a beginning and an end;

 Is defined by specific objectives (deliverables);
 Is undertaken within a well defined organisational structure;
 Has a single project manager who is responsible for its success;
 Has a defined starting point, a defined end point, and defined work breakdown structure
comprising a path from the start to the end.

To be successful, a project must move forward in a controlled manner, from initiation to completion. A
project uses resources. These include work effort of the project team, including significant stakeholders
not assigned directly to the team, infrastructure support, project administration, money for project related
travel and training, etc. Resources must be used effectively or the project will be late, or over budget, or
both.

Project milestones, comprised of specific deliverables, are developed to show tangible results of work
done and to provide substance for quality assurance reviews. Quality Assurance (QA) reviews are
essential, to identify issues at the earliest possible stage, to enable them to be addressed so that the
overall project objectives, delivery date and budget are not adversely impacted.

Risks are inherent in all projects. A risk management plan is an essential element of any project charter.
Any and all foreseeable risks must be documented and relevant mitigation strategy devised.

Project Management is the process by which a project is initiated, controlled, and brought to a successful
implementation.

The objective of project management is to plan and control a project from start to end, with high levels of
productivity and quality. A project must be managed in terms of its structure, work performed by staff
assigned to it, specific deliverables and budget constraints. Levels of control and monitoring will vary
depending on the timeframe and criticality of the project at hand. Progress reporting will also vary
depending on its intended audience.

Page 10 of 94
3 Project Management Phases
INITIATION
BUSINESS CASE
ESTABLISHMENT INITIATION
PROJECT
MANAGEMENT PLANNING Business need recognise d

CONTROL
Project scope & objectives define d and agreed

COMPLETION
Alternative solutions determined
PROJECT PLAN
PLANNING Alternative solutions evaluated and compared
Confirm assumptions

Recommended solution determine d

Confirm resource (skill) requireme nts

Confirm resource ava ilability, identify Business Case developed

individua ls to be assigned to skill needs
Business Case presented to appropriate manage ment
Committee for approval and budget allocation
Determine tasks, work breakdown structure,
milestones and de liverables
Proposa l approved by ma nageme nt and budget approve d

Estimate task effort

Determine task dependenc ies
Determine externa l depe ndenc ies
Determine interface/interaction dependenc ies
PROJECT CHARTER
ESTABLISHMENT
Allocate responsibility, assign project ma nager, project
sponsor, establish steering committee

Determine key milestone completion dates Identify project team and stakeholders

Schedule pla n, inc lusive of constraints Docume nt project team structure

Review Project Plan Establish project cost codes and a llocate budget

Submit Project Plan for acceptance PROJECT STATUS REPORTS

CONTROL
Analyse performance
Capture actual data,
ACCEPTANCE SIGN-OFF compare and ana lyse Review estimates to complete
COMPLETION Actuals VS Plan
Post actual against budget
Process Owner & Executive Sponsor sign-off

CHARGE (if applicable)

Communicate progress
POST IMPLEMENTATION REVIEW
Review Project Plan

Page 11 of 94
4 Project Scope
The scope of any project should be derived from and be consistent with an overall enterprise model of
business needs, priorities, strategies and infrastructure. Projects should be identified based on a number
of complementary developments and prioritised according to prevailing business objectives. The
planning phase of any project is critical to its ultimate success.
During the planning phase, the University‟s goals, objectives and critical success factors have to be taken
into account. Similarly, the strategies, data, processes and organisational structure must be reflected in
the planning of any project.
Each functional division will be a cluster of processes and data and reflect a part of the overall University
strategy and organisational elements associated with them.
All processes will cross numerous functional divisions, and the end-to-end impact of any change to any
process needs to be identified and addressed during a project‟s planning phase.

UNIVERSITY OBJECTIVES

BUSINESS PROCESS

BUSINESS PROCESS
FUNCTIONAL UNIT
FUNCTIONAL UNIT

FUNCTIONAL UNIT

FUNCTIONAL UNIT
FUNCTIONAL UNIT

FUNCTIONAL UNIT

FUNCTIONAL UNIT
FUNCTIONAL UNIT

FUNCTIONAL UNIT

FUNCTIONAL UNIT

FUNCTIONAL UNIT

FUNCTIONAL UNIT

BUSINESS PROCESS

BUSINESS PROCESS
SUPPORTING RESOURCES

No project can be an island in the context of an holistic organisation. Projects should not be single point
solutions to business problems or needs. The top down planning process will ensure that each project
represents a tactic within an overall business program. Project managers have to manage these
interdependencies without compromising the success of the individual projects for which they are
responsible.

Page 12 of 94
5 Role of the Project Manager
The project manager acts as a leader and a process manager. As a leader, the project manager is
responsible for managing and communicating a clear vision of the project objectives, and for motivating
the project team to achieve them. As a process manager, the project manager must ensure that work
efforts are sequenced to achieve the overall project schedule.

A project manager must have credibility with their project team and with the project sponsor. So it is
essential that the project manager have, or acquire, some knowledge of the technical aspects of any
project to which he/she is assigned.

Project deliverables are very rarely static over the life of a project. Objectives and deliverables may, and
usually do, change as new information is gathered by the project team and evaluated by the project
sponsor. The project manager must assure a well defined scope management plan, provide continuous
leadership for the development team, manage the project sponsor relationship effectively, and create a
project environment that allows all participants to maintain maximum productivity and effectiveness.

6 User and project staff interrelationship

Business users, not technology or external providers, should be the focus of every project. User
involvement ultimately determines the quality of business systems. Past practices isolated users from the
project process. It was, therefore, hard for users to commit to a process in which they had not
participated, or had been afforded the opportunity to understand. This “them” and “us” approach
inevitably militates against success of any project.

When designing a project organisation structure, the roles of users as members of the project team, the
management and control structure, and support groups need to be defined before the project begins.

Users need to be involved in any project;

 to assure project direction continues towards the specific business needs and objectives,
 as an information source,
 as reviewers and evaluators of deliverables,
 as members of the project team in the functional analysis and process modelling stages.

Business process models need to be developed to ensure that the current procedures and proposed
changes are understood clearly. Such models need to be developed jointly by the business users and
the project staff, to derive a common understanding of the business and its needs. Models developed by
project staff in isolation from the business knowledge base are insufficient to assure a common
understanding.

Many projects fail because they lack credibility with the end users. This lack of credibility often arises
from:

 Past failures to deliver on commitments; projects are often late, over budget and deliver less than
the end users expected.
 Poor communications; users are not listened to, project staff prefer to minimise interaction with
end users, assumptions are made, there is a reliance on informal communications, overuse of
jargon and an unpreparedness to speak to the users in their own terms. If end users are not
sufficiently involved in the project the project will inevitably lose support.

Page 13 of 94
  Perceived lack of structure and process. Interviews and work shops will appear random unless the
users receive timely and professionally structured feedback.
 An over emphasis on technology, rather than the business need. Often, to the end users, a
project can seem to be predicated on the project teams‟ desire to use technology, particularly
topical technology, rather than to address the actual business need, which may be resolved
without technology at all.

7 Knowledge base
A thorough knowledge base should underpin every project. A knowledge base is the set of all information
relevant to the identified business need that is collected during the planning, analysis, design,
development and implementation phases of a project. The accumulated knowledge base should be
documented using a conceptual data model, a logical data model and a physical data model to constitute
a central repository of the University‟s accumulated knowledge relevant to the particular project.
Assuring a comprehensive knowledge base is essential to maintaining a rigorous structure in any project.
The scope of information represented in the knowledge base is far greater than the traditional project
information of tasks, money, time and resources. Strategic plans, organisational models, requirements
models and functional design specifications are documented, integrated and preserved in the knowledge
base.
The knowledge base must be stored in a central location, available (as read only) to all who need to know
its contents. Use of the knowledge base enables the business knowledge gained within a single project
to be shared and reused by other projects. Effective knowledge coordination improves the effectiveness
of each project manager and assures that individual project findings comprise a collective organisational
memory over time. Most usually, the central location is a specific local area network domain set aside
specifically for the purpose of accumulating and integrating the organisation‟s total knowledge. Elements
of the knowledge base are described as objects. Objects include entities that are elements of the
business process (lecturer, tutor, student, lecture room, etc), outputs (including forms, letters, screen
layouts, etc), critical success factors and organisational units.
All deliverables are described in terms of the knowledge base objects that comprise them. Iterative
performance and analysis of tasks and activities are used to refine the information in the knowledge base.
Knowledge coordination is critical to ensure smooth translation of models between project phases.
Refer Appendix A for details of data modelling techniques.

Page 14 of 94
8 Project Charter
The Project Charter is essential to ensure user involvement and understanding, particularly because the
Charter must:

 Document the agreement between the project sponsor and the project manager;
 Provide a clear statement of the purpose of the project and what is to be delivered by it;
 Define the project roles and responsibilities.

Refer Appendix B for the format of a Project Charter.

A Project Charter is the blueprint of a project; it constitutes the foundations upon which the project will
proceed. If the Project Charter does not achieve the objectives stated above, then the project will most
probably fail, simply because the criteria for success are not described accurately and there is no
common understanding of what constitutes success. The Project Charter is not a static document. It
needs to be updated as, if and when the project scope changes, when staff assigned to the project
change, when stakeholders change, when budget variances occur, etc. The Project Manager must treat
the Project Charter seriously and exert all efforts to achieve the commitments within the Project Charter.

An effective Project Charter requires that the business needs be understood to the appropriate level of
detail, which necessitates comprehensive needs analysis (functional specification).

In many ways, business needs analysis (business process mapping) is the hardest part of the
development (or configuration) of a computer application. This arises because the analyst is the “middle
man”, trying to serve both the user community and IT&T staff. Finding solutions that will satisfy both
parties is inevitably difficult, because there will often be conflicting interests and priorities, and
communication difficulties between the business and the “technologists”.

Surveys over three decades have indicated that approximately 70% of total computer system costs are
incurred in maintenance and modification of the original implementation. This results from, primarily, two
related aspects of business systems development:
1. The system design (base functionality and configuration in the case of packaged systems) does
not end up reflecting the users‟ functional requirements.
2. It is difficult and costly to alter system logic after the original design has been implemented.
There is a big difference between business analysis and business systems design, one that is often
blurred to the disadvantage of all parties. An analyst must be objective in determining the optimum
business process, not be constrained by pre-determined ideas or advice as to the business system‟s
functionality. Business system design must be based on the business process analysis. It is at this point
that any discrepancies between what the business needs and what the business system software can
deliver will be identified.

Narrative is a very ineffective way of trying to ensure a clear understanding of the business requirements,
as reflected in the optimal business processes.

Page 15 of 94
To design and install cost-effective business systems that meet the needs of the user base, those needs
must be completely and reliably met by functionally rich and robust solutions. In all instances, the end
user must be provided with:

 A functional specification (needs analysis) of the business system to be developed (or purchased
and installed). The functional specification represents the essential activities which must be
performed, whether they can be computerised or not.
 The functional specification should set out, clearly, the logical requirements of the business system,
without including so much information that it verges on a technical specification and becomes
unintelligible to the business users/process owners. It is essential that the functional specification
be understood by the end-user/process owner, so that he/she can:
o Agree, and sign off to the effect that, the functional specification meets his/her/their business
process functional requirements (and that any compromises or trade-offs in functionality have
his/her/their assent)
 The functional specification should make it clear what options are available to meet the business
needs, and what trade-offs may be required (for other than essential functions).

An effective functional specification can only be prepared on the basis of a clear understanding of the
business processes that the business systems application is being developed (or installed and
configured) to support. Business process mapping is, therefore, the first and most essential step in
business systems development or re-design.

9 Business Process Mapping

9.1 Fact finding and recording techniques

It is essential in business systems analysis not to overlook sources of valuable background information
relevant to the business process being analysed. What is relevant will be determined by how well the
objectives of the analysis have been defined. A high level preliminary review, preceding detailed
analysis, will often facilitate the information gathering exercise.

Normally, useful background information can be obtained from:

 Organisation charts and Policy manuals

If these are unavailable or out-of-date, the current organisation structure or policies need to be
determined. The analyst needs to understand the constraints that may apply to changing any
process.

 Operating instructions and/or Procedural documentation

Again, these may be out-of-date, but will act as a guide. Even when current, they are a guide to
understanding the present process, rather than a constraint on improving them. It is important to
understand the reason behind any obvious inefficiency in the current process.

 Previous reports, Minutes of meetings, correspondence

Ask people who have been around long enough to know (and preferably, who appear to be unbiased
in the process analysis).

Page 16 of 94
 Personal conversations
Be aware of the person who may have been closely involved with the process/processes under
review in the past, who may now be in another department, school or faculty.

Identify the key people who interact with the process or system being analysed, particularly indirect
users.

By identifying and researching as much background information as practical within the time available, the
person conducting the analysis of the business process:

 Will be sure of the information he/she requires, and from whom it can be obtained
 Can anticipate likely opposition and obstruction
 Can prepare well for interviews, deal with uncooperative people, and more readily distinguish facts
from opinions
 Be able to complete interviews more quickly
 Begin to understand the real motives for the study being undertaken:

o Why this process and not some other?

o What does senior/executive management expect to get from the analysis?

9.2 Charting
Charting is the principle documentation approach within business analysis. Charting has five main uses:

 Fact finding
 Analysis
 Design
 Presentation
 Implementation

In regard to fact finding, an effective and comprehensive chart of the process is the way in which the
analyst will know and understand the existing process, including:

 Who
 What
 Where
 When
 Why
 How

The chart of the existing process (or system) will set the direction for further analysis and for
improvement. It is important to chart at the highest level first, then to “drill down” to more detailed levels
as, if and when the need for such becomes apparent (as it inevitably will in the context of proposed
automation of business processes).

Similarly, charting of the design of the new (or possible alternative) process, in the context of the chart of
the existing system, will reveal the complexity of the new (or possible alternative) system and, particularly,
the extent to which it varies from the existing system.
Page 17 of 94
Charts are very effective presentation tools (“a picture is worth a thousand words”), as they:

 Obviate long narratives which may not make the flow of work obvious
 Provide succinct and compact guidance as the functional flow of the process
 Facilitate checking of correctness with functional operatives within the business areas
 Assist identification and analysis of gaps, bottlenecks, inefficiencies and opportunities for
improvements
 Facilitate comparison between current and proposed processes

Accurate charts also form the basis for functional specifications of IT&T systems and for training of
functional operatives and information technology system users.

Charting must take account of:

 The type of process being analysed

 The level of detail required in the analysis
 The purpose to which the chart is to be put
 The use of the charts in presentations; they may become the key to convincing management to
support the change (and approve the costs of making the change)

It‟s important to note that all business process analysis and improvement depends to some degree on trial
and error (“iterative analysis”).

Effective business process mapping helps to identify:

 The sub-processes and steps within the process being analysed

 The purpose for which the business process exists (outputs)
 The resources required to achieve the purpose of the business process (inputs)
 The existence (or not) of controls that ensure accuracy, reliability, maintainability, timeliness, audit
ability, etc.
 The interdependencies and interfaces of the business process being analysed.

9.2.1 Types of Charts

9.2.1.1 Information Flow Charts
 Operational/procedural flow process charts/maps
 Schematic flow charts, diagrams or maps
 Form flow chart
 Forms routing charts
 Computer logic charts

Page 18 of 94
9.2.1.2 Special Purpose Charts

 GANTT1 or BAR charts (Project Planning)

 PERT2 network charts (Project Planning)
 FAST3 diagrams
 DFD (data flow diagram)

9.2.1 Entity Relationship Diagram

This is a diagram used to show how various entities (elements of the process) are related to each other.
The following chart provides an example of an entity-relationship diagram in which the relationship
between student and course is many, because each student may attend many courses and each course
will have many students. The relationship between tutor and course is one to many, because each tutor
will teach many courses, but each course will have only one tutor (in this example):

Students Courses Tutor

Enrols in Taught by

1
The Gantt chart, devised as a charting method by Henry Gantt, is a visual display to represent scheduling which is based on
time, rather than quantity, volume or weight.
2
PERT charts: (sometimes called Network Charts or Logic Diagrams) are widely used project management
diagrams, used for displaying project schedules depicting tasks and the dependencies between tasks.
3
Function Analysis System Technique
Page 19 of 94
9.2.3 Process Flow Chart
Process Flow Charts are used at ACU National to map the business activities that support the University‟s
vision, mission, strategies and operational plans.
A Process Flow Chart shows the information and/or activity flow represented by separate forms, records,
and other media. It may be presented in either a horizontal or vertical flow, and is especially useful in
defining the functional requirements of an information technology application. The conventions and
symbols applying to process flow charting are:

 Each horizontal line on the chart represents a discrete information flow (usually a separate paper
form in each case)
 The symbols on each line represent the activities in which that particular information or paper form is
involved, or handled
 The vertical lines indicate the relationship between different forms or records. Where two forms are
linked vertically through several operations, it indicates that the same forms are used in multiple
operations
 Information or activity flow is from left to right, or from top to bottom
 Basic symbols have the following meanings:

Activity
Something is done to or with the information on the form (or in the
computer). The nature of the activity being performed needs to be
explained on the chart.

A new form or record is created



Information is being added. This is usually associated with a vertical

connection, indicating the source from which the information being added
is obtained.

Indicates a sorting or distribution of copies

Indicates a machine operation (most usually a computer system; the

process map should include a notation as to the computer application to
MO which the information is submitted, or from which the information <data>
is obtained.
Movement; indicates transfer of a form physically from one point to
another; the destination or origin of the move should be notated below
the arrow.
A decision, inspection, check or review point. No information changes.

Page 20 of 94
9.2.3 Analysis of Process Charts
The business process chart provides the most effective means of eliminating unnecessary work and
streamlining business processes, because it provides a detailed description of a particular task or piece of
work.
There are five key questions that need to be answered to perform an effective analysis:

1. What is being done and why is it necessary?

Does each step serve a useful purpose? Does it actually contribute to the end result?
An excuse for performing a step is often not a true reason for it being done, often, it will be found to be
unnecessary.

2. What is being done and why should it be done there?

Can it be done more easily in some other step of the process, or in another department? Will a change to
where and when it is being done save steps, time and effort?
3. Who is doing the job? Why should he/she do it? Would someone else do it better?
Is someone else better qualified or skilled to do the work? Who can do it most easily and most
practically? Ensure that high-salaried time is used discriminately, and delegate tasks to lesser-paid
employees wherever feasible.

4. When should this step or task be done? Why?

Should this step be done earlier or later or combined with some other step? Is it really in its proper
sequence in the end-to-end process? By doing it at this time and at this juncture in the end-to-end
process, is it really slowing down or holding up another business operation?
5. How is it being done? Why should it be done that way?
Is the process too complicated in its present form? Can it be done in an easier way? Should different
forms or supplies be used? Can shortcuts be adopted? Is automation feasible? Will automation make it
happen faster, more efficiently, with less cost?
For many activities there are explicit rules for how activities are done. Rules are of two types - constraints
and operational guidance. Constraints define conditions under which an activity cannot be done or
conditions under which an activity must be done. In the University environment these are determined
primarily by Legislation and statistical reporting requirements and cannot be changed by the University
unilaterally. Operational guidance is the University‟s determination of how activities should be done.
These can be analysed and changes recommended without reference to external authority.
Never overlook the people aspects and cultural issues that will need to be addressed, which include
changes in:

• Organisational structures: options: specialist/generalist; teams/individuals etc

• Job roles: logical grouping of tasks; management roles; how these fit together; skills, capabilities etc.
• Reward systems, performance measures and career paths
• Training and development
• Terms and conditions of employment.

Page 21 of 94
10 Project Management Life Cycle
The Project Management Life Cycle is most usually referred to as the System/Software Development Life
Cycle (SDLC). The processes shown in green shaded arrows related specifically to projects that are
initiated to implement an Information Technology & Telecommunications (IT&T) solution. The other
processes apply to all projects, whether IT&T based or not:

User
Implement
Acceptance
testing
Integration Maintain,
testing Support
enhance Establish Framework
 Strategies
 Policies
Identify
 Procedures
Unit business
testing need

Analyse
Program and
coding specify
requirements

Program Functional
design Technical
specification specification

Page 22 of 94
11 Project Initiation
Project initiation has the following objectives:

 Identify and document the business need/objectives that the project will address
 Determine and evaluate alternative ways in which the business need can be met and recommend
the best solution
 Assure and establish sponsorship of the project
 Define the objective, approach and controls of the project
 Estimate the project effort, duration and cost
 Ensure a clear and common understanding of the deliverables that will be produced
 Specify what work needs to be completed in order to produce the deliverables
 Determine the type of skills that will be needed to complete the project
 Estimate how long it will take and what it will cost (once-off and ongoing/capital and operating
expenditure)
 Specify what will constitute completion of the project
 Obtain appropriate management approval for effort and cost
If a project is part of a larger business program, as well as developing project charters and high-level
plans for each individual project, a master project plan will need to be prepared to identify project
interdependencies. If the business program consists of a number of sequential, as opposed to
concurrent, projects, it may be enough to create the master project plan and a detailed project charter for
the first project only.
Initiation of a project must be supported by a business case, signed off by the appropriately authorised
officers of the University. The business case documents all the information required to make a decision
on the merit of a proposed project
Preparation of the business case is an essential discipline, in that it requires concepts to be detailed and
fully considered. Any flaws in the understanding of the business need or the proposed solution should
become apparent during writing of the business case. Retrospective documentation of a business case,
documenting work already done, is unacceptable.
The business case constitutes the justification for the project. It is designed to gain approval at the
appropriate levels of the University to proceed with the project. Formulation of the business case is a
response to an identified business need, problem or issue, part of an ongoing strategy for business
improvement, a request for increased funding, justification for continuing funding, or consequent upon a
seemingly good idea to test the merit of that idea.
Option 1 in every evaluation of alternative solutions is “do nothing”. This base case or do nothing scenario
is the foundation upon which all benefits from the proposed business process re-engineering (BPR) effort
are determined. By documenting everything together in one document, it is easy to link the issues to the
solution and the benefit, and identify where the business would be without the BPR project. The
development of the overall business case simplifies the development of the financial justification, and will
usually identify holes or problems with the solution. Moreover, post implementation review of benefits
derived can only be effected when there was an initial projection of such benefits.
The business case provides a consistent message to many different audiences. It is a high level view of
the entire project and enables all staff and functional units impacted by the project to have a common
understanding of the project‟s scope and objectives.
Refer Appendix G for a sample Business Case.

Page 23 of 94
11.1 Define Project Scope and Objectives

Failure to clearly define the scope and objectives of any project is the most common cause of project
failure. Project scope and objectives are closely related to the business objectives but represent more
specific deliverables so must be expressed in a way that facilitates post implementation review against
the original scope and objectives. Effective and comprehensive functional analysis is essential at the
outset and relies on appropriate business process analysis.

11.1.1 Project scope

The project scope should be expressed as a concise and accurate description of the end deliverables to
be expected from the project and that meet specified requirements as agreed between the project‟s
stakeholders. It is important to specify exclusions from scope, where misunderstandings are probable.

11.1.2 Project objectives

A project‟s objectives are synonymous with “goals”.

11.2 Cost and Benefit Analysis (CBA)

Every project competes for limited funds and finite resources. It is therefore essential to analyse the costs
versus the benefits of every project so that they can be prioritised and allocated budgets.
There are numerous ways to approach a CBA, some of which are:
11.1.1 Discounted cash flow (DCF)
This is a method that considers the time value of money. DCF assumes that the value of any given
amount of money will be less in the future than in the present or the past. Cash flows in the future are
discounted, as opposed to compounded, by a specific discount rate, to convert them to present value.
DCF includes Internal Rate of Return (IRR) and Net Present Value (NPV):

11.2.2 Internal Rate of Return (IRR)

IRR is method that calculates the rate of return on an investment by finding the discount rate that equates
the present value of future cash flows to the cost of the investment. That is, the internal rate of return is
defined to be the discount rate that makes the net present value of the cash flows over time equal to zero.
Refer to Appendix J for details and examples of how to calculate IRR.

11.2.3 Net Present Value (NPV)

NPV is a method for assessing investment proposals in which the value is equal to the present value of
future returns, discounted at the cost of capital*, minus the present value of the cost of the investment.,
As a rule, the higher the NPV, the better the monetary returns are on an investment. Refer to Appendix L
for details and examples of how to calculate NPV.

*Cost of capital is the discount rate used for project investments evaluations and capital budgeting. It is the opportunity cost
of an investment, that being the rate of return that the University would otherwise be able to earn at the same risk level and
the investment that is being proposed and subjected to calculation of NPV. The opportunity cost is the value of the next
best purpose that the money available could have been used for.

Page 24 of 94
11.2.4 Return on Investment (ROI)

ROI is the yield that will manifest as a “profit” from expenditure. ROI is usually expressed as a
percentage of the initial investment amount. Refer to Appendix M for details and examples of how to
calculate ROI.

11.3 Developing a cost/benefit analysis

The following standards and guidelines need to be determined before a realistic CBA can be developed:
 The cost of capital (discount rate) to be used
 The recommended investment analysis time line applicable to each of capital and operating
expenditure respectively, ascertained from Finance.
 Cost and benefit categories
 Treatment of intangible (qualitative) benefits
 Treatment of taxes, depreciation and consumer price index (CPI)
 Full absorption cost of labour, by level and skill set, computer time usage, etc.

11.3.1 Identify benefits

Work with the project‟s sponsor to identify benefits that will result from implementation of the project. This
requires a clear understanding of the project‟s scope and objectives and of the current method of doing
the business process addressed by the project. Always start with the expected tangible (quantitative)
benefits and document assumptions clearly. Always ensure that it is possible to track and audit tangible
benefits.

Intangible (qualitative) benefits do not enable actual cost/benefit analysis and are usually only relevant as
considerations for a project that is at the margin of being cost justified.

It is not always clear whether a benefit is tangible. Tangible benefits, such as reduced staff (which can be
recruitment avoided, as opposed to redundancies) and avoidance of rental of extra office space are easy
to quantify. Ethereal intangible benefits such as “better decision making support” cannot be quantified.

11.3.2 Identify costs

Determine the costs and the intervals at which those costs will be incurred over the life of the project.
Consider both direct and indirect costs. An indirect cost will inevitably be the organisational change
impacts, including the temporary reduction in productivity while users are familiarised with the new system
and while they are seconded to the actual project team. Costs will vary depending on the staffing
approaches and the supporting technology (if applicable). Operating leases will vary the scheduling of
capital costs compared to outright purchase.

11.3.3 Develop the project cash flow schedule

Determine the timeframe over which the cost of the project is to be amortised (usually three to five years).
Allocate the anticipated costs and benefits monthly across the timeframe.

Page 25 of 94
12 Project Planning
Project planning is an iterative and ongoing process. Detailed plans must be revised as necessary
throughout the life of the project.

When planning a project, the project manager must confirm and build on the business case developed
during the project initiation phase to prepare an appropriately detailed project charter. The project
manager is responsible to create the project plan. The detailed project plan is used to document
deliverables and to achieve the project objectives detailed in the project charter. Project plans should
include:

 task schedules, being project specific detailed work plans,

 resource schedules,
 quality management and review plans,
 a risk management plan,
 a communications plan,
 an issue management plan,
 a scope management plan, and
 a detailed budget addressing all aspects of the project and its management

When preparing the detailed work plans, the project manager must ensure consideration of:

 task dependencies
 task and resource scheduling
 addition of any new tasks manifested as the project progresses (assuring also that the scope of
the project is closely managed and changes to that scope are documented thoroughly).

Project plans must be reviewed regularly to identify any slippage from original delivery dates, to
implement corrective measures and to evaluate the flow on effect on the project schedule overall.
The master project plan and all subsidiary plans must include milestones. Milestones will usually be the
completion of project stages. Resource constraints, quality issues and project risks need to be factored
into the milestone plan.

Each task within a project plan has a narrative description sufficient to communicate:

 What is to be achieved/delivered;
 The steps involved in achieving the deliverable;
 The completion criteria of each deliverable.

Maintaining and tracking a detailed project plan is impractical if done manually. ACU uses Microsoft‟s
Project Plan software to create and maintain project plans.

There is some overlap between initiation, establishment and planning of a project. Generally, details from
the business case, created during project initiation, will be carried forward into the project charter created
during the establishment phase and the project charter may be modified when detailed plans are created.
The high level project schedule in the project charter will be to an activity level, whereas the actual
detailed plans will be at a task level. Similarly, the high level plan, on which the budget is based, will
show skill types needed, whereas the detailed plans will show particular staff‟s names.

Page 26 of 94
During the planning process, it is essential to recognise that some or all of the project team, and
potentially some of the extended stakeholder team, will need training. Determine the type and duration of
training required and include that training in the detailed project plan.
The most common time based techniques for displaying project plans are shown below; the Gantt Chart is
the default display option within Microsoft Project, so is used most often at ACU National.

 CPA – critical path analysis (refer Appendix C)

 PERT – program evaluation and review technique (refer Appendix D)
 Gantt Chart - A Gantt chart is a horizontal bar chart developed as a production control tool in
1917 by Henry L. Gantt, an American engineer and social scientist (refer Appendix E)
A project plan has many uses, not only as a schedule to manage the timeliness, sequence and inter-
dependency of tasks, but as a tool to assure clear communications.

12.1 Change Management Plan

A change management plan must be prepared in conjunction with the project plan, to ensure that user
training and procedural documentation are available at appropriate junctures.

Change management is the mechanism through which a change to a process or system in the University
is initiated, assessed and implemented. Any change to a process or system will involve resources to
make the change and have the potential to impact on other parts of the overall process or system. Only
when the change is assessed in relation to its overall impact on the University can an informed decision
be made as to the merit of the proposed change.

13 Project organisation
A project team is brought together for a pre-determined period of time to achieve a specific set of
objectives. The project organisation chart must be augmented by role definitions and assignment of
responsibilities for each member of the team. It is essential that the project team be given sufficient
authority to achieve the project‟s objectives. Some of the factors that influence the perception and
effectiveness of the project team include:

 The active and visible support and sponsorship of most senior management and the project
sponsor
 The reputation and credibility of the particular individuals assigned to the project team
 The strength of the working and reporting relationships within the team
 The organisational culture in which the project team will function
The first appointment within any project team will be the project manager.
If more than six people need to report to the project manager, then consideration should be given to
assigning team leaders for identifiable modules of the project, through whom other team members will
report.

Page 27 of 94
Roles in the overall project organisation will typically include:

13.1 Executive Sponsor

This is the person who has ultimate authority over the project and is ultimately accountable for its
success. The executive sponsor:
 has control of the budget,
 resolves otherwise irreconcilable conflicts in the course of the project,
 provides high level direction,
 approves changes to project scope, including their time and budget impacts.

Sometimes, the executive sponsor and the project sponsor will be the same person. Often, the executive
sponsor will delegate routine participation in the project to the project sponsor.

13.2 Project Sponsor

The Project Sponsor provides the interface between project ownership and delivery. The Project Sponsor
is the client side representative who acts as a single focal point of contact with the project manager for the
day-to-day management of the interests of the client organisation. The Project Sponsor is responsible for
ongoing management on behalf of the project owner to ensure that the desired project objectives are
delivered. The person in this role must have adequate knowledge and information about the business and
the project to be able to make informed decisions. They may be known as the Project Sponsor;
sometimes referred to as the Project Director.

For smaller/straightforward projects the roles of Project Sponsor and Project Manager may be combined,
subject to the proviso that the person taking on the combined responsibilities possesses the requisite
competencies, expertise, experience and has the available time and resources. Where roles are
combined, it is essential that delegations and responsibilities are clearly understood and do not overlap
with other roles. This role description assumes that the roles of Project Sponsor and Project Manager are
separate.

The Project Sponsor is responsible for:

 Ensuring an appropriate project or programme management framework is in place, incorporating
the Gateway review process if required.
 Preparing the project brief, Project Initiation Document (or equivalent) and business case
 Appraising options and submitting for approval
 Securing resources and expertise from the client organisation as required, for example, appointing
professional advisers to support the project sponsor role
 Co-ordinating and directing end user input
 Co-ordinating value management strategy
 Controlling changes following approval
 Determining and managing risks to the project
 Managing the project budget, including risk allowance
 Acting as sole point of contact with project manager
 Co-ordinating and fostering teamwork
 Managing the project manager‟s performance of delegated responsibility
 Establishing formal reporting arrangements on project progress
 Defining criteria for control and management of the project

Page 28 of 94
  Assisting the project manager in the resolution of problems
 Receiving and reviewing detailed reports on the project from the project manager
 Ensuring the project manager receives departmental decisions on time
 Establishing with the project manager a common approach to major issues that arise
 Establishing a mechanism to ensure regular dialogue with contractors to promote problem solving,
team working and risk-sharing

The Project Sponsor should be able to:

 Apply quality management principles and processes
 Apply risk assessment and management principles and processes
 Network effectively, negotiate well and influence people, broker relationships with stakeholders
within and outside the project
 Be aware of the broader perspective and how it affects the project.

13.3 Project Manager

The Project Manager, operating within agreed reporting structures, is responsible for:
 Designing and applying an appropriate project management framework for the project (using
relevant project standards)
 Managing the production of the required deliverables
 Planning and monitoring the project
 Adopting any delegation and use of project assurance roles within agreed reporting structures
 Preparing and maintaining the Project Plan
 Manage project risks, including the development of contingency plans
 Liaison with business programme management (if the project is part of a business programme)
and related projects to ensure that work is neither overlooked nor duplicated
 Overall progress and use of resources, initiating corrective action where necessary
 Change control and any required configuration management
 Reporting through agreed reporting lines on project progress through status reports, change
request logs and issue logs
 Liaison with appointed project assurance roles to assure the overall direction and integrity of the
project
 Adopting technical and quality strategy
 Identifying and obtain any support and advice required for the management, planning and control
of the project
 Managing project administration
 Preparing a “Lessons Learned” report
 Preparing any follow-on action recommendations as required

The Project Manager should be able to:

 Apply standard project management approaches to the specific requirements of the project
 Direct, manage and motivate the project team
 Develop and maintain an agreed project plan and detailed stage plan(s)
 Tailor expert knowledge to meet specific circumstances
 Plan and manage the deployment of resources to meet project milestones
 Build and sustain effective communications with other roles involved in the project as required
 Apply quality management principles and process.

Page 29 of 94
14 Scope Management
Any additional functionality, deleted functionality, modification of deliverables, etc., as detailed in the
project charter, constitutes a change in the project‟s scope. Many projects fail to meet their schedules
and their budgets because of “scope creep”. It is essential that any and all changes to scope be
managed closely. Such management requires that any request for change be documented, evaluated,
tabled and, if approved, scheduled into a revision of the project plan.

Scope management:

 Maintains the integrity of the project charter

 Provides a way to process and record change requests
 Provides a single point of entry to record and process change requests
 Enables quick and efficient assessment of change requests
 Helps to ensure that any requested change is evaluated objectively in the context of its impact on
the project overall
 Enables formal review and approval processes for change requests
 Provides a basis for routine standard reporting of changes requested
 Captures historical change information as input to the knowledge base for subsequent projects
and for the post implementation review of the affected project.

Each request for change to the scope of the project must be considered and a decision made as to
whether it is to be accepted, rejected, or deferred until post-implementation of the original scope.
Acceptance of any change will require that the project charter, project plan, project budget and resource
requirements be amended.

Change requests need to be categorised, as follows, to assist in determining how to deal with them.

Mandatory (M) changes are those which are mandated by legislation or statutory reporting requirements.
Such changes must always be included into the original implementation schedule. They should not arise,
as all such requirements should have been identified during preparation of the project charter. They will
arise as the result of internal oversight, or changes to the legislation or government reporting
requirements.

Essential (E) changes are changes that the University stakeholders consider it impossible to do
business without. Again, manifestation of such will be as the result of a failure during the analysis and
design leading to the functional specification.

Desirable (D) changes are changes that stakeholders advise would facilitate and optimise operations.
Almost without exception, these should be deferred from the initial implementation scope and, instead, be
scheduled as post-implementation production enhancements.

Nice to Have (N2H) changes are changes that, if the University had infinite resources, infinite funds and
infinite time, would marginally enhance the implemented solution. They will always be deferred from initial
scope, and post-implementation, will always stand behind desirable changes. Most often, N2H are “in our
dreams, but not in our lifetimes”.

Page 30 of 94
Any stakeholder of the project may submit a change request. All change requests are to be assigned to
the project manager in the first instance. The project manager will then assign one of his/her team
members to analyse each request, including a high level cost/benefit analysis.

After this preliminary analysis, it is the responsibility of the project sponsor to decide whether the change
will be included in the initial implementation, deferred to post-implementation, or rejected.

A good scope management process is essential to delivering the commitments documented in the project
charter. When changes are rejected, the stakeholder who requested such change is going to need to
understand the reasons for that rejection; no-one likes to be told “no”.

The request for a change may arise at any time, so the change request process is ongoing throughout the
life of the project. It is best to establish a clear schedule for consideration of change requests, at least
once a month, and possibly weekly, depending on the duration of the project overall and the
deliverables/milestones impacted by the change request.

14.1 Scope creep considerations:

14.1.1 Impact analysis

Short term and long term consequences of implementing VS not implementing the requested change
need to be considered.
14.1.2 Cost analysis

Inevitably, the cost of including additional functionality within the project scope will be outside the original
project budget. However, sufficient funds should be provided in the original project budget for resources
to spend the time assessing the change requests themselves. Change analysis hours should be included
as scheduled and assigned tasks of selected project team members in the original project plan.
14.1.3 Mandatory changes

Consistent with the category, mandatory changes must be accepted and included in the project scope.
When mandatory changes are identified, the fact that it/they have been identified must be communicated
throughout the immediate and extended project team.

Page 31 of 94
15 Project Status Reporting
The project status report communicates project progress against project plans. Refer to Appendix H for
the format of a Project Status Report. Project Status Reports are distributed to the project sponsor,
project team, project steering committee, where applicable, user community and other interested
stakeholders. A Project Status Report must be produced no less frequently than monthly, on an agreed
date that enables reporting of budget VS actual expenditure for the month to which the Status Report
relates.

Preparation of a Project Status Report is essential to:

 report the progress of a project towards its objectives, as measured against the project plan
 evaluate progress, as measured against the success criteria detailed in the project charter
 report issues to the appropriate stakeholders and seek assistance through escalation, when and
as necessary

The purpose of a Status Report is to keep stakeholders informed. The reports must be concise and
honest. The level of detail in a report should be consistent with the audience to whom it is sent. The
report submitted to executive management/steering committee will be derived from, but be less detailed
than, the version provided to the immediate project team.

The Project Status Report is also a key mechanism to control the project. As work on the project
proceeds, the project manager will use the Project Status Report process to:

 compare actual progress to planned progress

 use the preceding comparison to determine the overall status of the project
 recommend or take appropriate actions based on the results of the comparisons

The project manager must be alert to potential or actual problems, look for trends in performance by
individuals or groups within the overall team and make good use of the issue log within the Project Status
Report as an early warning signal. Every team leader within a project team should submit a formal
Project Status Report to the project manager, who will then be kept fully informed and be able to ensure
that the overall Project Status Report reflects the project as a whole.

When a project runs into problems, controlling that project becomes even more difficult then when all is
proceeding to plan. During the project, the project manager may need to take critical decisions on
matters such as individual or team performance, user relationships, technical and management issues,
project organisation and project schedules.

The project manager must maintain a balance between the frequency of formal Status Reporting and the
need to respond to issues in a timely manner. Formal control involves procedure, effort and time.
Informal control allows quicker response, but involves more uncertainty.

Effective project control requires that information is timely and true. In times of difficulty, there is a
temptation to tell the user community what they want to hear, and for members of the project team to
conceal problems from the project manager. Inevitably, this is counter productive for the project overall.

The project manager must analyse project plans scrupulously to identify problems. The overall time spent
on the project may appear to be “spot on” to estimates. But, this could be caused because excess hours
have been spent on one or more tasks, while others that should have begun have not.

Page 32 of 94
The full functionality of Microsoft Project‟s variance analysis tools must be employed to ensure that the
project is genuinely on track.

16 Issue Management
To avoid having to spend time on problem management, regular monitoring, beyond just the facts as
represented in project status reports, needs to be undertaken by the project manager and team leaders.
If the project manager is not proactive in monitoring the overall project, then urgent issues will overtake
genuinely important ones and the “squeaking gates”, within either the project team or the broader user
community, will receive all the attention, while serious issues will arise from lack of attention in the early
stages.

Maintenance of an up-to-date “to do list” is never more important than in the context of a time driven
project. To do lists include items that don‟t warrant inclusion on the overall project plan, but which are the
essence of effective time management in any work environment. For projects in particular, the to do list
must be reviewed at the start of each day and updated at the end of each day. Outstanding items must
be prioritised according to their real importance, not someone else‟s definition of urgency. An effective
project manager must ensure that his/her involvement is constant and visible. The best way to do this is
to interact with each member of the team daily. A comprehensive round of good mornings, in the context
of genuinely meaning “how are things going” is a good discipline to adopt. Similarly, such daily contact
with key users is essential too.
A good project manager will track and manage use of his/her time very carefully, whether his/her time is
charged out or not. Maintenance of such records, by time intervals no less frequent than hourly per day,
will identify “time wasters” and excessive administrative overheads that distract from the real work of the
project.
Each week, the project manager should:

 Collect and collate project actual data, including,

 All details required for project status report (refer Appendix H)

 All tasks on project plan with scheduled completion dates for the ensuing week
 All tasks on project plan with past due scheduled completion dates
 Costs incurred during the preceding week

 Team meeting
A team meeting should be held every week, on the same day, at the same time, in the same
venue. Such a meeting should not exceed one hour.

Each attendee is required to:

 Have filtered the project plan for their own assigned tasks,
 Have prepared an individual status report, inclusive of:
o an issue log,
o explanations of any past due scheduled dates for their assigned tasks,
o proposed remedial actions to complete overdue task/s,
o Give a commitment to a revised completion date that takes account of the flow on
effects of such delay/s where the task is a prerequisite/predecessor of a
subsequent task.
Any and all issues raised must be documented and carried forward to the formal issue register, the format
of which is shown at Appendix I.
Page 33 of 94
Where any scheduled deliverable has slipped, the project plan must be revised accordingly.

Formal Minutes of this weekly meeting must be kept. Usually, the role of Minute taker will rotate through
the attendees, excluding the project manager. Alternatively, if the project has been assigned
administrative support, the same person will take the Minutes each week.

Pursuant to the weekly team meeting, the project manager should meet with the project sponsor to
discuss and update the status of open issues and any outstanding change requests.

Each month, prepare the comprehensive, collated and complete Project Status Report, in accordance
with Appendix H:

 Update the project plan

 Update the project budget; summarise the actual expenditure compared to the budget for the
month by each budget category (capital expenditure, operating expenditure) on the status
report, but ensure that the variances are captured to line item before such summary is created.
 Review and update the issues log
 Review and update the change request log

When an issue attains amber or red status, it may be considered a problem and requires corrective
action. Depending on the impact of a problem, such action may need to be immediate, or scheduled into
the project plan for a future date. Any problem constitutes a risk to the success of the project.

Page 34 of 94
17 Risk Management

With reference to AS/NZS 4360:1999 “Risk Management”, the magnitude of risk is assessed according to
the following matrix:

High/ High/ “Unacceptable” Risk

Almost Significant Severe Severe
major major
Certain N5 (V5) (E5) Ratings
L5 M5
(5)

High/ High/
Likely Moderate Significant Severe
major major
(4) N4 L4 E4
M4 VH4
Likelihood

Low/ High/ High/

Moderate Moderate Significant
trivial major major
(3) L3 M3
N3 VH3 E3

Low/ Low/ High/

Unlikely Moderate Significant
trivial trivial major
(2) M2 V2
N2 L2 E2

Low/ Low/ Low/

Rare Moderate Significant
trivial trivial trivial
(1) V1 E1
N1 L1 M1

Negligible Low Medium Very High Extreme

(N) (L) (M) (VH) (E)

Consequence

Risk management requires that risks be determined, assessed, prioritised and controlled.

Effective risk management is an ongoing discipline throughout the life of any project. Regular review of
the project plan will manifest uncertainties which may constitute risks. Risks are contingencies that may
adversely impact the budget, the timeliness of deliverables and, ultimately, the implementation date, or
the extent to which the project, upon implementation, actually meets the end-users requirements.

Risks which, upon assessment, are determined to be within the red, amber or yellow sectors of the matrix
above require preventative measures to be put in place. Categorisation of risks in accordance with the
matrix automatically assists prioritisation, as “High/Major” obviously constitutes a greater risk than
“Significant”. It will still be necessary to prioritise risks within each of those categories and this requires
that the potential consequences be considered.

Risks can be mitigated by reducing either the likelihood or the consequence. Likelihood can be reduced
by proactive mitigation strategies. Piloting a project implementation in a small self-contained functional
area is a standard risk mitigation measure. All mitigation strategies must be assigned to a specific
person/role who will be accountable to implement the resolution. This assignee will also be responsible,
as the project manager‟s delegate, to monitor the risk, to take appropriate preventative action and to
recover from the impact if preventative measures fail.

Page 35 of 94
All project risks need to be put into the context of the three standard project measurables; cost, delivery
schedule and user satisfaction.

Some risks have been shown to be inherent in projects and can be anticipated; others will arise and
require action that has not yet been incorporated into the prevailing body of experience. That a project
will be late is not a risk, it is the consequence of a risk that has not been managed appropriately. Some
generic project risks, derived from prior experiences among project managers, are shown in the table at
Appendix J.

Page 36 of 94
18 Communication Management
Effective communication within a project environment is the key to not only ensuring that all stakeholders
are kept informed of the project‟s progress but the appropriate opportunities are created for them to
provide the necessary inputs into the process. Without appropriate channels of communication the project
is susceptible to a number of significant risks including:

 misinterpreted objectives – leading to undesired project outcomes

 incorrect emphasis on priorities with regards to budget, quality and scope management
 resistance to change – leading to possible problems with the implementation phase
 decreased momentum or stalling – leading to slippage and lowered quality

To mitigate the risks associated with poor communication it is necessary to include a communications
section as part of the Project Plan or create a separate Communications Plan as an attachment outlining
the communication strategies that will be used during the course of the project.

Before attempting to develop a communication plan the project manager should conduct a stakeholder
analysis. This can be as simple as compiling a list of project participants and customer groups, to
performing an in-depth analysis producing comprehensive stakeholder profiles. The choice of complexity
should be based on the nature and complexity of the project but the most important information that
should be gathered includes:

 Name, contact details and their functional role (individual)

 Group name/description and functional role (group)
 Project role or interest in project
 Responsibilities in project
 Specific requirements already flagged by stakeholder
 Training needs

Once this process is complete the methods and frequency of communication and interaction can be
mapped to each stakeholder and incorporated into the communication plan.

Communication during the project can be by various methods, including:

 Project team meetings

 Steering committee meetings
 Project status reports
 User forums and discussion groups
 Newsletters
 Training sessions
 Conferencing and workshops

The communication plan should include the following information:

 A list of stakeholders and the selected methods of communication, the frequency and content for
each
 Roles and responsibilities of staff for each communication noted
 A strategy for dealing with unscheduled communications
 Details of mechanisms for stakeholder feedback
 A strategy for the communication of major issues, risks and changes to the project‟s scope
Page 37 of 94
Project communications are essential to the coordination of project tasks and events and as such should
be included items in the project schedule. The integration of communication tasks into the schedule will
lessen the chances of them being overlooked.

The communication plan should be reviewed and changed as needed throughout the project and a
number of questions should be asked:

 Is the information being communicated meeting the needs of its intended audience?
 Is the information presenting the true status of the project?
 Do all project team members and other stakeholders understand their role and responsibilities?
 Have all project team members and other stakeholders met their obligations?
 Has the communication schedule been adhered to?

Communication in a project environment is an ongoing process that is often overlooked. By going through
the process of developing plans and strategies the project is more likely to succeed.

A communication plan template has been included in this handbook (see Appendix K)

Page 38 of 94
19 Project completion
A project will have been completed successfully when it has met all of the objectives and success
criteria detailed in the project charter. A project may also be completed by virtue of being abandoned.

Project completion is the point at which the project will be evaluated for addition to the cumulative
knowledge base that will help assure the success of future projects. Project acceptance needs to be
documented; the following is an example of an appropriate document for sign-off by the project
owner/project sponsor and other identified key stakeholders.

PROJECT COMPLETION APPROVAL AND ACCEPTANCE

Project Name: Project Manager: Date:

Completion statement:

Additional comments:

Approvals (position title/name/signature):

Page 39 of 94
20 APPENDIX A –DATA MODELLING

19.1 Conceptual data modelling

Conceptual data modelling is the first stage in the process of top down functional analysis. The aim is to
describe the information used by an organisation in a way which is not governed by implementation-level
issues and details. It should make it easy to see the overall picture so that non-technical staff can
contribute to discussions.

A common method of analysis involves identifying:

1. the ENTITIES (persons, places, things etc.) which the organisation has to deal with.

2. the ATTRIBUTES - the items of information which characterise and describe these entities.

3. the RELATIONSHIPS between entities which exist and must be taken into account when
processing information.

In the abstract, or illustrated by superficial examples, this looks a very simple idea. An explanation may
put forward a car as a typical entity, point to make, colour, registration number as obvious attributes, and
suggest owning and driving as relationships in which it takes part. But applying the method of analysis to
some useful purpose in a working organisation will be difficult, simply because the world does not fit so
neatly into boxes.

19.1.1 Entities.

20.1.1.1 Defining
In a global data model for a hospital, for example, the entity names employee and patient are likely to
occur. In some situations the same individual may be both an employee and a patient; is s/he one entity
or two? In such a case it is more accurate to define a fundamental entity such as a person able to take a
role in the relationship.

Note: the name given to an entity should always be a singular noun descriptive of each item to be stored
in it. e.g. student NOT students
20.1.1.2 Composite entities
Sometimes an entity may be considered as a single entity or as multiple entities. For example, a firm may
have a number of different premises for the delivery of goods or supply of services - multiple entities - but
one head office for the payment of accounts - a single entity. Similarly, a single object - e.g. an aeroplane
- may be made up of many components. These components have a hierarchical / recursive relationship:
e.g. A is made up of B and C which in turn are made up of X, Y and Z. It is impossible to treat such
entities at a single level; for example the CAA has rules about the expected life of different aircraft
components but these must be related to the flight history (take-offs, landings, flight hours) of the plane in
which they are fitted.
20.1.1.3 Aggregates
For some applications, e.g. stock control of low cost items, we are not concerned with individuals but with
AGGREGATES - e.g. how many cans of baked beans are in the warehouse? It is easy to overlook the
fact that a definition refers not to an individual but to a type of object. More problems arise when
manufactured objects change status part-way through their lives - a car on an assembly line may be
indistinguishable from those immediately before and after it, but it must at some point acquire an
individual identity for sale and registration.

Page 40 of 94
 20.1.1.4 Sub-classification of entities
The need for sub-classification of entities arises frequently. For example, a transport pool handles
resources which in a global data model might be all classed as vehicles. Although certain attributes and
relationships may be common to all vehicles, they are not inter-changeable and for practical purposes
must be subdivided into vans, lorries, limousines, etc. each with their own particular characteristics.
20.1.1.5 Physical boundaries
It may be difficult to determine the physical boundaries of entities which are identified primarily by
geographical location. For example, a motorway is a road which is part of one continuous system; it may,
however, be necessary to specify points on the motorway, where one section stops and the next begins.
20.1.1.6 Events
So far we have been talking about entities which are fairly tangible objects; however, there are many
more that are more abstract, for example a sale or a birth. In terms of the overall model these are events
which trigger off processes. Nevertheless, we may wish to count them, attach attributes to them, and
relate them to one another, as if they were entities. The more abstract the entity, the more difficult it is to
decide whether it should really be classed as an event or a relationship.
20.1.1.7 Messages
Similar difficulties occur with entities which exist only as messages within an existing clerical business
system. As a piece of paper, a receipt is a tangible object, but it is doubtful whether it should be a first
class citizen of a conceptual data model, since in different technological situations its functions could
equally well be performed by a notch on a stick or a series of pulses on an electronic document
interchange (EDI) network.

As these examples indicate, entities are not easy to pin down and compromise is required between a
fruitless search for some ultimate truth and a short-term expedient which will break down as soon as it is
seriously tested. It is necessary to consider the purpose for which the information is being collected, what
sort of questions are likely to be asked and how future developments may require the initial requirements
specification to be extended.

19.1.2 Attributes.
Attributes are pieces of information ABOUT entities. The analysis must of course identify those which are
actually relevant to the proposed application. Attributes will give rise to recorded items of data in the
database so it is important that nothing potentially useful is omitted here even though not all may be
included later.

At this level we need to know such things as:

 attribute name.

 the domain from which attribute values are taken.

 whether the attribute is part of the entity identifier.

 whether it is permanent or time-varying.

 whether it is required or optional for the entity.

Page 41 of 94
 19.1.2.1 Attribute names.
Names should be explanatory words or phrases; coding and/or abbreviations should be postponed until
the implementation level. They should enable users of the data model to see what is being recorded, and
identify where the same piece of information occurs in different places (e.g. through a DATA
DICTIONARY.)
19.1.2.1 Domains
A DOMAIN is a set of values from which attribute values may be taken. Examples are: dates, sums of
money, temperatures, grid references, colours, gradings and nationalities. In one way the more definite
we can be here the better - it is more helpful to know that an attribute is a linear measurement than that it
is a number - but precise formatting specifications are not required. A date is a date, however it is stored
or presented, and the conceptual data model is not the place to specify that it is a six-digit number in the
format ddmmyy. On the other hand it will be useful to know the kind of accuracy which may be expected
for this attribute - is the measurement to the nearest day, week or year?
19.1.2.2 Identifier attributes.
We must distinguish between attributes which just describe an entity (and perhaps change over time), and
those which help to identify it uniquely. This will certainly influence the lower level design. But some care
is required. In natural discourse very few things have one unique name or identifying attribute - they are
distinguished by a combination e.g. name, address and date of birth for a person. In formal business
systems, it is convenient to give unique but arbitrary labels to persons or objects (e.g. National Insurance
Number, Vehicle Registration Number) so as to have quicker and easier means of identification. But
however convenient such KEYS are at the implementation level they should not be introduced into the
conceptual design unless they are already familiar to users of the information, and there is an
understandable process for getting from the entity itself to its identifying attribute.
19.1.2.3 Time-varying attributes.
It is important to know which attributes may change their values over time, as they will have to be updated
when the system is implemented. It may also be necessary to hold previous values somewhere for
AUDITING or the production of HISTORICAL REPORTS.
19.1.2.4 Optional attributes.
Entities may have attributes whose values will sometimes be unknown or irrelevant. This happens with
very general entities such as vehicle more often than with those more narrowly defined. A record of which
attributes are OPTIONAL or MANDATORY will help when defining general consistency constraints for the
data base at lower levels.

19.1.3 Relationships
In many applications one external event or process may affect several related entities, requiring the
setting of LINKS from one part of the database to another. Important information to be recorded is:
19.1.3.1 Number and type of roles
Like an attribute, a relationship should be named by a word or phrase which explains its function. The
same applies to the role names within the relationship, e.g. owner, driver etc. Role names are different
from the names of entities forming the relationship: one entity may take on many roles; the same role may
be played by different entities. Where a relationship is symmetrical (e.g. 2 roads intersecting) role names
are arbitrarily assigned.

An important point about a relationship is how many entities participate in it. In practice BINARY
RELATIONSHIPS are most convenient for data modelling; however it is by no means the case that all
relationships must necessarily be binary in this sense. For example, consider a model built around vehicle

Page 42 of 94
manufacturers, types of vehicle and garages. In such a model we may wish to represent the information
specified by a TERNARY RELATIONSHIP e.g.

 (Vehicle_Manufacturer, Vehicle_Type, Garage)

 Vehicle_Manufacturer supplies Vehicle_Type to Garage.

This ternary relationship is not in general equivalent to the combination of the three binary relationships:

 Vehicle_Manufacturer SUPPLIES Vehicle_Type

 Garage SELLS Vehicle_Type

 Garage IS SUPPLIED BY Vehicle_Manufacturers

For example the information that:

1. Ford supplies cars to Hills

tells us more than the combination:

2. Ford supplies cars

3. Hills sells cars

4. Hills is supplied by Ford

Relationships (2), (3) and (4) only tell us that:

 Ford supplies cars to some garage(s)

 Hills sells cars supplied by some supplier

 Ford supplies some type of vehicle to Hills.

One cannot validly infer (1) from (2), (3) and (4); e.g. it may be that Hills only sells Ford trucks, not cars.
The false inference (2, 3, 4) => (1) is sometimes called the connection trap.
19.1.3.2 Degree
Relationships may be:

 ONE-TO-ONE, e.g. Building - Location,

 ONE-TO-MANY, e.g. hospital - patient,

 MANY-TO-MANY, e.g. Author - Book.

 RECURSIVE, e.g. Manager - Employee.

To decide the DEGREE of a relationship one must be clear about whether individuals or types are
involved. The relationship (vehicle_manufacturer, vehicle_type) is one-to-many if we are talking about an
individual manufacturer, but many-to-many where (vehicle_manufacturer, vehicle_type) are types.

Consider also the time dimension - whether the relationship is being recorded at a single point in time or
over a period of time. For example, in Britain the legal relationship husband-wife is one to one in the first
case, but potentially many to many in the second.

Page 43 of 94
 19.1.3.3 Optionality
A relationship may be required or optional for either participant, e.g. a piece of property must be owned by
a person but not all persons need own a piece of property.
19.1.3.4 Permanence
A relationship may be defined as permanent (e.g. parenthood) or temporary (e.g. ownership or
employment). If temporary but required by one of the participants (e.g. ownership) it must be transferable.
19.1.3.5 Dependencies
One relationship may necessarily exclude or imply another, or be excluded or implied by another.
Membership of the City University Students Union necessarily implies membership of the University itself.

Many of the above constraints will require consistency checks on incoming data. Some database
management systems (DBMS) allow such checks to be declared as part of the logical data model so that
they are applied automatically whenever the data base is updated.

Page 44 of 94
19.2 Logical Data Modelling
Logical data modelling is a graphic-intensive technique that results in a data model
representing the definition, characteristics, and relationships of data in a business, technical,
or conceptual environment. Its purpose is to describe end-user data to systems and end-user
staff.

Various methods of data modelling exist, each using a host of conventions and tools. The
most popular approach is called the entity-relationship (ER) approach, developed by Peter
Chen in the late 1970s. Although a number of authors and tool designers have modified and
expanded ER concepts, most still have a strong Chen flavour. Also, with the introduction of
CASE tools, the number of diagrammatic conventions that the data modeller must master has
increased sharply.

19.2.1 Data Modelling Objects

The three types of data objects--entities, attributes, and relationships--are the basic building
blocks of modelling:
 Entities are persons, places, or things about which an organization wishes to save
information. Employees, States, Orders, and Time Sheets are examples of entities. (As
a convention, I capitalize the first letter of entities.)

 Attributes are the properties of entities. Attribute examples include Colour,

Employment Date, Name, and Tax File Number.

 Relationships are verbs that describe how entities relate to each other; for example:
'Customers Buy Products,' 'Employees File Time Sheets,' 'Salespeople Place Orders.'
A sentence in this entity-relationship-entity construct is called a "relationship entity
pair," which is a fashionable mechanism for representing relationships. Relationship
entity pairs are bidirectional. Therefore, 'Customers Buy Products' is the same as
'Products are Bought by Customers.' "Relationship" describes an end-user
relationship, not a technical one.
While a number of graphical conventions represent data objects, one convention on which all
the different approaches seem to agree is the use of a rectangular box to represent an entity.
Relationships are represented by a line. However, for various reasons, including time, space,
and laziness, modellers often do not label relationships in both directions. One reason is that it
is often unnecessary to label the relationships if the meaning of the relationship is easily
understood.

19.2.2 Relationship diagrams

The conventional way to show relationships is shown in the following diagram:

Page 45 of 94
Proper procedure is to label all relationships in both directions, as shown in the top figure
(plumbers prepare pipes/pipes are prepared by plumbers). However, many modellers place
the relationship in a diamond, as shown in the bottom figure (seamen sail ships/ships are
sailed by seamen).

19.2.3 Attribute diagrams

Attributes are diagrammed in several different ways or not diagrammed at all. Some modellers
place attributes in the entity box while others use ovals to hold attribute names:

However, it is common practice not to place attributes on a diagram at all. Simple models,
such as those above, are illustrative. In real analysis exercises, an entity may have so many
attributes that a diagram becomes unreadable. A more practical approach is to keep attributes
out of the data model and in the data dictionary.
19.2.3.1 Type/Occurrence Distinction

Before proceeding, the distinction between an entity type and an entity occurrence or instance
needs to be understood (“occurrence" and "instance" being interchangeable.).

An entity type represents the class of objects that share a distinguishing factor. An occurrence
is a single case or instance of a type. For example, "Detective" is an entity type, while
"Sherlock Holmes," "Hercule Poirot," and "Ellery Queen" are entity instances. The distinction
between entity type and entity occurrence is the same as the distinction between record type
and record occurrence.
To say that entity type 'A' relates to entity type 'B' means that one or more occurrences of 'A'
are (or can be) related to one or more occurrences of 'B.' If this argument sounds familiar to
you, it might be because you studied a similar issue in your college philosophy class.
Philosophers have what they call the "type token distinction," where 'Man' can represent the
set or 'type' of all men (or women), and 'Socrates' represents a single 'token' or occurrence of
that set. Attributes and relationships, like entities, have types and occurrences. The distinction
between type and occurrence is important for understanding the data modelling concepts of
cardinality and modality, which are the two characteristics of relationships.

Page 46 of 94
19.2.3.2 Membership Class (Connectivity Characteristics)

If entity 'A' relates to entity 'B,' knowing more about how the occurrences of 'A' relate to the
occurrences of 'B' is important. One concern is the cardinality of the relationship.
Cardinality5 is the specification of the number of occurrences of one entity type that can be
related to the number of occurrences of another entity type. Cardinality is usually expressed
as simply "one" or "many." For example, a husband can have only one wife (in most cultures),
while a parent can have many children. Thus, two entities can be related as:
 One-to-one (1:1)--An occurrence of entity 'A' can relate to one and only one
occurrence of entity 'B,' and an occurrence of 'B' can relate to only one occurrence of
'A.' For example, a husband can have only one wife, and a wife can have only one
husband (at least here in New Jersey).
 One-to-many (1:N)--One occurrence of entity 'A' can relate to one or many
occurrences of entity 'B,' but an occurrence of 'B' can relate to only one occurrence of
'A.' For example, a mother can have many children, but a child can have only one
mother.
 Many-to-many (M:N)--An occurrence of entity 'A' can relate to one or more
occurrences of 'B,' while an occurrence of 'B' can relate to one or more occurrences of
'A.' For example, an uncle can have many nephews, and a nephew can have many
uncles.
The most popular way to represent cardinality is to use a bar to express one and a trident
(also called a "crow's foot" or "chicken foot") to express many:

5
The term cardinality refers to the number of cardinal (basic) members in a set. Cardinality can be finite (a non-negative integer)
or infinite. For example, the cardinality of the set of people in the United States is approximately 270,000,000; the cardinality of
the set of integers is infinite.

In tables, the number of rows is called the cardinality. In practice, tables always have positive-integer cardinality. The reason for
this is simple: tables with no rows, or with a negative number of rows, cannot exist. In theory, however, tables with infinite
cardinality can exist. An example is a multiplication table of non-negative integers in which entries are implied for all possible
values:

0 1 2 3 ..
1 1 2 3 ..
2 2 4 6 ..
3 3 6 9 ..

The concept of cardinality is of interest to set theoreticians because it has been used to demonstrate that some infinite sets are
larger than others. The cardinality of the set of real numbers is greater than the cardinality of the set of integers, even though both
sets are infinite. The cardinality of the set of integers is called aleph-null or aleph-nought; the cardinality of the set of real numbers
is called aleph-one.

Page 47 of 94
However, several other approaches and diagramming conventions exist:

Note that Chen and Reiner use a diamond to represent a relationship, while the Trident
approach uses a line. (For a discussion of the Reiner technique, see Reiner et al., "The Data
Base Design and Evaluation Workbench [DDEW] Project at CCA." Database Engineering
7(4):10-15, 1985.) The diamond does a better job of representing certain types of
relationships, but it is not as good at showing the bi-directionality of relationships. Chen
represents cardinality by using a 1, N, or M on the relationship line, while Reiner fills in the
diamond. Also, most tools now use the trident to show a cardinality of many, while some give
the user a choice of symbols.

In contrast to cardinality, the modality of a relationship indicates whether an entity occurrence

must participate in a relationship. Cardinality tells you the maximum number of entity
occurrences that can participate in a relationship, while modality (also called optionality) tells
you the minimum number of occurrences. The modality values are zero if an occurrence is not
needed or optional, and one if an entity occurrence is required or mandatory.

Take the example of Invoice and Line Item entities: An Invoice occurrence can relate to many
Line Items, but a Line Item can relate to only one Invoice. This tells you the cardinality. But is it
possible to have a Line Item occurrence not related to an Invoice occurrence? The answer, of
course, is no. For a Line Item to exist, it must be linked to an Invoice. Therefore, the
relationship is mandatory. The same is true in the other direction. It makes no sense to have
an Invoice without a Line Item. The relationship is mandatory in both directions.

A bar represents a modality of one, while a circle represents a modality of zero. The following
diagram shows relationship entity pair, 'Artists Paint Pictures.':

Because it is impossible to have a picture without an artist, the relationship 'Pictures Are
Painted by Artists' is mandatory. However, it is possible to have Artists who are not related to
any Pictures (just go into Greenwich Village some Saturday night); therefore, in the other
direction, the relationship is optional. When dealing with the modality of a relationship,

Page 48 of 94
modellers usually refer to the "one" end of a one-to-many relationship first. This relationship,
then, is mandatory-optional.

There may also be optional-optional relationships. For example, the relationship 'Banks
Finance Cars' is optional-optional, because you can have a bank that doesn't finance cars,
and there are cars that are not financed.

Most data modellers use the term "optionality" instead of modality. This is an awkward and
unfortunate use of the term because the optionality of a relationship could be either optional or
mandatory. While an optional optionality appears redundant, it is not as bad as the seeming
contradiction of a mandatory optionality.

Modality is a term from modal logic. It is used to distinguish necessary statements (in which
truth is necessary or mandatory) from contingent statements (in which truth is conditional or
dependent on external conditions). Modality is, in fact, a more accurate, meaningful, and less-
confusing term than optionality.

By now you have probably noticed that the bar specifying a cardinality of one can usually be
inferred, because a cardinality of zero is impossible. However, the cardinality bar does serve a
purpose. Because modellers do not always know the cardinality of a relationship, they must
have a way to distinguish not knowing from one. Note that many tool vendors do not require,
nor do some allow, a bar for a cardinality of one. In that case, the best practice is to specify
the nature of the relationship in the relationship description.
19.2.3.3 Degree
Relationships can have any number of entity types associated with them. When an entity type
is related to itself, the relationship degree is called unary or recursive. For example, a child
can be related to another child through the relationship 'Sibling.': This is a unary, or recursive
relationship, that is, an entity type is related to itself

.
The most common relationship is the binary relationship that links two entity types.
N-ary relationships are those involving more than two entity types, such as 'Customer Buys a
Car from a Dealer.':

Page 49 of 94
All data modelling tools support binary relationships, and most support unary relationships, but
only a few support n-ary relationships. The reason is that most database management
systems (DBMS) support binary relationships only.
19.2.3.4 Attribute Values
As with entities and relationships, there are attribute types and attribute occurrences. An
attribute value is an instance or occurrence of an attribute type. An attribute value is a
characteristic of or fact about an entity occurrence. The fact might be that the entity's Colour is
"blue" (the convention is to place attribute values in double quotes) or that the AUTHOR
NAME is "Thomas Rowley."
Attribute values are what data processing is all about. They form the core of information
management and represent the most tangible and least abstract aspects of all data
processing.

Many data modellers divide the world into data and metadata. Data consists of tangible data
values, such as "blue," "French fries," and "mustang." Metadata is data about data. For
example, the attribute type Menu Item tells us something about the attribute instance "curried
pancakes," while the entity type Employee tells us something about the instances of
"employee." These objects are called metadata because they are one step removed from the
data.

19.2.3.5 Domains
A domain is the set of possible values an attribute type can have. Examples of domains
include: dates, text, integers between 200 and 399, real numbers with two decimal places,
state abbreviations, and so on. However, while "July 11, 1983" is an acceptable value for
Employment Date, "Curried Pancakes" is not.
Domains are important because they tell you not only what the acceptable values of an
attribute are, but also how to use the attribute. For example, the statement: "Medical Coverage
= 'Yes' if Claim Date is greater than or equal to Employment Date and less than or equal to
Termination Date" makes sense only if the values for Claim Date, Employment Date, and
Termination Date share the same domain.

If Claim Date = "May 5, 1987," Employment Date = "July 11, 1983," and Termination Date =
"123 South Main Street," the results will be quite unpredictable.

Domains can be specific or generic. Generic domains, such as 'integer,' 'text,' or the ever-
popular 'alphanumeric,' are the easiest to work with, but they're also the least meaningful.
Domains such as 'Dates between 1/1/50 and 12/31/94' or 'acceptable Zip codes' are more
useful.

Domains can also be nested; that is, the scope of one domain can incorporate another. The
domain 'Dates between 1/1/50 and 12/31/94' is incorporated in the domain 'Dates,' which, in
turn, is incorporated in the domain 'Integers,' and so on.

There are three main types of domains:

 A data type is a programming language term that identifies broad domain categories,
such as integers, real numbers, and text, as well as the more specific dates, financial
numbers, and U.S. dollars.

Page 50 of 94
  Ranges, such as dates between 1/1/1950 and 12/31/1967, non-negative values (for
example, real numbers between 0 and 4.0), and last names beginning A to J, indicate
which values between two end points are acceptable.

 Acceptable Values, such as street names, suburbs, post codes and State names are
the most specific types of domains. They specify the only values an attribute can have.
Thus, the acceptable values for the Gender attribute would be "Male" and "Female." In
effect, a domain hierarchy is created with the data type at the highest level and
acceptable values at the lowest.
The entity-relationship (ER) approach to logical data modelling does not end here. What has
been set forth in this article is just a cursory view of some rather complex notions involved in
data modelling. The following figure shows how the topics discussed in this appendix relate to
each other.

The preceding article was written by George Tillmann who is a principal with New York-based
Booz-Allen & Hamilton's Information Technology Group.

Page 51 of 94
19.3 Physical Data Model6
19.3.1 Overview
This section describes the generation of the Data Archive Physical Data Model (PDM), as
described by the Infrared Space Observatory (ISO) and should be used to aid further
understanding of the detailed descriptions hereinafter.
A PDM represents the structure of the data as it will be implemented in the database. The ISO
Data Archive PDM was originally generated from the ISO Data Archive Conceptual Data
Model (CDM) taken into account the features and physical restrictions of the Data Base
Management System (DBMS) which is used to implement the ISO Data Archive PDM.

19.3.2 Generating the Data Archive PDM

The ISO Data Archive PDM is generated from the ISO Data Archive CDM by translating
conceptual objects into physical objects, as shown below:
Object in a CDM Generated object in a PDM
Attribute Column
Entity Table
Identifier Primary or foreign key depending on independent or dependent
relationship
Relationship Reference
Independent one-to-many relationships
In independent one-to-many relationships, the identifier of the entity on the one side of the
relationship becomes a:
 primary key in the table generated by the entity on the one side of the relationship
 foreign key in the table generated by the entity on the many side of the relationship.
Dependent one-to-many relationships
In dependent relationships, the identifier of the non-dependent entity becomes a
primary/foreign key in the table generated by the dependent entity.
Independent one-to-one relationships

In independent one-to-one relationships, the identifier of one entity migrates as a foreign key
to the table generated by the other.

Independent many-to-many relationships

In independent many-to-many relationships, the identifiers of both entities migrate to a join

table as primary/foreign keys.

6
Source of definition is http://www.iso.vilspa.esa.es/ida/pdm/pdmp6.html

Page 52 of 94
19.3.3 ISO Data Archive Physical Data Model – example:

Page 53 of 94
21 APPENDIX B – PROJECT CHARTER FORMAT
Substantial information required to be included in the project charter will be extracted directly
from the business case upon which approval of the project was based. The project charter
brings this information together with other information critical to the project‟s ability to achieve
the benefits represented in the business case. The business case, unlike the project charter,
is a static document for reference in the post-implementation review to evaluate the success of
the project.

Section Contents

I. DOCUMENT CONTROL DETAILS

 Author
 Contributors
 Revision Dates and descriptions

II. DISTRIBUTION LIST

III. ENDORSEMENTS AND APPROVALS

1. EXECUTIVE SUMMARY
High level summary of the Project Charter for senior management review

2. KEY STAKEHOLDERS

Name and position title of stakeholders in the Project, together with a short
description of the strategy that will be used to liaise with those stakeholders to
ensure their “buy-in” to the Project.

3. STATEMENT OF THE BUSINESS REQUIREMENT

Explicit definition of the business need being addressed, expressed in terms of
the functional area objectives that need to be met.

4. PROJECT OBJECTIVES
The statement of objectives specifies the outcomes sought to meet the
business need described in Section 3. Ensure that the project‟s objectives are
consistent with the objectives of the University as a whole. It is essential to
define the objectives clearly, as their realisation will determine the outcome of
the evaluation of success in the post-implementation review. Objectives
should follow the “SMART” approach:
 Specific
 Measurable
 Achievable
 Realistic
 Time-driven

Page 54 of 94
5. PROJECT SCOPE
The scope of the project specifies the activities and defines the boundaries of
the work to be done. It identifies the deliverables required to meet the project
objectives. This guides the further design of the system and the use of
resources in its implementation and operation.
The project scope needs to be very specific in describing what will be
produced, how long it will take to deliver the specific outcomes, and how much
it will cost to deliver those outcomes.
It is essential to obtain the approval of the project sponsor to the project
scope, otherwise the project cannot succeed. Time, cost and deliverables are
inextricably interrelated. If the project sponsor cannot fund the cost, then
deliverables will need to be reduced. If an implementation date is mandated
that is not achievable with current resources, then extra resources will need to
be funded, etc. If the project sponsor does not sign-off on any one of time,
cost or deliverables, then the project manager will need to work with the
project sponsor to reconcile the scope and objectives and change the project
charter accordingly. This can be achieved by any one of:

 making changes to goals, objectives and/or deliverables

 changing the scope; if the scope seems unachievable within the
available time and budget then in all probability it will be and the
project will fail,
 doing more analysis of the underlying baseline assumptions and
refining those assumptions.

6. KEY DELIVERABLES
A detailed project plan will not be developed until the project manager begins
work in earnest, but this section of the project charter must include a high level
summary of that subsequent detailed plan.
It is essential to ensure that the list of key project deliverables is complete.
Any omission will adversely impact the project cost estimates. Deliverables
need to include not only writing programs or implementing revised procedures
and processes, but also the time and resources required to convert data from
current systems, whether manual or computerised.
Each deliverable must be allocated specific completeness and correctness
criteria that constitute acceptance criteria for the final product.

7. MILESTONES & DEPENDENCIES

Milestones at specific points in the project, short of completion, need to be
identified as check points to evaluate the progress and quality of the project, to
avoid waiting until the day before implementation to determine that the project
is a failure or success.

Page 55 of 94
8. INFORMATION AND PERFORMANCE REQUIREMENTS
This section details the proposed system‟s requirements, in terms of
functionality, accuracy, timeliness, frequency, criticality, etc., that support the
project‟s scope and objectives. Management information requirements,
including security needs, are stated separately from operational information
needs.
• Gather relevant information about the business operations, documents,
reports, processes, procedures and business rules that are used to achieve
the business objective
• If the requirement is for a totally new computer application, then analyse
the current system to see whether any of its components warrant
retention, as interfaces to the new system.
• Document the business processes in a process map that represents the
business activities that support the end-to-end process. This will enable
identification of data flows relevant to the information system.
• When requirements have been defined fully in the mapping and analysis of
the business processes, identify those which are most appropriately
handled by a computer application and those that are more effectively and
efficiently kept as, or created as, manual systems.
• Based on analysis of the information gathered, the use to which the
information is put needs to be determined, including an analysis of the data
that will need to be used to give the required information to the end-user.
• The systems objectives for the end-user functional requirements can then
be documented and ranked in order of importance to the business
objectives according to the categories of mandatory, essential, desirable
and nice to have. End users will insist on describing their wants, but it‟s
essential to ensure all functions are prioritised, which will assist in
determining needs:

The objective is to define what the system, whether computer based or

manual, is required to do to support the business (i.e. specify its functionality).
It is essential to understand the University‟s business processes and business
needs. It is inexcusable to contrive to justify purchase of a third party solution
then try to manipulate the University‟s business needs and processes to fit it

If buying a third party solution, thorough analysis of to what extent the

package does not meet the defined business needs, in the form of a gap
analysis, is essential. This cannot be done unless the functional analysis and
specification (needs analysis) has been documented to an appropriate level of
detail to enable a clear gap analysis of any third party solutions.

Page 56 of 94
22 APPENDIX C - Critical Path Analysis (CPA)
The critical path is the longest path through the project from start to end. If tasks that are on
the critical path are delayed and fail to meet their scheduled delivery date, the end of the
project will similarly be delayed.

Dupont and Remington Rand devised the Critical Path Analysis technique in the 1950‟s, to
standardise the presentation of large projects. It is sometimes also called “critical path method
(CPM), or just “arrow network”.

CPA is a mathematical model that calculates the earliest possible start and end dates for each
task (forward pass), then the latest possible finish and start dates for each task (backward
pass). The critical path is, therefore, a sequence of tasks, each of which must finish on
schedule for the overall project to finish on time. There can be more than one critical path
within an overall project. An example of a CPA is:

Design Packaging Develop Packaging

Research Market Package Product

Design Product
Produce Product

Once the CPA calculation is finished, the contingency margin in non-critical tasks can be
determined. The contingency margin is the amount of time that a task can slip before it affects
the end of the project, and, therefore, becomes critical in it.

Calculating the critical path

The following example shows a project with two distinct paths, A-B-C-E-F and A-B-D-E-F:

eks
2 we 3w
C ee
ks

3 weeks 3 weeks
A B 4 weeks 5 wee
ks E F
D

The first calculation is the Forward Pass, which determines the Early Start (ES) and Early
Finish (EF) dates for each task. This is the earliest possible time that the task can start and
finish.

Page 57 of 94
 FORWARD PASS

BC CE
ES=3 ES=5
eks 3 w EF=8
EF=5 2 we
C ee
ks

3 weeks 3 weeks
A B 4 weeks 5 wee
ks E F
AB D EF
ES=0 DE
BD ES=7 ES=12
EF=3 EF=15
ES=3 EF=12
EF=7

The second calculation is the Backward Pass, which determines, firstly, the Late Start (LS),
then the Late Finish (LF) for each task. This is the latest possible time the task can start and
finish without adversely impacting the project‟s overall end date:

BACKWARD PASS
CE
BC ES=5
ES=3 EF=8
EF=5 eks LS=9
LS=7 2 we 3w
C ee LF=12
LF=9 ks

3 weeks 3 weeks
A B 4 weeks 5 wee
ks E F
AB EF
BD
D DE ES=12
ES=0
EF=3 ES=3 ES=7 EF=15
LS=0 EF=7 EF=12 LS=12
LF=3 LS=3 LS=7 LF=15
LF=7 LF=12
Upon completion of the forward and backward passes, the critical path, and the contingency
margin/s, can be determined. The critical path is shown above in the shaded circles (A-B-D-E-
F). The critical tasks are those where the early and late dates are the same. The contingency
margin available is calculated as:

Late Finish – Early Finish = Contingency Margin

Page 58 of 94
23 APPENDIX D - Program Evaluation and Review Technique (PERT)
The PERT chart graphically displays tasks as boxes, or nodes, with lines joining them to show
dependencies. The PERT chart is sometimes confused with a Critical Path Analysis (CPA).
The main difference is in how the PERT method calculates the estimated duration for a task.
A traditional PERT chart will also show task relationships accurately by the way the line joins
each node/box:

The PERT scheduling method was developed by Lockheed in 1958, for the Special Projects
Office of the United States of America‟s navy.

The methodology represents project timelines graphically according to the following

disciplines:

Start to Start
Finish to Start

Start to Finish Finish to Finish

Page 59 of 94
A PERT chart will appear as follows (in this instance specifically in Microsoft Project):

Page 60 of 94
24 APPENDIX E - Gantt Chart
Henry Gantt developed a bar chart, now called a Gantt Chart, during the First World War. The
chart is used to display tasks and durations as bars plotted against a timescale. The “Year
Planners” that many of us use in our offices is a derivative of the Gantt Chart. The Gantt
Chart is effective because it‟s simple. This advantage will be lost if project managers try to put
in too much detail. An example of a Gantt Chart is:

Page 61 of 94
25 APPENDIX F - Work Breakdown Structure (WBS)
The WBS is based on the deliverables that the work needs to produce. WBS is a
decomposition of the work required to achieve the specific set of deliverables. There are four
levels to WBS, each of which produces one or more deliverables or a part of a deliverable:

24.1 Phase

The highest level of WBS, below the Project itself, is a phase. Each phase (Initiation,
Planning, etc) has its own set of goals and objectives. Each phase produces a set of major
deliverables that feed into one or more future phases the overall project plan.

24.2 Stage

A stage is the largest logical unit of work within a phase. A stage groups a broad category of
related work and serves as the primary mechanism for planning, managing, and tracking
project activity at the highest level. In general, a stage produces one or more final
deliverables of the project. Stages are the best points to designate as project milestones for
peer/third party quality assurance (QA) reviews.

24.3 Activity

An activity groups a logical block of work that is smaller and more easily managed than a
stage. Generally, an activity produces a draft deliverable, or a part of a deliverable. Activities
provide the project manager with formal checkpoints for performing his/her own project quality
reviews and other aspects of the project control process.

24.4 Task

The lowest level of the work breakdown structure (WBS) is a task. A task generally produces
a part of a work product, such as a knowledge base object. A task can typically be assigned
to one individual, or to a team leader, and should take no more than 40 work hours of effort to
produce. The overall project work plan should be comprised of tasks.

The WBS is used to develop the work plan/project plan, but it is not in itself a project plan,
since it includes only the tasks that are directed related to the output of deliverables.

Page 62 of 94
26 APPENDIX G - BUSINESS CASE TEMPLATE

BUSINESS CASE
PROJECT NAME
Prepared by:
Contributors:
Audience:

Page 63 of 94
TABLE OF CONTENTS
Section 1 – Executive Summary
To be completed last
Section 2 – Statement of the business issue
What is the business issue that has resulted in the need to initiate a project?
Section 3 – Background and Business Drivers
What has led to identification of the current business issue? What are the adverse
consequences of continuing with the present processes?
Section 4 – Project Scope and Objectives
Describe the project and define the project scope from a “process” perspective clearly stating
where the process begins, and where the process ends. Describe what is included, and what
is not included in the project, including the organisations and functions involved, and list those
not involved. Describe those systems included in the project, and those that are not included.
Clearly state the project objectives, and the associated conditions of satisfaction (how will
success be measured). It is important that this section not only addresses the overall goals,
but also defines what success looks like for this project.
Section 5 - Evaluation of Alternative Solutions
This section addresses alternative solutions that would meet the business need, to varying
levels of effectiveness and cost. Describe the do-nothing scenario, and other alternatives
including incremental improvement projects. Alternatives should include selected sub-sets of
that solution.
Using the information gathered to complete previous sections, it should be possible to develop
a number of alternative solutions.

5.1 Option 1 – Do nothing

5.1.1 Advantages
5.1.2 Disadvantages
5.2 Option 2
5.2.1 Advantages
5.2.2 Disadvantages
5.3 Option 3
5.3.1 Advantages
5.3.2 Disadvantages
5.4 Option 4

5.4.1 Advantages
5.4.2 Disadvantages

Page 64 of 94
Evaluation Matrix
Specific evaluation criteria should be developed to cover functional, technical and economic
aspects of each alternative solution, in relation to the specific objectives of the project, as
they relate to meeting the business need.
Recommendation

After applying the evaluation criteria to each alternative, a recommendation should be made
and substantiated for the alternative that offers the best functional, technical, economic and
timely solution.

Section 6 – Proposed System Description

Begin with a narrative description of the proposed process re-design, or new system,
supported by high-level flow charts. If applicable, the proposed system should be compared
with any current system that it seeks to replace.
Technology Requirements

A description of any specific technical infrastructure or software needs, or assumptions,

including dependencies.
System Interfaces

Identification of any interfaces, whether manual or automated, with any other existing or
proposed systems.
Organisational Impact

Identification of any existing policies that may be impacted or changes that may affect
organisational structures and/or functional area‟s responsibilities.
Performance Objectives

This section should refer to the performance requirements previously described at Section 8
and describe how they will be measured. This information will also form the basis of the
Service Level Agreement to be put in place upon implementation of the system.

Section 7 – Economic Justification

Cost/Benefit analysis (CBA) and budgeted cash flow analysis

Refer Appendices K, L and M.

This section of the business case describes the costs associated with implementing the
recommended solution:
Implementation costs

List all “once-off” costs associated with training, systems development (if applicable),
form design, stationery costs (including cost of stationery on hand that will be
discarded consequent upon implementation of the new system), lost productivity,

Page 65 of 94
 change management, capital equipment ( both new, and “sunk cost” of any capital
equipment displaced if not fully depreciated), premises, consultancy or contract
support, etc.

Recurring costs
Describe and quantify any and all costs that will recur year after year to maintain the
recommended solution over the projected life of the new system.
Benefits
This section describes the quantitative benefits associated with the recommended
solution. It is important that the benefits link back to the situational assessment and
the key business drivers that led to the project being initiated.

Operational savings
This section describes all cost savings, or costs avoided, associated with the
realisation of the proposed project‟s objectives.

Section 8 – Implementation timeline

Describe the high level project timeline with key milestones and project checkpoints. The
project timeline should reflect key steps in the approach and include major decision making
milestones.

Section 9 – Project structure

Describe the resulting sub-projects that stem from the overall solution. Sub-projects may be
separated by process, systems and tools, organisational changes, training needs or other
drivers.
At this stage, the project structure does not address individual staff names, but specifies the
skills required and the number of such skilled resources estimated to be needed. If the project
resource requirements cannot be met within current staffing, ensure that any and all estimated
incremental staff costs, including back-filling if staff are to be seconded to the project, are
taken into the economic justification section.
This section provides the framework for more detailed specifications in the project plan and
also some information on resource requirements for those to be involved in the
implementation:

Section 10 – Critical Assumptions and Risk Assessment

This section provides information about any assumptions or constraints that are critical to the
successful development, implementation and operation of the proposed system and assesses
any risks that can be foreseen as possible with the project‟s progress and implementation:
Refer to Appendix J for some typical project risks, but ensure that adequate specific thought is
given to particular risks to the particular project being initiated.
Functional Risk

The impact of, or on, any pending or proposed system, skills and resources required in

Page 66 of 94
 faculties, schools, ITCS, application development teams, training resources and
dependencies on external suppliers.
Technical Risk

Level of experience, degree of complexity, magnitude of effort, time constraints for

implementation.
Economic Risk

Possibility and consequence of not achieving expected benefits, ease of measurement of

those benefits, quality of estimating assumptions, and availability of ongoing funding.
Security, Privacy and Audit Considerations

Security aspects required, privacy and confidentiality of information being processed, audit
requirements of the proposed system.

Business Continuity Measures

High-level descriptions of alternatives available to continue to meet the mandatory

functionality of the proposed system in the event that any supporting resource becomes
unavailable. These measures should be addressed in terms of the Standards Association of
Australia‟s Business Continuity Management Guideline.

Section 11 – Conclusions and Recommendations

State the conclusions the reader should draw from the business case, and recommendations
for the next steps. Iterate key themes from each major section of the case as part of the
executive summary and closing.

Section 12 - References & Related Documents

Document Date

Page 67 of 94
27 APPENDIX H – Project Status Report format
Distribution (position titles)

ACTIVITIES DURING THIS PERIOD

PROPOSED WORK FOR NEXT MONTH

Matters Requiring Action Action required by Action required by Status at

(date) (person) date

Progress against Budget – Month to nn/nn 200x

Original Budget Cost to date Revised Budget Budget
remaining
$ $ $ $

CONTRACT RESOURCE # DAYS DAILY RATE COST

Progress against Project milestones

Task Scheduled Revised Actual
completion completion completion
date date date

Project completion

Page 68 of 94
ISSUE LOG
Participant Priority Issue Status / Actions By Whom By When
*

*Priority categories:
RED AMBER GREEN
Significant/potential problems – needs Not critical yet – raised for

Roadblock, potential to stop/severely hinder
progress addressing now awareness, to ensure covered

RESOURCE CONSTRAINTS
Resource Absence Reason for absence Project Impact Remedial Action

Page 69 of 94
28 APPENDIX I - Issue Log format
Scheduled Actual
7 Assigned 9
Issue No Sub-project element Summary description of issue Priority 8 Status completion completion
To
date date

7
Mandatory, Essential, Desirable or Nice to Have (N2H)
8
Member of project team
9
Open, Active, Deferred, Closed

Page 70 of 94
29 APPENDIX J – Risk Management Schedule
Risk
Functional specifications
not clearly stated
Project management
structure not defined and
agreed
Insufficient resources
assigned to make timely
implementation possible
Vendor consultants do not
have adequate experience
to add necessary value to
the project
Backfilling of key business
users is not planned for
10
L = Likelihood
11
C= Consequence
10 11
L C Impact Mitigation strategy
No specific success Clearly document functionality to
criteria; disparate be delivered. Ensure that the
expectations among functional specification is signed
user base resulting in off by every key stakeholder.
dissatisfaction upon Document specific success
implementation. criteria and have them signed off,
Quality assurance particularly by the project
reviews will return sponsor.
unfavourable reports. Ensure that not quality assurance
review delivers any surprises, be
sure to communicate the
acceptance criteria for each
deliverable, as well as the project
overall. Be very alert to any
attempt to modify the scope of the
original functional specification;
maintain the change log
scrupulously.
Confusion in the project Define the project management
as to roles and structure in the project charter.
responsibilities, leading This must cover the various roles
to a potential lack of within the management structure
decision making. and their level of responsibility.
The project MUST have a
nominated Project Sponsor who is
the ultimate decision making
authority. The project should also
have a steering committee
comprised of the key
stakeholders.
Project can not be Develop the project plan as part
implemented on the of the project charter. Identify as
agreed date many of the significant tasks of
the project as possible and
estimate the resources required.
Will impact the Negotiate ability to reject any
implementation date and proposed candidate on the basis
potentially could have of their experience or
serious ramifications if performance on the project.
inappropriate
configuration settings
are defined
Conflicting priorities for Develop a detailed project plan as
the project team part of the project charter and
resources will impact the identify any resource constraints.
delivery date. Ensure that a strategy to support
the project team members is in
place.
Page 71 of 94

Risk
To many part time
resources on the project
Key business stakeholders
not identified
Critical path through the
project needs to be
identified and maintained
Decision making process is
not clear
Technology infrastructure is
not available to support a
particular phase of the
project.
Lack of facilities to support
the project team
Documentation not
managed in any structured
fashion
A third party package is
implemented without the
support of business groups
10 11
L C Impact
Tasks can not be
completed in time due to
conflicting priorities
The project will have
negligible support from
the end-users, causing
difficulties in operational
running
Without a critical path
identified the project
team members may be
working on less critical
tasks without being
aware of the impact.
Critical decisions are not
resolved in a timely
manner and impact the
implementation date
Delays to the project
that could impact the
implementation date
Project is delayed at the
start.
Difficult for the project
team to access
information easily
There is little user
acceptance of the
package and difficulties
in operational running.
Page 72 of 94
Mitigation strategy
Try to avoid any and all part time
assignments to the project team.
Ensure that the key business
users are identified and endorse
the project charter.
The project plan must identify the
critical path and ensure that this is
maintained through the life of the
project.
Develop and maintain an issues
register. The register forms part
of the overall management
structure and options for
outstanding issues will be brought
before the steering committee
meetings for resolution.
Ensure that all required elements
of the infrastructure environment
are acquired/established early in
the project and that the production
environment is available for
acceptance testing of the design.
Environments for development,
testing, training and production
need to be set up early in the
project and procedures
implemented that ensure that all
of the environments are robust.
Ensure that accommodation and
support services, including
telephones and desktop
computers, are available for the
project team. .
Set up a documentation directory
structure that provides for simple
shared access. Ensure that a
defined nomenclature is used to
categorise documents.
Establish a reference group as
one element of a communication
strategy that will enable the
affected functional units to be
informed of the progress of the
project.

Risk
Customisations are
required in the package to
perform critical business
requirements
Substantial new reporting is
identified to support current
business processing
Lack of available skilled
business resources in the
project‟s initiation and
design.
Substantial business
process re-engineering is
adopted without reference
to the impact within the
business environment
Design is overly complex
10 11
L C Impact Mitigation strategy
Implementation is Use the application design phase
delayed or significant of the project to identify any
business workarounds significant business issues. Work
have to be implemented. closely with the business to look
for alternatives to the proposed
customisations. Try to find ways
of configuring the system to give
the desired results.
Project is unable to Work with the business users to
deliver the required determine how on-line queries
reporting by the and standard reports can be used
implementation date and in conjunction to run the business.
the cost of report Evaluate the implementation of
development has an changed business practices to
adverse effect on the also reduce the reliance on
project budget „existing‟ business reports. Resist
the compulsion to develop more
reports for day 1 processing and
request the user base to evaluate
existing enquires and reporting
before requesting additional
functions. Be mindful that some
existing reports will be used
heavily by the business and it will
require business expertise to
design new business
management techniques in the
new package environment
The quality of the design Ensure that the business is
suffers. Existing committed to the project through
business practices are the charter process and that the
not well understood and project is a key priority of the
the capacity to identified business resources
implement changed
practices not explored.
When the application Get stakeholders commitment to
goes into production the BPR processes. Implement, if
there is significant user possible, parts of the revised
resistance to the business process prior to the
package. implementation of the package.
Ensure that key business users
(and champions of the application
within the business) are part of
the user acceptance team.
Identify issues early.
Issues are hard to Make business processes as
uncover and end-to-end easy to understand as possible. If
testing is complex there are complex workflows to
putting pressure on implement then consider the
achieving the potential of implementing these in
implementation date. phase 2 of the project.
Page 73 of 94

Risk
Design does not reflect
business requirements
Project team spends
excessive time on non
critical business processes
Business process design
changes the dynamics of
data capture and
processing
Pre-printed stationery not
available in time for “go-
live”
Design does not pay
sufficient attention to the
complete business process
but concentrates primarily
on the application aspects
Size of the task is
underestimated
Quality of the data is poor
Volume of data
10 11
L C Impact Mitigation strategy
Implementation does not Ensure that the application design
support required process produces a design that is
business processing understandable by the business
and alternative systems users. It also needs to be signed
and procedures are of by the key business
necessary to support the stakeholders
business.
Some key business Prioritise the functionality to be
processes are not provided in the application.
supported at Identify those „must have‟ items
implementation time and ensure the project plan
causing problems delivers those for the
implementation date.
Some business areas Identify issues of concern and
will not feel that they raise these through the Faculty
have adequate reference group.
resources to support the
change in business
practice
Unable to produce Agree on all output formats in the
anything requiring pre- design process; wherever
printed stationery possible, include stationery
formats in actual documents
produced by the system.
Although the business Ensure that a walkthrough of the
process works in theory end-to-end business process is
it breaks down when it is undertaken with the specialist
tested in the field staff. Map data capture from
input to output as part of
functional design.
Potential to delay the Identify all data sources required
implementation date if to support the new environment.
key data can not be In the case of multiple data
transferred in time. sources estimate the degree of
data cleansing and consolidation
required. Ensure that the data
migration tasks are started as
soon as possible in the project
plan.
More data cleansing and Identify data quality issues as
decision making is soon as possible after the
required to ensure commencement of the project
project timelines are met
May impact the ability to Data loading may have to
achieve the consider a phased approach. Key
implementation date data to support daily business
transactions first followed by
historical data.
Page 74 of 94

Risk
Reliability of the
development environment
is poor
Poor management control
of the various application
environments
Vendor experiences
package problems
Not all interfaces are
identified
Testing of interfaces can be
difficult and time consuming
10 11
L C Impact Mitigation strategy
Delays the project. Set up the development
Frustrates the project environment as soon as possible
team. The loss of an after project commencement.
environment due to Ensure that a backup strategy is
hardware or software in place that allows the project
corruption could have a team to return to a prior
significant impact on the development without substantial
project. outage time. Put in place the
procedures to request a special
backup to enable the capturing of
an environment post a significant
event (for example a data load).
Loss of progress due to Implement a set of processes to
having to recover deal with the development and
previous environments migration of functionality from the
development to test and then
production.
If the problems are Develop and maintain an issue
severe it may impact the log.
implementation date.
The more problems that
are identified in testing,
the longer the
implementation phase
will be,
Functionality will be Make sure that all of the business
impaired and systems to areas are aware of the fact that
which interfaces are the existing systems will cease to
required (in or out) will operate from the implementation
cease to provide correct date. Depending on the degree of
results. difficulty, change all output reports
from the HR system and Finance
system to say „will not be
available from 99 XXX 99‟ to alert
people that the reports will not be
produced. Request that all
system owners which feed the HR
or Finance system provide details
of the existing interface. Develop
an interface map to depict all
known interfaces.
Potential data errors will Ensure there is adequate support
occur due to the after implementation to deal with
particular condition errors that arise out of the system
having not been tested interfaces. Encourage as much
in the acceptance end to end and variance testing in
testing phase. the user acceptance testing
period as possible. End to end
testing of bank tapes etc could
involve a number of test runs.
Page 75 of 94

Risk
Insufficient training
provided to project team
and/or users
Key business users not
made available for testing
Not enough business
cycles or end-to-end testing
is performed
Acceptance testing is
performed with user profiles
that have global privileges
Transaction response times
do not meet objectives
Organisation does not
handle the change process
well
10 11
L C Impact Mitigation strategy
Project team and users Develop an appropriate training
ineffective in using the strategy that covers the project
application and may team and their requirement to be
develop a negative trained in the packages
attitude functionality. User training needs
to consider a train the trainer
approach or direct training of the
end user in key business
functionality. As part of the
marketing and training approach
identify process champions within
the business areas.
Application is Ensure that acceptance testing is
implemented but key on the plan with business users
business problems have identified. Resist the pressure to
not been identified. limit the amount of user
acceptance testing due to
unavailability of resources or lack
of time.
Although application Estimate a realistic amount of
performs most functions time to the user acceptance
correctly the integrity testing. Develop a testing
and accuracy of data strategy in the design phase of
has not been sufficiently the project to ensure that as many
verified aspects of the design are verified.
Ensure that the development of
the testing strategy as well as the
testing is included in the project
plan. The testing strategy must
contain the tests to be conducted
with the expected results.
Problems can arise at Acceptance testing must be
package implementation conducted in an environment that
occurs. mirrors the expected production
environment. The user
acceptance environment should
be able to become the production
environment once the final data
migration is undertaken.
Users unable to use the Monitor the situation, particularly
system as they through the user acceptance
expected to. phase. Identify the need for
infrastructure upgrades. Ensure
volume testing is targeted at
maximum throughput times.
Perception within the Ensure that appropriate training is
user base that they have provided throughout the
received little benefit implementation phase of the
from the introduction of product. Provide regular reporting
the application. to the University user base on the
process being undertaken.
Page 76 of 94

Risk
Limited skills transfer has
occurred to end-user staff
Production environment is
not stable
Capacity is exceeded soon
after production
Project budget is
underestimated
Excessive overtime worked
by project team
Lack of teamwork within the
project team, both core and
extended
10 11
L C Impact Mitigation strategy
Providing a consistent Ensure that staff who need to be
service is difficult and trained, in what, and when. Do
requires the on-going not effect training too early,
support of external staff certainly not “just in time” and do
or project team not train all users in all aspects of
members. the system, only what they will
need to know.
Users lose confidence in Implement redundancy features
the new application within the hardware and software
to support a high availability
environment
User performance Elicit a variety of sources
suffers and ability to (software vendor, hardware
process business vendor and independent) to
transaction load may be provide estimate hardware
questioned configuration to support expected
volumes.
More funding is required Closely monitor the usage of
or functionality reduced external resources and provide
regular Project Status Reports to
the Steering committee.
Morale will suffer and Ensure each member of the
the quality of work will project team has the skills
deteriorate appropriate to perform their
assigned role, and that there are
sufficient staff to meet the
scheduled delivery dates, or that
the scheduled delivery dates are
feasible within the available
resources. Ensure that
uncontrolled scope creep is not
causing the overtime.
Morale will suffer and As above. Also, do not assume
the quality of work will that all team members accept the
deteriorate. A crisis project‟s objectives and
mentality will hang over understand their role in delivering
the team most of the those objectives. Interpret project
time and information will goals into clear individual goals
not be shared readily for each team member so that
between team they know what is expected of
members. them and how their performance
Dysfunctional groups will be evaluated. Wherever
and cliques will form. possible, align each team
member‟s role within the project
with their own personal
professional goals. Ensure that
all key participants have timely
access to project information,
including status reports, change
log, issue log, etc. Informal
communications are also very
important.
Page 77 of 94
 10 11
Risk L C Impact Mitigation strategy
Failure to reach agreement The project deliverables Do not allow personal issues to
between the project will never meet the cloud the project‟s objectives.
manager and the project mercurial expectations Ensure that the process owner is
sponsor. of the project sponsor. kept informed.
Versions of the detailed
plan will change
dramatically and the
project team will lose
focus.

Page 78 of 94
30 APPENDIX K – Communication Plan Template

Communications Plan
Project Details
Project Name:
Date:
Project Owner:
Prepared by:

Principal Staff
Name Role Position @ ACU Contact
Details

Document Version Control

Version Date Details Written by Authorized
By

Page 79 of 94
 TABLE OF CONTENTS

1. Communications Plan Executive Summary ................................................................ 1

2. Marketing and Communication Strategies .................................................................. 1
3 Stakeholder Communications……………………………………………………………….2
4. Training Strategies ..................................................................................................... 2

Page 80 of 94
1. Communications Plan Executive Summary

2. Marketing and Communication Strategies

a. Communicating Major Risks, Issues and Changes

Page 81 of 94
3. Stakeholder Communication

Stakeholders Method Message Timing Frequency Communicator

4. Training Strategies

Stakeholders Training Required Format Timing Frequency Trainer

Stakeholder1

Stakeholder2

Stakeholder3

Page 82 of 94
31 APPENDIX L – Internal Rate of Return (IRR)

The following extract from a Computerworld article is a good summary of IRR; searching the internet
for “internal rate of return” will assist you to fully understand the method as there are many
examples of how to calculate it:
The internal rate of return (IRR) is the discount rate that results in a net present value of zero for a
series of future cash flows. Avoid a project if the IRR is less than the cost of capital or minimum
desired rate of return.
IRR provides a simple hurdle rate for investment decision-making, but IRR is not as easy to
understand as some measures and not as easy to compute.

IRR is the flip side of net present value (NPV) and is based on the same principles and the same
math. NPV shows the value of a stream of future cash flows discounted back to the present by
some percentage that represents the minimum desired rate of return, often your organisation‟s cost
of capital.

IRR, on the other hand, computes a break-even rate of return. It shows the discount rate below
which an investment results in a positive NPV (and should be made) and above which an
investment results in a negative NPV (and should be avoided). It's the break-even discount rate, the
rate at which the value of cash outflows equals the value of cash inflows.

Consider the three scenarios shown below (see table), each involving an initial investment of $1
million. The investment returns $300,000 (undiscounted) per year in each of the five years after the
initial investment, for a net return of $500,000.

A company evaluating this investment using cash flow discounted at 10% would compute an NPV of
$137,000, a decent but not spectacular result. But if the company evaluates the same investment at
15%, the project has a present value of only $6,000, essentially just breaking even, and at 20% the
project's present value is negative. The IRR is a fraction of a percentage point above 15%; at that
discount percentage, the investment's NPV is zero.

IRR is often used as a hurdle rate, a sort of go/no-go investment threshold.

Like NPV, IRR doesn't measure the absolute size of the investment or its return. And because of the
way the math works, the timing of periods of negative cash flow can affect the value of IRR without
accurately reflecting the underlying performance of the investment.

IRR can also produce misleading results because, as classically defined, it assumes that the cash
returned from an investment is reinvested at the same percentage rate, which may not be realistic.

Page 83 of 94
Internal Rate of Return: What It Looks Like12
Discount rate: 10% Discount rate: 15% Discount rate: 20%

Year Cash flow Factor Amount Factor Amount Factor Amount

0 -$1 million 1.000 -$1 million 1.000 -$1 million 1.000 -$1 million
1 +$300,000 0.909 $273,000 0.870 $261,000 0.833 $250,000
2 +$300,000 0.826 $248,000 0.756 $227,000 0.694 $208,000
3 +$300,000 0.751 $225,000 0.658 $197,000 0.579 $174,000
4 +$300,000 0.683 $205,000 0.572 $172,000 0.482 $145,000
5 +$300,000 0.621 $186,000 0.497 $149,000 0.402 $121,000
Total +$500,000 NPV = +$137,000 NPV = +$6,000 NPV = -$102,000

IRR = slightly more than 15%

IRR is often used as a hurdle rate, a sort of go/no-go investment threshold. In this example,
there is an initial investment of $1 million, with a net (undiscounted) return of $500,000. The NPV of
the $1 million outlay depends on the discount rate, or cost of capital, used to evaluate the
investment. The NPV is zero at the IRR, here a fraction of a percentage point above 15%.

12
Source: Computerworld

Page 84 of 94
32 APPENDIX M – Net Present Value (NPV)13
The net present value (NPV) of an investment is the present (discounted) value of future cash
inflows minus the present value of the investment and any associated future cash outflows. It's the
net result of a multiyear investment expressed in today's dollars.
By considering the time value of money, NPV allows consideration of such things as cost of capital,
interest rates and investment opportunity costs. It's especially appropriate for long-term projects.

But, ranking investments by NPV doesn't compare absolute levels of investment. NPV looks at cash
flows, not at profits and losses the way accounting systems do. NPV is highly sensitive to the
discount percentage, and that can be tricky to determine.

Unlike the more widely used payback period expressed in current values, NPV accounts for the time
value of money by expressing future cash flows in terms of their value today. It recognises that
money has a cost (interest), so that you would prefer to have $1.00 today to having $1.00 a year
from now. If you earn 10% interest on your money, $1.00 today will be worth $1.10 a year from now.
Or, turning that around, the "present" value of $1.10 one year out is $1.00.

Calculating NPV requires use of a discount rate equal to some minimum desired rate of return. This
could be your company's average weighted cost of capital (debt and equity) as computed by your
finance department. If capital costs your company 10%, you aren't likely to invest that capital for an
8% return.

The discount rate (say, 10%) determines the discount factor for each year (say, .909) that is applied
to that year's cash flow to convert it to today's dollars. The discount factor for year n can be
computed as: discount factor = 1/(1+i)n, where i is the target rate of return. So at a discount rate of
10% in Year 1, discount factor = 1/(1.1), or .909. Thus, in the earlier example, the present value of
$1.10 a year from now is $1.10 x .909, or $1.00. Fortunately, this math is automated in spreadsheet
packages. You enter only the undiscounted cash flows, the years in which the flows are expected
and some target interest rate. NPV will be calculated by, say, Excel.

The chart below compares two projects that a bank could undertake. Each has an initial investment
of $1 million and a minimum desired rate of return of 10%. On the basis of absolute (undiscounted)
return, the ATM installation is better because it generates $250,000 more cash over the life of the
investment. But when the time value of money is considered, the server consolidation project looks
slightly better, with an NPV higher by $9,000. Its present value is higher because the returns occur
earlier in the project's life.

The yearly cash flows from a hotel or entertainment project are net revenues, but for an IT&T
project, they generally are cost savings. NPV isn't appropriate for an IT&T project that can't be
associated with clearly defined cash flows.

NPV is a good "no-go indicator," because you'd normally reject an investment with a negative NPV
without further consideration. Those with a positive NPV should then be further measured by other
yardsticks.

13
Source = Computerworld

Page 85 of 94
Net Present Value: What It Looks Like14
ATM installation Server consolidation

Discount factor Present value of Present value of

Year Cash flow Cash flow
(at 10%) cash flow cash flow
0 1.000 -$1 million -$1 million -$1 million -$1 million
1 0.909 +$500,000 +$454,500 +$1 million +$909,000
2 0.826 +$500,000 +$413,000 +$750,000 +$619,500
3 0.751 +$500,000 +$375,500 +$500,000 +$375,500

4 0.683 +$500,000 +$341,500

5 0.621 +$500,000 +$310,500

+$1.5 +$1.25
Total +$895,000 +$904,000
million million
NPV considers the time value of money. In this example, we compare two $1 million projects with a
minimum desired rate of return of 10%. On the basis of simple cash flow, the ATM installation looks
better because it generates $250,000 more over the life of the investment. But when the time value of
money is considered, the server consolidation project looks slightly better, with an NPV higher by
$9,000, because the returns occur earlier in the project‟s life.

14
Source Computerworld

Page 86 of 94
33 APPENDIX N – Return on Investment (ROI)

The following elaboration of ROI, and example calculation, relates to a proposal for eLearning
(electronic learning). However, the methods are identical for all proposals, whether technology is
involved or not.

21.1 Introduction
Building a business case that is centred around a quantifiable, reliable, and compelling estimate of
the Return on Investment (ROI), is an essential element of any value proposition. The key to
producing a credible ROI lies in ascertaining the cost and income impact. This article provides
guidelines for quantifying the hard (quantifiable) benefits and soft (qualitative) benefits that are
important in developing a complete picture of the total return on investment.

In this example, the eLearning solution is expected to deliver a minimum ROI of 400% in the first
twelve months versus traditional education and training approaches, when the full business impact
is measured. Any ROI analysis should include the following four categories of potential benefits:
 Quantitative cost savings vs. alternative solutions
 Quantitative revenue/income impacts vs. alternative solutions
 Qualitative benefits vs. alternatives
 Qualitative benefits vs. alternatives
This paper defines these benefit categories and provides a primer on the mathematics of the ROI
calculation.

21.2 Quantitative (“hard”) Cost Savings

Quantitative cost savings can always be expressed in financial value terms and can be easily
estimated or measured. When calculating the total quantifiable cost savings, consider the following
factors:
 Travel Traditional instructor-led training (ILT) requires personnel to travel to one central
location. The hard travel savings are easy to calculate. Take the sum of airfare, hotel, meals,
car rental, etc. and multiply by the headcount number. In many cases, this alone yields a
400% ROI.
 Facilities (cost of renting premises to conduct training, electricity, overhead projector
purchase and/or depreciation, floor space cost, etc.)
 Instructor fees
 Printing, distribution and storage costs
 Repeated training for new staff, refresher courses, content updates, etc.
 Reduction of customer support costs (the average staff cost per minute for support calls,
telephone handset costs avoided, telephone call charges, PABX capacity needs, etc.).

Page 87 of 94
21.3 Quantitative (“hard”) Income/Revenue Impact
Quantitative revenue impact is the total revenue dollar value of the solution that can be estimated or
measured. When rolling up hard revenue impact, consider the following factors:

 Increased productivity

o More income-producing days per instructor or other customer facing personnel, such
as support staff.

 Shorter time to course deployment

o Reducing the time taken to develop and deliver a course expands the duration of its
availability; this may lead to increased revenue through being able to deliver the
course to more students over the longer delivery period.

 Increased revenue opportunities

o Delivering fee-based training and/or certification to students, and the ability to deliver
more revenue-generating courses to more students
21.4 Qualitative (“soft”) Benefits

Qualitative benefits are difficult and sometimes impossible to quantify and measure. Most usually,
qualitative benefits should not be the prime reason for proceeding with a project proposal. Often,
they will be the weighting consideration in an otherwise marginal business case. Sometime, they
can be as compelling as quantitative cost savings and strong positive revenue impact. Typically, the
business case for any investment starts with ROI calculations based on the quantitative cost
savings and income impact. The qualitative benefits are then layered on top of the business case to
provide a more complete view of the total return. When developing qualitative benefits, consider the
following values:
 Immediacy
o Since education is treated as an ongoing process and not an event, knowledge
transfer is always only a web browser away.
 Consistency
o Automated, technology-based approaches to large-scale knowledge transfer are
inherently more consistent in their delivery than human interaction, which can vary
from trainer to trainer and instance to instance.
 Certification
o Web-based eLearning is a cost-effective medium for certifying knowledge on a large
scale.
 Closed loop
o Course improvement with each iteration
 Lecturers developing courses and adding value elsewhere, not teaching classes

Page 88 of 94
  Increased morale gained from simultaneous training

o "We're no longer last on the up here in Malaysia."

 Individual Values

o Individual values are benefits that are experienced at the individual learner level.
They represent an additional category of soft benefits that should not be ignored in
understanding the complete business impact of an eLearning solution. Individual
values include:

 Timeliness of learning, etc.

21.5 Calculation of Return on Investment (ROI)
Three data points are required:

o The time period over which the ROI is to be calculated (typically one year).

o The investment. All costs directly attributable to the proposed solution and allocation of
appropriate percentages of indirect costs.

o The return. This is the total of the cost savings and revenue enhancements known, or
reasonably estimated, to be gained from the proposed solution.

There are three ways to calculate the ROI:

1. As a percentage.

If you gain benefits equal to $1,000,000 in 12 months on a total investment of $250,000 in the
same time period, the ROI can be calculated as follows:

Return = Payback - Investment

ROI = [(Payback - Investment)/Investment)]*100,

in this example:

[($1,000,000-$250,000)]/$250,000*100 = 300%

2. As a ratio

Divide the return by the investment.

$1,000,000/$250,000 = 4:1

3. As a time to break-even

Determine the number of days, weeks, or months it will take to break even on the investment.

Time period to break-even = (Investment/Return)*Time Period

($250,000/$1,000,000)*12 months = (0.25)*12 = 3 months or 90 days

Page 89 of 94
21.6 Conclusion

ROI analysis needs to be used in context of a broader evaluation framework because it is just one
of several financial measurement tools that can be used to support an investment decision. You
may want to complement your ROI financial measures with other methods that address the key
limitations of ROI metrics. For example, ROI does not factor in risk and does a poor job accounting
for intangible rewards.

ROI is particularly effective at:

 Facilitating investment prioritisation by making hard number comparisons between
investment options, allowing decision-makers to focus on the intangible benefits separately.

 Setting investment screening thresholds (e.g., consider only projects that deliver an ROI of
at least 200%).

 Imposing some discipline on the part of vendors and decision-makers to support business
impact claims by taking a more methodical and quantifiable approach to business
justification.

 Enforcing an understanding of the top/bottom line business impact of the investment since it
is impossible to complete an ROI analysis without understanding the potential impact on cost
and revenue generation.

Page 90 of 94
34 APPENDIX O – Weekly Project Review Meeting Minutes - Format
Meeting Date
Purpose of Meeting Review the Acme Project Plan
Participants

OUTSTANDING ACTION ITEMS

Meeting Item Assigned to Description Status Scheduled Actual
# completion Completion
(Date) (initials) date Date
250999 14 AA To develop a training navigation document Open 14/11/99
template
071099 24 (b) CC What are the environmental problems consequent Open 29/11/99
EE upon the installation and configuration of the
Acme environments and V2.0 of XXX?
FF
Requires DD to participate in this action item.
She cannot until she completes installation of
Project Y
071099 24 DD What caused problems? How can ZZZ prevent Open 29/11/99
CC recurrences?
(c)
FF DD unable to prepare detailed report until she
completes installation of Project Y.
071099 24 GG Ensure that installation and configuration process Open
HH/ is documented fully, so that it becomes a
(d)
repeatable and easily manageable procedure.
DD
DD cannot participate in this documentation until
CC she completes installation of Project Y. 29/11/99
FF
CLOSED ACTION ITEMS
Meeting Item Assigned to Description Status Scheduled Actual
# completion Completion
(Date) (initials) date Date
230999 1 CC Review supplier issues regularly with relevant Closed 07/10/99 07/10/99
provider and present findings at weekly meeting
250999 2 CC Follow-up the status on screen format. Closed 07/10/99 07/10/99
071099 3 EE Build product releases and upgrades into schedule Closed 24/09/99 24/09/99
230999 4 BB Follow-up with supplier re keeping the old Closed 01/10/99 01/10/99
environment. BB to discuss with third party
provider
230999 5 KK Identify whether test system needs to be a refresh Closed 30/09/99 30/09/99
from backup or a full release.

NEW BUSINESS

 Item 1

 Item 2

 Item 3

Page 91 of 94
35 APPENDIX P – TESTING INFORMATION TECHNOLOGY
APPLICATIONS

Terminology15

In IT&T projects, a test is an activity in which a system or component is executed under specified
conditions, the results are observed or recorded and an evaluation is made of some aspect of the
system or component. The term “testability” is used to describe:

 The degree to which a system or component facilitates the establishment of test criteria and the
performance of tests to determine whether those criteria have been met,
 The degree to which a requirement is stated in terms that enable establishment of test criteria
and performance tests to determine whether those criteria have been met (see measurable).

Testing terms and their meanings are contained in the following table:

TERM MEANING
Black-box testing See functional testing.
Boundary value A test data selection technique in which values are chosen to lie along
analysis data extremes. Boundary values include maximum, minimum, just
inside/outside boundaries, typical values, and error values. The hope is
that, if a systems works correctly for these special values then it will work
correctly for all values in between.

Cause effect A testing technique that aids in selecting, in a systematic way, a high-yield
graphing set of test cases that logically relates causes to effects to produce test
cases. It has a beneficial side effect in pointing out incompleteness and
ambiguities in specifications.

Closed-box testing See functional testing

Equivalence class A software testing technique that involves identifying a small set of
partitioning representative input values that invoke as many different input conditions
as possible.

Error based testing Testing where information about programming style, error-prone language
constructs, and other programming knowledge is applied to select test
data capable of detecting faults, either a specified class of faults or all
possible faults.

Failure directed Software testing based on the knowledge of the types of errors made in
testing the past that are likely for the system under test. Synonymous with
"heuristics testing"

Functional testing The application of test data derived from the specified functional
requirements without regard to the final program structure. Synonymous
with "black-box testing" and "closed-box testing"

15
Source = IEEE (Institute of Electrical and Electronics Engineers)

Page 92 of 94
Heuristics testing See failure directed testing.

Test case Documentation that specifies inputs, predicted results, and a set of
execution conditions for a test item. Synonymous with test case
specification. See also test procedure.

Test case generator A software tool that accepts as input source code, test criteria,
specifications, or data structure definitions and uses those inputs to
generate test input data and, sometimes, determines expected results.
Synonymous with test data generator and test generator.

Test design Documentation that specifies the details of the test approach for a software
feature or combination of software features and identifies the associated
tests. Refer also:
 Boundary value analysis
 Cause effect graphing
 Equivalence class partitioning
 Error based testing
 Functional testing

Test documentation Documentation that describes plans for, or results of, the testing of a
system or component. Types include test case specification, test incident
report, test log, test plan, test procedure and test report.

Test driver A software module used to invoke a module under test and, often, provide
test inputs, control and monitor executive, and report test results.
Synonymous with test harness.

Test harness See test driver.

Test incident report A document that reports on any event that occurs during testing that
requires further investigation. See also failure directed testing.

Test log A chronological record of all relevant details about the execution of a test.

Test phase The period of time in the software development life cycle (SDLC) in which
the components of software (developed or purchased) are evaluated and
integrated, and the software is evaluated to determine whether or not
requirements (functional specifications) have been satisfied.

Test plan Documentation that specifies the scope, approach, resources and
schedule of intended testing activities. A test plan identifies test items, the
features to be tested, the testing tasks, responsibilities, required
resources, and any risks requiring contingency planning. See also test
design and validation protocol.

Validation protocol Validation Protocol provides the test scripts and specific guidelines to
prove the effective functional use of the software. See test plan.

Page 93 of 94
BIBLIOGRAPHY

The Office of Government Commerce, United Kingdom http://www.ogc.gov.uk/sdtoolkit

Computer World periodical publications
The Data Base Design and Evaluation Workbench [DDEW] Project at CCA." Database Engineering
7(4):10-15, 1985”
Intelligent Enterprise periodical publications
U.S. Department of Transportation - Volpe Center Logical Data Modelling
Infrared Space Observatory http://www.iso.vilspa.esa.es

Page 94 of 94