Вы находитесь на странице: 1из 230

Faculty of Science and Technology

CBPM4103
IT Project Management

Copyright © Open University Malaysia (OUM)


CBPM4103
IT PROJECT
MANAGEMENT
Dr Nasina Jagesh
Yahaya Abd Rahim
Normi Sham Awang Abu Bakar
Mohd Zahari Awang

Copyright © Open University Malaysia (OUM)


Project Directors: Prof Dato’ Dr Mansor Fadzil
Assoc Prof Dr Norlia T. Goolamally
Open University Malaysia

Module Writers: Dr Nasina Jagesh


Yahaya Abd Rahim
Universiti Teknikal Malaysia Melaka

Normi Sham Awang Abu Bakar


Universiti Islam Antarabangsa

Mohd Zahari Awang

Moderator: Aedah Abd Rahman


Open University Malaysia

Developed by: Centre for Instructional Design and Technology


Open University Malaysia

First Edition, November 2008


Second Edition, December 2011
Third Edition, December 2014 (rs)

Copyright © Open University Malaysia (OUM), December 2014, CBPM4103


All rights reserved. No part of this work may be reproduced in any form or by any means
without the written permission of the President, Open University Malaysia (OUM).

Copyright © Open University Malaysia (OUM)


Table of Contents
Course Guide xi–xvii

Topic 1 Introduction to Project Management 1


1.1 Definition of Project 2
1.2 Definition of Project Management 3
1.3 Types of it Projects 4
1.4 Software Versus Other Projects 5
1.5 Project Managers 6
1.6 Project Stakeholders 8
1.7 Project Proposals 10
1.8 Project Life Cycle 11
1.8.1 Four-Phase Project Life Cycle 12
1.8.2 Five-Phase Project Life Cycle 13
1.8.3 Six-Phase Life Cycle 14
1.8.4 Overlapping Activities in a Project 15
1.9 Project Management Methodology 16
1.10 System Development Life Cycle (SDLC) 19
1.10.1 The Waterfall Model 20
1.10.2 Comparison of SDLC with PLC 21
Summary 23
Key Terms 24
References 24

Topic 2 Project Selection 25


2.1 Project Identification 26
2.2 Project Portfolio 27
2.2.1 Programme Management and Portfolio 27
Management
2.2.2 Problems for Portfolio Managers 29
2.3 Project Selection Models 30
2.3.1 Non-Numeric Selection Models 31
2.3.2 Numeric Selection Models 33
2.4 Cost-Benefit Analysis 35
2.4.1 What is Cost? 35
2.4.2 What is Benefit? 37
2.5 The Payback Method 38
2.6 Net Present Value Method 40
2.7 Internal Rate of Return 41

Copyright © Open University Malaysia (OUM)


iv  TABLE OF CONTENTS

2.8 Feasibility vs. Business Case 43


2.9 Project Risk Evaluation 45
Summary 46
Key Terms 47
References 47

Topic 3 Project Initiation 48


3.1 Project Definition 49
3.2 Roles and Responsibilities 51
3.3 Project Scope and Objectives 53
3.4 Project Scope Checklist 55
3.5 Quality, Priority and Expectations 57
3.6 Identifying Project Tasks 58
3.7 Definition of Success 59
3.8 Project Launching 62
Summary 63
Key Terms 64
References 64

Topic 4 Project Planning 66


4.1 Planning Overview 67
4.2 Rules in Project Planning 68
4.3 Steps in Project Planning 69
4.4 Project Scope and Objectives 70
4.5 Requirements Specification 70
4.6 Project and Activities 72
4.7 Activity Plan 73
4.8 Work Breakdown Structure (WBS) 74
4.8.1 Examples of WBS 76
4.8.2 Uses of WBS 78
4.9 Work Package Estimates 79
4.10 Setting the Milestones 80
4.11 Handling Software Prototypes: The Prototyping Model 82
Summary 83
Key Terms 84
References 85

Topic 5 Software Project Estimates 86


5.1 Software Estimates and Benefits 87
5.1.1 Stages of Estimates 87
5.1.2 Overestimation and Underestimation 88
5.1.3 Software Estimation Process 88
5.1.4 Basis for Software Estimation 90

Copyright © Open University Malaysia (OUM)


TABLE OF CONTENTS  v

5.2 Various Estimation Techniques 91


5.3 Constructive Cost Model (COCOMO) 94
5.3.1 The Basic COCOMO 94
5.3.2 Intermediate COCOMO 95
5.3.3 Advanced COCOMO or COCOMO II 96
5.3.4 Pros and Cons of COCOMO 97
5.4 Function Point Analysis (FPA) 97
5.5 COCOMO Versus FPA 99
5.6 Reconciling COCOMO and FPA 100
Summary 102
Key Terms 103
References 104

Topic 6 Project Risk and Quality 105


6.1 Risk Management Process 106
6.2 Risk Identification and Quantification 109
6.3 Risk Response and Control 111
6.4 Disaster Recovery Planning (DRP) 113
6.5 Project Quality Management 115
6.6 Product Versus Process Quality 118
6.7 ISO Certification 120
6.8 Capability Maturity Model 122
Summary 123
Key Terms 125
References 125

Topic 7 Scheduling, Monitoring and Control 126


7.1 Project Execution 127
7.2 Project Activities and Duration 128
7.3 Scheduling Methods 130
7.4 Gantt Chart 131
7.5 Critical Path Method 132
7.5.1 Analysis of Network 133
7.5.2 Complex Network Notation 134
7.5.3 Network Improvement 136
7.6 Using Other Charts 137
7.7 Earned Value Analysis 139
7.8 Monitoring and Control 141
7.9 Microsoft Project 144
Summary 146
Key Terms 147
References 147

Copyright © Open University Malaysia (OUM)


vi  TABLE OF CONTENTS

Topic 8 Resources, Teams and People 148


8.1 Project Resources 149
8.2 Key Group Players 150
8.2.1 Project Team 150
8.2.2 User Group 150
8.2.3 Steering Committee 151
8.3 Key Individual Players 152
8.3.1 Executive Sponsor 153
8.3.2 Project Manager 153
8.3.3 Team Leaders 154
8.4 Team Members 155
8.4.1 System Analysts 156
8.4.2 Programmers 156
8.4.3 Programmer-Analysts 156
8.4.4 Database Administrator (DBA) 157
8.4.5 Network Specialist 157
8.5 Assignment of Resources 158
8.6 Project Management Structure 159
8.6.1 Management Structure I 159
8.6.2 Management Structure II 161
8.6.3 Management Structure III 163
8.7 Project Team Organisation 163
8.7.1 Pure Project Structure 164
8.7.2 Matrix Structure 165
8.7.3 Centralised Control Structure 166
8.7.4 Decentralised Control Structure 167
8.7.5 Mixed Control Structure 167
8.8 Assessment of Team Organisation 168
8.9 Other Goals and Strategies 169
Summary 171
Key Terms 172
References 172

Topic 9 Suppliers and Contractors 174


9.1 Using Subcontractors 174
9.2 The Process of Contracting 176
9.2.1 Requirement Cycle 177
9.2.2 Requisition Cycle 177
9.2.3 Solicitation Cycle 178
9.2.4 Award Cycle 179
9.2.5 Contract Administration Cycle 179

Copyright © Open University Malaysia (OUM)


TABLE OF CONTENTS  vii

9.3 Requests for Proposals (RFP) 180


9.3.1 Preparing RFP 181
9.3.2 Identifying Vendors 182
9.3.3 Evaluating Proposals 183
9.4 Negotiating the Contract 183
9.5 Terms of Contract 184
9.6 Types of Contracts 186
9.7 Fixed Price Contract 188
9.7.1 Fixed-Price-Incentive-Fee 190
9.7.2 Guaranteed Maximum-Share Savings 190
9.8 Cost-Plus Contract 190
9.9 Time And Material Basis Contract 191
Summary 192
Key Terms 193
References 193

Topic 10 Project Termination 194


10.1 Tracking the Progress 195
10.2 Reasons for Termination 196
10.3 Checklist for Project Closedown 197
10.4 The Final Report 199
10.5 Post-Closing Review 200
10.5.1 Review with the Customer 200
10.5.2 Review with the Project Team 202
10.6 Why Projects Fail 204
10.7 Critical Success Factors 207
Summary 171
Key Terms 172
References 172

Copyright © Open University Malaysia (OUM)


xxvi X COURSE ASSIGNMENT GUIDE

Copyright © Open University Malaysia (OUM)


COURSE GUIDE

Copyright © Open University Malaysia (OUM)


Copyright © Open University Malaysia (OUM)
COURSE GUIDE DESCRIPTION
You must read this Course Guide carefully from the beginning to the end. It tells
you briefly what the course is about and how you can work your way through
the course material. It also suggests the amount of time you are likely to spend in
order to complete the course successfully. Please keep on referring to the Course
Guide as you go through the course material as it will help you to clarify
important study components or points that you might miss or overlook.

INTRODUCTION
CBPM4103 IT Project Management is one of the courses offered by the Faculty of
Science and Technology at Open University Malaysia (OUM). This course is
worth 3 credit hours and should be covered over 8 to 15 weeks.

COURSE AUDIENCE
This course is offered to all students pursuing the Bachelor of Information
Technology programme and the Bachelor of Multimedia and Communication
programme. It aims to expose students to knowledge on how to manage and
plan for IT projects. Project management consists of important elements such as
organising, directing and planning. The course will explore the types of models
that students can use in organising IT projects. The models can also be used not
only for IT projects, but in various other situations or organisations.

As an open and distance learner, you should be able to learn independently and
optimise the learning modes and environment available to you. Before you begin
this course, please ensure that you have the right course materials, understand
the course requirements, as well as know how the course is conducted.

STUDY SCHEDULE
It is standard OUM practice that learners accumulate 40 study hours for every
credit hour. As such, for a three-credit hour course, you are expected to spend
120 study hours. Table 1 gives an estimation of how the 120 study hours could be
accumulated.

Copyright © Open University Malaysia (OUM)


xii  COURSE GUIDE

Table 1: Estimation of Time Accumulation of Study Hours

Study
Study Activities
Hours
Briefly go through the course content and participate in initial 3
discussions
Study the module 60
Attend 3 to 5 tutorial sessions 10
Online Participation 12
Revision 15
Assignment(s), Test(s) and Examination(s) 20
TOTAL STUDY HOURS ACCUMULATED 120

COURSE OUTCOMES
By the end of this course, you should be able to:
1. Analyse the importance of evaluating and selecting projects;
2. Explain non-numeric and numeric selection models;
3. Describe the basic, intermediate and advanced COCOMO;
4. Explain the execution phase of PLC;
5. Discuss the advantages and disadvantages of the various types of contracts;
and
6. Describe a post-project review with the customer and the project team.

COURSE SYNOPSIS
This course is divided into 10 topics. The synopsis for each topic is presented as
follows:

Topic 1 defines project and project management. It provides several examples of


projects in general as well as those of IT. In this topic, you will learn the purpose
of preparing a project proposal and how to prepare a one. Finally, the topic ends
with the project life cycle, the project methodology and the software life-cycle
model.

Copyright © Open University Malaysia (OUM)


COURSE GUIDE  xiii

Topic 2 emphasises that IT projects are capital investments that need some kinds
of cost recovery following their expenses. There are different project selection
models and this topic will discuss the different criteria in making a choice out
of those models. The two important project selection models will be discussed in
greater detail.

Topic 3 is about project initiation which is the first phase of the project life cycle.
It starts with producing a project charter. It includes defining the scope and
objectives of the project together with the preparation of an outline plan. This
topic also has a discussion on the definition of success. The topic finally ends
with project launching which motivates the project team and reminds the
members that the project has officially started.

Topic 4 introduces important steps and issues in planning for an IT project. This
is the second phase of the project life cycle. It describes what constitutes the
scope, objectives and requirement specifications of a project. This topic also
describes the meaning, the design and uses of the work breakdown structure.
Finally, this topic ends with planning to set the milestones, plus an idea on how
to handle software prototypes.

Topic 5 emphasises that software projects are different from other projects. There
are several techniques commonly used to estimate software development effort
more accurately. Towards the end, we will focus in detail on the constructive
cost model (COCOMO) and the Function Point (FP) analyses. Some other tips
will also be covered briefly.

Topic 6 discusses how the process of risk management and project management
includes attention on risks and quality. This topic also includes risk identification
and quantification to ensure nothing significant is overlooked. Towards the end,
this topic covers the disaster recovery plan, project quality management, ISO
certification and capability maturity model.

Topic 7 discusses three major activities in the execution phase of the project life
cycle. The first activity is scheduling to produce a timetable for the plan. The
second major activity is monitoring of project activities, while the third one is to
control the activities. Estimating the value of the work done in a project is called
„Earned Value‰ analysis. Finally, this topic ends with a very brief introduction
to the Microsoft Project as a software tool for project management.

Copyright © Open University Malaysia (OUM)


xiv  COURSE GUIDE

Topic 8 discusses project resources. Project resources can be any item, person, or
team that is needed to run a project. This topic emphasises more on the people
and the team organisation that move the project from beginning until the end.
This topic also discusses the most appropriate ways to organise project teams
based on various situations.

Topic 9 discusses suppliers and contractors in general. This topic discusses


related issues including a detailed coverage on many types of contract that can
take place in IT project situations. Besides that, this topic looks into the process of
developing a request for proposal (RFP) document and the terms of a contract.

Topic 10 covers the final stage of the project life cycle, the termination phase. This
topic discusses what needs to be done in order to terminate and to close the
project. It covers the reasons for terminating the project, and the possible reasons
for project failure.

TEXT ARRANGEMENT GUIDE


Before you go through this module, it is important that you note the text
arrangement. Understanding the text arrangement should help you to organise
your study of this course to be more objective and more effective. Generally, the
text arrangement for each topic is as follows:

Learning Outcomes: This section refers to what you should achieve after you
have completely covered a topic. As you go through each topic, you should
frequently refer to these learning outcomes. By doing this, you can continuously
gauge your understanding of the topic.

Self-Check: This component of the module is inserted at strategic locations


throughout the module. It may be inserted after one sub-section or a few sub-
sections. It usually comes in the form of a question. When you come across this
component, try to reflect on what you have already learnt thus far. By attempting
to answer the question, you should be able to gauge how well you have
understood the sub-section(s). Most of the time, the answers to the questions can
be found directly from the module itself.

Copyright © Open University Malaysia (OUM)


COURSE GUIDE  xv

Activity: Like Self-Check, the Activity component is also placed at various


locations or junctures throughout the module. This component may require you
to solve questions, explore short case studies, or conduct an observation or
research. It may even require you to evaluate a given scenario. When you come
across an Activity, you should try to reflect on what you have gathered from the
module and apply it to real situations. You should, at the same time, engage
yourself in higher order thinking where you might be required to analyse,
synthesise and evaluate instead of only having to recall and define.

Summary: You will find this component at the end of each topic. This component
helps you to recap the whole topic. By going through the summary, you should
be able to gauge your knowledge retention level. Should you find points in the
summary that you do not fully understand, it would be a good idea for you to
revisit the details in the module.

Key Terms: This component can be found at the end of each topic. You should go
through this component to remind yourself of important terms or jargon used
throughout the module. Should you find terms here that you are not able to
explain, you should look for the terms in the module.

References: References is where a list of relevant and useful textbooks, journals,


articles, electronic contents or sources can be found. This list can appear in a few
locations such as in the Course Guide (at References section), at the end of every
topic or at the back of the module. You are encouraged to read and refer to the
suggested sources to elicit the additional information needed as well as to
enhance your overall understanding of the course.

ASSESSMENT METHOD
Please refer to myINSPIRE.

REFERENCES
Bunni, G. N. (2005). The FIDIC forms of contract (3rd ed.). Oxford, England:
Wiley-Blackwell.
Burke, R. (2010). Project management: Planning and control techniques.
Chichester, England: John Wiley.
Cadle, J., & Yeates, D. (2008). Project management for information systems (5th
ed.). Harlow, England: Pearson Prentice Hall.
Carroll, J. (2012). Effective project management in easy steps. Southam, England:
In Easy Steps.

Copyright © Open University Malaysia (OUM)


xvi  COURSE GUIDE

Gatti, S. (2013). Project finance in theory and practice: Designing, structuring, and
financing private and public projects. Waltham, MA: Academic.
Harvard Business Review (HBR). (2012). HBR Guide to project management.
Boston, MA: Harvard Business School.
Headington, R. (2013). Monitoring, assessment, recording, reporting and
accountability: Meeting the standards. London, England: David Fulton.
Hoffer, J. A., George, J. F., & Valacich, J. S. (1999). Modern system analysis and
design. Reading, MA: Addison-Wesley.
Jagesh, N., Rahim, Y. A., Bakar, N. S. A. A., & Awang, M. Z. (2009). CBPM4103 –
Information technology project management. (2nd ed.). Kuala Lumpur:
Open University of Malaysia.
Kendall, G. I., & Rollins, S. C. (2003). Advanced project portfolio management
and the PMO: Multiplying ROI at warp speed. Conyers, GA: J. Ross.
Lewis, J. P. (1993). The project managerÊs desk: A comprehensive guide to project
planning, scheduling, evaluation, control & systems. Chicago, IL: Probus.
Lewis, J. P. (2011). Project planning, scheduling & control: The ultimate hands-on
guide to bringing projects in on time and on budget (5th ed.). New York, NY:
McGraw-Hill.
McLeod, G., & Smith, D. (1996). Managing information technology projects.
Danvers, MA: Thomson.
Ould, A. M. (1999). Managing software quality and business risk. Chichester,
England: John Wiley & Sons.
Pressman, R. S. (2001). Software engineering: A practitionerÊs approach. Boston,
MA: McGraw-Hill.
Schwalbe, K. (2004). Information technology project management. Cambridge,
MA: Thomson Course Technology.
Symes, S. (2005). Advantages & disadvantages of a fixed-price contract. Retrieved
from http://smallbusiness.chron.com/advantages-disadvantages-fixedprice-
contract-21066.html
Vliet, H. V. (1993). Software engineering: Principles and practice. New York, NY:
John Wiley & Sons.
Young, T. L. (1994). Planning projects. Kuala Lumpur: Pelanduk Publications.
Fitzgerald, J., & Dennis, A. (2009). Business data communication and
networking networking.(10th ed.). New York: John Wiley & Sons.

Copyright © Open University Malaysia (OUM)


COURSE GUIDE  xvii

TAN SRI DR ABDULLAH SANUSI (TSDAS)


DIGITAL LIBRARY
The TSDAS Digital Library has a wide range of print and online resources for the
use of its learners. This comprehensive digital library, which is accessible through
the OUM portal, provides access to more than 30 online databases comprising
e-journals, e-theses, e-books and more. Examples of databases available are
EBSCOhost, ProQuest, SpringerLink, Books24x7, InfoSci Books, Emerald
Management Plus and Ebrary Electronic Books. As an OUM learner, you are
encouraged to make full use of the resources available through this library.

Copyright © Open University Malaysia (OUM)


xxvi X COURSE ASSIGNMENT GUIDE

Copyright © Open University Malaysia (OUM)


Topic  Introduction to
1 Project
Management

LEARNING OUTCOMES
By the end of this topic, you should be able to:
1. Identify the key people in project management;
2. Differentiate software projects from other projects;
3. Describe a good project proposal;
4. List the activities that overlap in the project life cycle;
5. Differentiate between project life cycle and project management
methodology; and
6. Elaborate on the life cycle model of system development.

 INTRODUCTION
This topic defines project and project management. It provides several examples
of projects in general as well as those related to IT. Certain aspects of software
engineering projects differ from other types of engineering projects. These
aspects are clearly highlighted and differentiated. Some key people who get
involved in the duration of a project are also identified and explained in detail.

In this topic, you will learn about the purpose of preparing a project proposal
and the characteristics of a good proposal. Finally, the topic ends with a
description of the project life cycle; the project methodology and the software life
cycle model.

Copyright © Open University Malaysia (OUM)


2  TOPIC 1 INTRODUCTION TO PROJECT MANAGEMENT

1.1 DEFINITION OF PROJECT


The Project Management Institute (PMI) is the professional association for project
managers. According to the PMI (2008) (as cited in Lewis, 2011):

A project is a temporary endeavour undertaken to produce a unique product,


service or result.

Temporary means that every project has a definite beginning and an end. Their
dates have been decided. So, a project is not a permanent organisation without
an end. Unique means that the product, service, or result to be produced is
different from the others that have been produced before. It is not a repetitious
work. Thus, a project is a one-time activity with a well-defined set of desired
end results. It can be divided into subtasks that must be accomplished in order
to achieve the project goals. A repetitive job is therefore not a project. A single
task too is not a project.

Besides the above definition, you can simply define a simple project as a problem
scheduled for a solution. However, a more comprehensive definition can be
stated as a one-time job that has defined starting and ending dates, clearly
specified objectives or scope of work to be performed, a pre-defined budget and
usually a temporary organisation which is dismantled once the project is
complete. A project is complex enough that the tasks and subtasks require
careful coordination and control in terms of timing, precedence, cost and
performance.

Examples of projects are:


(a) Developing a new product or service;
(b) Building a bridge, house or road (construction project);
(c) Writing computer software (software project);
(d) Developing a computerised payroll system (IT project);
(e) Installing an assembly line (industrial project);
(f) Publishing a book or a magazine; and
(g) Developing a business plan or an IT plan.

Copyright © Open University Malaysia (OUM)


TOPIC 1 INTRODUCTION TO PROJECT MANAGEMENT  3

The following jobs are repetitive in nature, and thus are not considered as
projects:
(a) Processing insurance claims and invoices;
(b) Cooking in a restaurant;
(c) Driving a car over the same route every day; and
(d) Coming to work every day.

ACTIVITY 1.1

1. Have you ever been involved in a project? Think of what you


need to do or plan before embarking on a project.
2. List some examples of software projects that you have come across.

1.2 DEFINITION OF PROJECT MANAGEMENT


You must have been exposed to the term „management‰ before. The functions of
management include planning, directing, controlling and so on. Thus, project
management is simply the process of defining, planning, directing, monitoring
and controlling the development of an acceptable project to achieve certain
objectives at a minimum cost within a specified time-frame. A more
comprehensive definition is given below:

Project management is the application of knowledge, skills, tools and


techniques on project activities to meet project requirements. It is a process
of integrating everything that needs to be done as the project evolves through
its life cycle, from concept to handover, in order to meet the objectives that
have been set.

Successful project management means the ability to achieve the project


objectives within the set time-frame using the approved budget. Project
management aims at meeting or exceeding the needs and expectations of the
stakeholders.

Project management is not just the scheduling of tasks; not just the use of tools;
and not just the job title. It consists of the „what‰ and the „how‰. The „what‰ is
the tasks to be performed, while the „how‰ is the process by which they are
performed. The tools being used are the scheduling software, computers, project
Copyright © Open University Malaysia (OUM)
4  TOPIC 1 INTRODUCTION TO PROJECT MANAGEMENT

notebooks and daily planners. In short, according to Lewis (2011), good project
management is the correct mixture of tools, people and systems.

1.3 TYPES OF IT PROJECTS


We have already looked at examples of projects in general. Now, let us look at
the six types of IT projects listed in Figure 1.1.

Figure 1.1: Six types of IT projects

The following are descriptions of the six types of IT projects and some
comprehensive examples of these types of projects:

(a) Software Development


This is the most common IT project. You can develop the software for a
payroll system, student records system, library information system,
accounts receivable system, accounts payable system and many others. In
principle, most of the software development projects have a lot in common.
Thus, if you have done one of such projects, the next one would be much
easier.

(b) Package Implementation


This involves buying a ready-made software package, modifying and
installing it. It represents an alternative, quicker and cheaper way of
meeting customer requirements. However, it is not easy to find a ready-
made software that fully meets a customerÊs requirements. Thus, some
modifications are normally required. If the modification is too much, then it
is not worth the price. Many financial applications are available in the form
of packages ă e.g. accounts payable and accounts receivable.

(c) System Enhancement


This type of IT project arises when the existing system is not able to
accommodate new requirements in the forms of new features and
functions. When the system users or owners make the request for change,
two possible alternatives can happen. One way is to do a simple
enhancement which can be taken up as part of maintenance work.

Copyright © Open University Malaysia (OUM)


TOPIC 1 INTRODUCTION TO PROJECT MANAGEMENT  5

However, if the enhancement is relatively big, it needs to be managed as a


real project.

(d) System Migration


This type of IT project involves changing of the platforms. Quite often,
application systems are first developed on small computers running on
Windows or other simple operating systems. Later, as the volume of data
and the complexity increase, the applications need to be upgraded into
larger computers running on UNIX, and other more complex operating
systems. System migration requires a certain amount of software
modification.

(e) IT Infrastructure
This type of IT project includes replacement of computer hardware, servers,
network communication links and other computer equipment. It normally
does not involve a lot of software development, but may require a lot of
integration testing to make sure that all the components can work together
as a whole system. Trouble-shooting and minor modifications may be
needed.

(f) IT Consultancy
This type of IT project may include doing a feasibility study, business
analysis, system design, project management, training and other soft kinds
of assignments. Consultants are more like advisory service providers. They
do not normally get deeply involved in the actual doing of the work, but
their previous experience is required in order to have the credibility in
giving out advice.

ACTIVITY 1.2

1. What are the main differences between a software development


project and a package implementation project?
2. State three reasons why an organisation might decide to outsource
its IT provision and discuss the reasons.

1.4 SOFTWARE VERSUS OTHER PROJECTS


Software projects are distinctly different from other types of projects. The main
reason is the nature of the software itself. Software products have special
characteristics when compared with buildings, roads, cars and other engineering
products. These characteristics are summarised in Table 1.1.
Copyright © Open University Malaysia (OUM)
6  TOPIC 1 INTRODUCTION TO PROJECT MANAGEMENT

Table 1.1: Characteristics of Software Projects

Characteristics Details
Invisibility When a physical artefact such as a bridge or road is being
constructed, the progress of work can actually be seen. With
software projects, progress is not immediately visible. Software
remains largely intangible during most of the development process.
It is often difficult for project managers to assess the real progress.
Complexity Software products are more complex than other engineered
artefacts. For example, if you double the number of programmers,
you do not reduce the time taken by half. But for a building
construction work, if you double the number of workers, you can
reduce the time taken by half.
Conformity Other types of projects consist of the physical systems and materials
such as cement and steel which are governed by consistent physical
laws. They are very predictable. However, software projects have
to conform to flexible human requirements with diverse opinions.
Flexibility Software projects have the strength of flexibility to accommodate a
lot of changes. To add a change into the software, there is no need to
delete what has been done so far. Unlike other types of projects, the
software projects welcome any number of changes at any time. Of
course, implementation of changes may extend the project duration.
Hence the software projects are more flexible to incorporate changes
by adding new things or deleting some or all of the existing things.

Source: Jagesh et al. (2009)

1.5 PROJECT MANAGERS


The person who is responsible for organising, staffing, budgeting, directing,
planning and controlling the project is the project manager. This person develops
a plan through which the project can be tracked and controlled to ensure that the
project would meet pre-set objectives.

It is the responsibility of the project manager to identify all the project


stakeholders and determine their needs and expectations. These needs and
expectations should then be managed, influenced and balanced to ensure project
success. There should be an environment where the stakeholders are
encouraged to contribute their skills, ideas and knowledge which may be useful
to the success of the project.

The project manager understands what the customer wants and knows how to
fulfil those wants through the project that he manages. He is given a number of
people to help him execute the project. Thus, he needs to have a blend of
Copyright © Open University Malaysia (OUM)
TOPIC 1 INTRODUCTION TO PROJECT MANAGEMENT  7

management, human relations and technical skills. A detailed list of the kinds of
knowledge and skills needed are given in Table 1.2.

Table 1.2: Knowledge and Skills of a Project Manager

Types of Skills Description of Knowledge and Skills


Management related Skills in planning, conflict management, decision-making,
skills goal setting, leadership skills, team building and time
management.
Technical related Knowledge of IT, total quality management (TQM), earned-
skills value analysis, scheduling methods, problem solving,
analysis of data and concurrent engineering.
Human relations and Skills in negotiation, written-communication, group
related skills dynamics, interviewing, listening skills, oral communication,
coaching and counselling.

Source: Jagesh et al. (2009)

Figure 1.2 shows the three levels of management that a project manager may be
required to interface with at different times.

Figure 1.2: Three levels of management

The project managerÊs primary responsibility is to ensure effectiveness and


efficiency of the work across the entire project, which involves the following
actions at each level:

Copyright © Open University Malaysia (OUM)


8  TOPIC 1 INTRODUCTION TO PROJECT MANAGEMENT

(a) Strategic level


At the strategic level, the manager should:
(i) Evaluate and analyse the strategic impact of each proposed system on
the organisationÊs operation;
(ii) Report to senior management on the results; and
(iii) Contribute to the strategic decision-making process.

(b) Tactical level


At the tactical level, the managerÊs responsibility includes:
(i) Converting the objectives, targets and performance standards agreed
into operational planes;
(ii) Developing outline and detailed plans for the project; and
(iii) Monitoring the performance of the project against agreed plans.

(c) Operational level


At the operational level, the manager should:
(i) Manage and control daily activities of the project team members;
(ii) Conduct regular progress meetings with the project staff and team
leaders to identify and resolve existing and potential difficulties; and
(iii) Appraise the performance of individual members of the project staff.

The project manager plays a key role in the effective management of the
development process. He must be present and visible at all times. Although other
participants may also contribute significantly to the project, it is the manager
who fulfils the major role of integrating all the various contributions.

1.6 PROJECT STAKEHOLDERS


Project stakeholders are people who have a stake or interest in the project
activities to be done because they will be affected by the outcomes. Stakeholders
can be individuals or group of people, and can be internal or external to the
organisations.

Typical IT project stakeholders could be some of the following parties:

(a) Shareholders
They can be individual shareholders, or the proxy shareholders who
manage financial funds. Certainly, they have a stake in the financial future
of the company. They may or may not like changes to the organisation.
Copyright © Open University Malaysia (OUM)
TOPIC 1 INTRODUCTION TO PROJECT MANAGEMENT  9

(b) Managers
They are the people who run the company and make crucial decisions on
behalf of the company. They have a stake because of the salary they get and
their reputations are affected if the company goes up or down.

(c) Employees
They have an interest in the way business is run and the way changes are
taking place in the company. Their livelihoods are at stake should the
business fail.

(d) Customers
They are the people who buy goods and services from the company.
Changes in the company may affect our relationship with them. More
customers may come, or more may leave after changes are made.

(e) Suppliers
They are the people who provide raw materials, component parts and
services to the company. IT projects may change the companyÊs
relationship with them for better or worse. Thus, they too have a stake in
the project.

(f) Competitors
They have a deep interest in the project because of the outcomes after
completing the project. Thus, they may plan a counter-attack to frustrate
the companyÊs success should the new IT project turn out to be a success
story.

(g) Regulators
These are normally groups from the government or from the industry who
may change the law in response to developments in IT. For example, the
Internet social media and e-commerce may result in changes to the cyber-
laws.

(h) Community
These are the people in general. They may protest should the project
outcomes disturb their environment. In the non-IT projects such as
highways, the community may disrupt the traffic to express their
frustrations.

Some stakeholders are interested in the outcomes of the project, while others are
only interested in the project while it is being implemented. Therefore, in
addition to the project manager and the project team members, project

Copyright © Open University Malaysia (OUM)


10  TOPIC 1 INTRODUCTION TO PROJECT MANAGEMENT

stakeholders may include internal clients, business users, government, suppliers


and other agencies.

Project stakeholders can be classified as internal or external as shown in


Table 1.3.

Table 1.3: Internal and External Project Stakeholders

Project Stakeholders
Internal to the project External to the project team Totally external to the
team but in the same organisation organisation
This means that they The people and the The customers, users and
will be under the direct departments from whom the suppliers who will be
managerial control of project team may need affected by the system; or
the project leader. assistance. the contractors who will
carry out the project work.

Source: Jagesh et al. (2009)

SELF-CHECK 1.1

1. What are the special characteristics that differentiate a software


project from other types of projects?
2. Who is the person who manages a project?
3. Is the user of a project a project stakeholder?

1.7 PROJECT PROPOSALS


A project proposal summarises the development of decisions based on the
clientÊs requirements, the project managerÊs knowledge of the work, and the
discussions held among the project team on the possible alternative ways of
implementing the project. The aim of the project proposal is to present to the
client a clear, high-level understanding of the project work.

It should include a suggested schedule for developmental work including the


main stages, and the overall cost. The proposal enables the client to decide on
whether to continue or not to continue the proposed project. The project proposal
should be convincing and relevant to the needs of the client. It should be exciting
and innovative. As the client may receive proposals from other companies as
well, the proposal should also be competitive.

Copyright © Open University Malaysia (OUM)


TOPIC 1 INTRODUCTION TO PROJECT MANAGEMENT  11

The project proposal should cover the following items:


(a) Executive summary and general introduction;
(b) Statements of what the clients and users want from the project;
(c) Description of the approach and reasons for the choice;
(d) Outline diagram of the proposed structure;
(e) Description of the human and non-human resources needed;
(f) Work breakdown structure and the schedule;
(g) Cost/payment structure; and
(h) Limitations of the proposal.

The proposal may be adjusted and refined on the activities, tasks, schedule and
budget before it becomes a document of contract. What is a contract?

A contract is an agreement between two parties (a client and a contractor)


that defines their benefits and responsibilities.

The contract for a software product obliges the project team to provide certain
deliverables, by a certain date, for some kind of remuneration. The contract comes
into the picture after the client is satisfied and agrees with the proposal submitted.
Once the contract is signed by the parties, the actual project work will start.

SELF-CHECK 1.2

1. A college has assigned the project of developing financial and


accounting software to a software organisation. For this project,
who are the stakeholders?
2. What are the characteristics of a good project proposal?
3. What is the difference between a project proposal and a contract?

1.8 PROJECT LIFE CYCLE


The project life cycle refers to a series of activities which are necessary to fulfill
project goals or objectives. The concept of a project life cycle provides a useful
framework for looking at the project dynamics over time. This idea is quite

Copyright © Open University Malaysia (OUM)


12  TOPIC 1 INTRODUCTION TO PROJECT MANAGEMENT

familiar to most managers. It is used to conceptualise the stages of work,


which are often accompanied by the budgetary and organisational resource
requirements of each stage.

Phases of the project life cycle (PLC) can vary in details. As a general rule, all
projects have a life cycle consisting of four, five or six phases.

1.8.1 Four-Phase Project Life Cycle


Whether you are managing an IT project, a construction project, a business
project or any other project of any size, you will go through the same four
phases: initiation, planning, execution and termination.

Even though the phases have distinct qualities, they do overlap. For example,
you may start with a budget and a tentative completion date during the planning
phase. However, once you are in the execution phase, you will get new updated
information on the details. Thus, you will revise the budget and the completion
date.

Table 1.4 provides a very simple frame of reference of the four distinct phases of
activity in a four-phase project life cycle.

Table 1.4: Four-Phase Project Life Cycle

Stage Description
1. Conceptualisation This is the initial stage of a project. Top managers determine
(Initiation) that a project is necessary. Preliminary goals and alternative
project approaches are specified, as are the possible ways to
accomplish these goals.
2. Planning This is the establishment of formal plans to accomplish the
projectÊs goals. Activities include scheduling, and allocation of
other specific tasks and resources.
3. Execution This is the actual work of the project. Materials and resources
are procured, the project is produced and performance
capabilities are verified.
4. Termination This consists of the final activities that must be performed
once the project is completed. These include releasing
resources, transferring the project to clients and if necessary,
reassigning project team members to other duties.

Source: Lewis (1993)

Copyright © Open University Malaysia (OUM)


TOPIC 1 INTRODUCTION TO PROJECT MANAGEMENT  13

The four-phase project life cycle is extremely useful for project managers because
it helps them to define the level of effort needed to perform various tasks
associated with each stage. Figure 1.3 shows the distribution of effort throughout
the four-phase project life cycle.

Figure 1.3: Distribution of effort throughout the four-phase project life cycle

During the early stages, requirements are minimal. They provide a method for
tracking the status of a project in terms of its stages of development. Level of
effort is highest during the execution phase. For students of project management,
the life cycle gives them the logical flow of the phases and activities within
phases.

1.8.2 Five-Phase Project Life Cycle


Now, let us look at the five-phase life cycle. This is a generic life cycle. It is
consistent for virtually all types of IT projects. For those of you who are familiar
with pseudo-codes, a project life cycle can be better illustrated by using this
technique, especially on what is involved during the execution phase. A pseudo-
code version to illustrate an idea of the project life cycle is presented in
Figure 1.4.

Copyright © Open University Malaysia (OUM)


14  TOPIC 1 INTRODUCTION TO PROJECT MANAGEMENT

Figure 1.4: Pseudo-code for a five-phase project life cycle


Source: McLeod and Smith (1996)

According to McLeod and Smith (1996), the major advantages of the project life
cycle in general (especially the five-phase PLC) are:
(a) Project managers do not have to „reinvent the wheel‰ for each new project;
(b) Senior management and steering committee groups will be able to compare
projects meaningfully;
(c) Project reporting and terminology can be consistent in terms of the phases
and review points;
(d) Expertise can be built up with respect to the estimating techniques and past
performances; and
(e) Standard project plans can be built up especially in tools, which need only
slight modifications to provide a solid, comprehensive plan for a new
project.

1.8.3 Six-Phase Life Cycle


If you wish to have a more detailed breakdown, there is the six-phase project life
cycle. For a six-phase model, the phases can be classified as:
(a) Concept;
(b) Definition;
Copyright © Open University Malaysia (OUM)
TOPIC 1 INTRODUCTION TO PROJECT MANAGEMENT  15

(c) Design;
(d) Construction (or development);
(e) Application (or installation); and
(f) Post-completion.

The six phases of this life cycle are explained in Table 1.5.

Table 1.5: Six-Phase Project Life Cycle

Phase Description
Concept Investigation of technology, feasibility studies and survey of
competition.
Definition Specification of objectives, establishing targets, quality assurance
procedures, setting up control system and establishing project
organisation.
Design Architectural and engineering, design reviews, assessment reports,
revising cost and performance targets.
Construction (or Most effort expended, first units, begin sales campaign and quality
development) control procedures.
Application (or Install and field test, begin de-staffing, advertising begins, debug
installation) and re-design.
Post-completion Final de-staffing, post-mortem analysis, final reports and closeout.

Source: Lewis (1993)

1.8.4 Overlapping Activities in a Project


As mentioned previously, the project life cycle typically consists of several
phases. Each phase has a set of tasks or activities, expected results and quality
checks. Some activities are confined to specific phases, while others run through
several phases of the life cycle. Of special significance are the activities that
overlap the entire life cycle.

These activities that overlap the entire life cycle are:


(a) People management;
(b) Risk management; and
(c) Quality management.

Copyright © Open University Malaysia (OUM)


16  TOPIC 1 INTRODUCTION TO PROJECT MANAGEMENT

These will be discussed separately in later topics. Figure 1.5 illustrates the
concurrency of these activities along the project life cycle.

Figure 1.5: Project phases and concurrent activities


Source: McLeod and Smith (1996)

As mentioned earlier, most of the effort in system development project goes into
the so-called build or construction phase, which is actually inside the larger
execution phase. The construction phase includes detailed design, coding, testing
and documentation. You can save a lot of effort and money by ensuring that you
have a solid base to work on before entering this phase. That means, you are
advised to do thorough planning before entering this phase.

SELF-CHECK 1.3

1. List the four phases of the project life cycle.


2. Which phase of the project life cycle requires the most effort?
3. Name three activities that overlap in the entire project life cycle.

1.9 PROJECT MANAGEMENT METHODOLOGY


Small companies probably do not have their project management procedures and
systems. They simply hire experienced project managers and allow them free
rein. The results would be having no consistency in approach. Anyone assigned
to a new project team has to learn new scheduling, budgeting and reporting
techniques. As a result, systems duplication, time to learn and the resulting
inefficiency in the project execution can cost unnecessary money to the
organisations. For people who work on multiple projects in the same company,

Copyright © Open University Malaysia (OUM)


TOPIC 1 INTRODUCTION TO PROJECT MANAGEMENT  17

they have to follow different steps and support multiple meetings and report
formats which can be conflicting at times.

However, large companies, or companies with a project management office


(PMO) normally create the procedures and systems that allow for coordinated,
simplified project planning and execution. This kind of standard procedure and
system is called a „project management methodology‰. The objective of the
project management methodology is to provide a standard method and
guideline. This would ensure that projects are conducted in a disciplined, well-
managed and consistent manner that promote the delivery of quality products
and result in projects that are completed on time and within budget.

In the most general sense of the word, the term „methodology‰ is simply a loose
collection of methods, techniques and tools. A different methodology can be
made up for each project. But this kind of practice is not normally followed
within organisations. It is more common for an organisation to use a standard
methodology, which is applicable for most projects. This offers a number of
advantages as follows:
(a) Saving time on selecting a methodology for every project;
(b) A formal method is better because a documentation standard is available;
and
(c) As each methodology needs training, the training costs are reduced.

Adopting and following a standard methodology gives a lot of benefits both to


the organisation as well as to the individual project managers. Some of the
advantages are:
(a) Methodologies ensure that a consistent, reproducible approach is applied to
all projects and this reduces learning time and maintains standards;
(b) Methodologies reduce the risk associated with shortcuts and mistakes;
(c) Methodologies improve the quality of the end products;
(d) Methodologies influence the establishment of a „professional attitude‰ and
diffusion of „professional skills‰; and
(e) Methodologies are good starting points for novices and useful controls for
the project leaders.

Methodologies are too restrictive for experts, who may want to by-pass the steps
and activities. Therefore, they should not be too static. The project manager
needs to assess the project characteristics, see what project management
processes are required and then determine how to tailor the methodology. This
tailoring is then reflected in the „project plan‰.
Copyright © Open University Malaysia (OUM)
18  TOPIC 1 INTRODUCTION TO PROJECT MANAGEMENT

Further, a standard methodology should not be made to become stagnant or


obsolete. Project processes should be established to improve the methodology
over time. Process improvement is cyclical in nature. It requires a mechanism to
continually evaluate and refine improvements until the process is fully optimised
for the organisation. Thus, when project processes change, methodologies too
need to change in a gradual manner.

If your organisation does not have a methodology yet, then you can start to make
one after completing this course. Some methodologies have acquired names or
have been given famous names. Examples of the famous methodologies are
described in Table 1.6.

Table 1.6: Famous Methodologies

Methodology Description
PRINCE2 This is a structured project management methodology.
The Lewis Method This is a project management methodology promoted by
James Lewis. It conforms to the five processes defined by
the Project Management Body of Knowledge (PMBOK) of
the Project Management Institute (PMI).
SSADM This is a systems development methodology in the UK and
can be linked to the PRINCE2.
DSDM This is a systems development methodology based in the
UK.
Information Engineering This was promoted by James Martin and has become a
Method (IEM) systems development methodology since the 1980s.

Meanwhile, it is good to introduce to you the Project Management Institute


(PMI). This is a professional association for project managers. In 2010, PMI had
passed the 500,000-member mark (Lewis, 2011). It attempts to promote project
management as a profession, thereby raising the perceived status of project
managers. It has developed a certification process that confers upon those who
meet the requirements, the designation of Project Management Professional
(PMP). So, this is an additional professional qualification like the ACCA, CPA,
CIMA and so on.

Today, many companies prefer someone who is certified in the field in their
recruitment process. If you want to become a certified project manager, you can
get more information on PMI on this website: http://www.pmi.org.

Copyright © Open University Malaysia (OUM)


TOPIC 1 INTRODUCTION TO PROJECT MANAGEMENT  19

1.10 SYSTEM DEVELOPMENT LIFE


CYCLE (SDLC)
You must have been introduced to the term „System Development Life Cycle‰
(SDLC) before, especially in the subject of System Analysis and Design. In short,
the System Analysis and Design forms the core of SDLC.

SDLC consists of all phases in the life of an information system. Typically the
phases are:
(a) Problem identification;
(b) Feasibility study;
(c) System analysis;
(d) System design (specification);
(e) Programming;
(f) Testing;
(g) Installation;
(h) Maintenance; and
(i) Evaluation.

If you are managing a project involving software development, then this section
is important to go through. Otherwise, you can skip this section. The main
differences between software and other projects have already been discussed
earlier in this topic. It has been said that software development projects must be
treated differently from other projects. These other projects could be other types
of IT projects, or even those in the fields of civil engineering, business and so on.

In this section, only the simplest of the software development model will be
introduced, called the life cycle model, also known as „the waterfall model‰. If
your software development customer can agree to follow this model, then your
project can be easily managed, almost similar to managing other projects. You
can easily incorporate this model into your project plan by fitting its stages
(phases) into the PLC. If your customer does not agree, then you have to consider
other models such as the prototyping model ă which will be discussed in details
in a later topic.

Copyright © Open University Malaysia (OUM)


20  TOPIC 1 INTRODUCTION TO PROJECT MANAGEMENT

1.10.1 The Waterfall Model


The waterfall model is also called the „waterfall life cycle model‰. The waterfall
model has been used in various development projects for more than 40 years. It
was borrowed from the classical engineering discipline, and thus is taking an
engineering approach to provide a solution. Despite the availability of other
alternative models and approaches, this model is still the most widely used and
is the assumption for the stages of SDLC. It is called the life cycle model because
it follows the stages of SDLC.

The flow is like water falling down from the top of a hill as shown in Figure 1.6.

Figure 1.6: The waterfall life cycle model

This model is meant to be simple and straightforward. Figure 1.6 helps to make
information system development more visible. In principle, every stage is
supposed to be executed only once, although in practice there may be iterations
throughout all the stages. At the end of every stage, there is to be a document,
report or deliverable being produced for the management as a basis for going
down to the next stage. So, the arrows in Figure 1.6 represent various
deliverables being produced. The output of one stage becomes the input to the
subsequent stage and the flow moves down until completion of the project.

Copyright © Open University Malaysia (OUM)


TOPIC 1 INTRODUCTION TO PROJECT MANAGEMENT  21

The strengths and the advantages of the waterfall model are as follows:
(a) Being linear in form, it is very simple to understand, to teach and to use;
(b) The model is easier to manage;
(c) Software development is likely to be faster and cheaper;
(d) Deliverable of a previous phase becomes the specification for the next
phase, making it possible to hand over the job to another group of people at
each phase; and
(e) Staff resignation does not affect this project very much.

However, the waterfall model is not good in all situations. The main
shortcomings of this model are as follows:
(a) The assumption of a clear specification at a very early stage is not realistic;
(b) Efforts are directed at a complete product without a plan to modify it and
this is also unrealistic in todayÊs applications; and
(c) Finally, it does not accommodate user participation in projects, as this
would interrupt the smooth flow of IS development. This could lead to user
dissatisfaction.

The waterfall life cycle model gives rise to the concept of two groups of people ă
the development team and the maintenance team. The former concentrates on
developing all the systems, while the latter would maintain them. Maintenance
involves all the future modifications of the new system as a result of the userÊs
continuous requests. However, eventually a stage will be reached when it is no
longer possible to change the system simply by adding a module or by changing
data records. This kind of a radical change requires the effort of a system analyst
who would come in to redefine the system as a new project.

1.10.2 Comparison of SDLC with PLC


SDLC stages illustrate the process of information systems development. It
provides the stages that a typical system passes through during its life. Thus,
developing a new system can easily follow the pattern of SDLC. The stages
involved in SDLC are as shown in Figure 1.7.

Figure 1.7: Stages in SDLC

Copyright © Open University Malaysia (OUM)


22  TOPIC 1 INTRODUCTION TO PROJECT MANAGEMENT

However, in a practical project management, the project life cycle (PLC)


addresses project issues better than the SDLC. The stages in SDLC can be placed
and matched with the PLC as listed in Table 1.7.

Table 1.7: Comparison of Stages in PLC and SDLC

No. Stages in PLC Stages in SDLC


1. Initiation Problem identification
2. Determine feasibility Feasibility study
3. Planning System analysis
4. Execution System design, construction and installation
5. Termination (End of installation)
6. Post-termination System maintenance and evaluation

We can now differentiate the project life cycle (PLC) from the SDLC. Generally,
all projects share the following phases: initiate, determine feasibility, plan and
estimate, execute and terminate. The „execute‰ phase can be iterative. For a
system development project, „execute‰ consists of specification, design,
programming, system testing and installation. The system development
methodology will specify the tasks, deliverables and quality standards for each
phase.

The PLC is thus a container for SDLC. It is an umbrella incorporating SDLC


(McLeod & Smith, 1996). Many phases of SDLC may coincide with phases of
PLC, but PLC is more extensive when it comes to real projects. A generic PLC is
suitable for all kinds of IT projects. There are some activities that occur once ă e.g.
initiation, determining feasibility and termination; while other activities occur
repeatedly for every phase. Some occur for every task of the technical life cycle of
the project.

SELF-CHECK 1.4

1. What is the difference between a project life cycle and a project


management methodology?
2. What are the differences between SDLC and project life cycle?

Copyright © Open University Malaysia (OUM)


TOPIC 1 INTRODUCTION TO PROJECT MANAGEMENT  23

ACTIVITY 1.3

Since ICT is a means to facilitate our lives and make things easier for us,
think of how technology itself can help in making IT project
management easier to monitor and more efficient.

 A project is a one-time job, with start and end dates, to fulfil a scope of work,
with an agreed budget and executed by a temporary organisation which is
dismantled once it is completed.

 Software development project is the most common IT project. You can


develop the software for a payroll system, student records system, library
information system, accounts receivable system, accounts payable system
and many others.

 The project manager plays a key role in the effective management of the
development process. He must be present and visible at all times.

 A project proposal gives a high-level idea of what to achieve with what


resources. The project proposal should be convincing and relevant to the
needs of the client. It should be exciting and innovative.

 Project stakeholders are the persons who have a stake or interest in the
project ă they may be affected by the projectÊs outcomes.

 Project management is the activity of planning, scheduling, monitoring and


controlling the project to achieve its objectives with the available resources.

 A standard project life cycle consists of four phases: initiation, planning,


execution and termination.

 Project management methodology is practical guideline to ensure that


projects are conducted in a disciplined, well-managed and consistent manner.

 SDLC illustrates the process of information systems development. It provides


the stages that a typical system passes through during its life. Thus,
developing a new system can easily follow the pattern of SDLC.

Copyright © Open University Malaysia (OUM)


24  TOPIC 1 INTRODUCTION TO PROJECT MANAGEMENT

Project Project management methodology


Project life cycle (PLC) Project proposal and contract
Project management System development life cycle (SDLC)

Jagesh, N., Rahim, Y. A., Bakar, N. S. A. A., & Awang, M. Z. (2009). CBPM4103 ă
Information technology project management (2nd ed.). Kuala Lumpur: Open
University of Malaysia.
Lewis, J. P. (1993). The project managerÊs desk reference: A comprehensive guide
to project planning, scheduling, evaluation, control & systems. Chicago, IL:
Probus.
Lewis, J. P. (2011). Project planning, scheduling & control: The ultimate hands-on
guide to bringing projects in on time and on budget (5th ed.). New York, NY:
McGraw-Hill.
McLeod, G., & Smith, D. (1996). Managing information technology projects.
Danvers, MA: Thomson.

Copyright © Open University Malaysia (OUM)


Topic  Project
2 Selection

LEARNING OUTCOMES

By the end of this topic, you should be able to:


1. Identify the four main parties that propose new projects;
2. Explain the importance of evaluating and selecting projects;
3. Differentiate project, portfolio and programme management;
4. Discuss the various non-numeric and numeric selection models with
examples; and
5. Illustrate the importance of linking projects to business objectives.

 INTRODUCTION
Development projects are capital investments. These can be software
development, construction of a new building or buying of a fleet of lorries. At the
end of each project, an organisation is going to have a kind of asset of
considerable value. Other examples of IT capital expenditures include the
construction of a new computer centre, purchasing of a mini computer or setting
up of a communication system. There must be some kind of cost recovery
programmes following these expenses.

Investment appraisal is concerned with managerial decisions on whether or not,


when, and how to spend money on projects. Such decisions are important for the
organisation concerned, because a large sum of money is to be committed in an
irreversible decision, with no definite knowledge on the size of future benefits.
This could be a province of the managers, but it would be good for other officers
like the system analysts to realise the process involved.

Copyright © Open University Malaysia (OUM)


26  TOPIC 2 PROJECT SELECTION

This topic will introduce various selection methods and criteria for selecting a
project, that is, whether or not to go ahead with a project. The organisation, the
project manager, and the project team members should compare the benefits
with the costs, risks and techniques that are involved in a project before taking it
up. There are different project selection models and this topic will discuss the
different criteria in making a choice of those models. The two important project
selection models ă namely the numeric and the non-numeric models ă will be
discussed in greater detail in this topic.

2.1 PROJECT IDENTIFICATION


Let us think about the people who would normally identify and suggest various
IT projects. The sources of these ideas show the nature of projects. That
influences the way projects are evaluated and selected for implementation.
Indeed, different organisations identify projects in different ways. It normally
depends on the size of organisations ă whether small, medium or large.

According to Hoffer, George and Valacich (1999), the following are the people or
parties that identify and suggest new projects:

(a) A key member of the top management


Top management consists of people like the CEO, the managing director,
the general manager, the board of directors (BOD) and so on. They are very
high level people in the organisation, with deep knowledge and wide
experiences. Their suggestions are not likely to be questioned by an
ordinary officer. Projects identified by the top management normally have
a strategic organisational focus. A lot of logic based on experience is
normally involved with just a little numerical justification.

(b) A steering committee


A steering committee is a high level committee that steers the project along
the direction of corporate objectives. The committee is formed by the BOD,
and is meant to represent the board outside the meetings of the board.
Certainly, the committee reports to the BOD regularly. The people normally
chosen to sit in the steering committee consist of the project sponsor,
the project manager, heads of various user departments and other
stakeholders. Projects identified by the steering committee normally reflect
the diversity of the committee members and therefore have a cross-
functional focus.

(c) User departments


User departments are business users of the system to be developed. They
have deep and wide experiences in the operational aspect of the system ă
Copyright © Open University Malaysia (OUM)
TOPIC 2 PROJECT SELECTION  27

whether they are currently being done manually or with a limited usage of
IT. Thus, they may suggest portions of the system, or even the entire system
to be computerised and automated. Those identified by individual
departments normally have a narrow tactical focus. They are just thinking
from inside their individual departments without crossing into other
departments. Because of their business nature, their projects need to pass
the required return on investment (ROI).

(d) The IS/IT management group (for IT projects)


Finally, the information system (IS)/IT management group consists of the
people inside the IS/IT department ă e.g. the CIO, IT director and
managers, the systems analysts and programmers, and even other officers
inside the division and department. These are mostly very technical people
who think from the perspective of the technical feasibility and based on the
knowledge they have gained from the IT industry. Thus, projects suggested
by the IS/IT group are less concerned with the cost-benefit analysis.

2.2 PROJECT PORTFOLIO


It should be noted that a medium-size organisation (or a large-size one) normally
has a lot of suitable projects to be undertaken at any one time. However, the
organisation normally does not have enough resources to do them all at the same
time ă mainly not enough money, and not enough people to handle them. Thus,
only a handful of the projects will get selected for implementation. These lucky
projects are collectively called the „project portfolio‰ and the person-in-charge of
these projects is called the „portfolio manager‰.

2.2.1 Programme Management and Portfolio


Management
There are two new terms that are closely related to project management and a
short explanation for each is required to differentiate them. They are programme
management and portfolio management.

Let us get to know more about these terms.

(a) Programme Management


The term „programme management‰ has nothing to do with managing
computer programs. Programme management can be defined as:

Copyright © Open University Malaysia (OUM)


28  TOPIC 2 PROJECT SELECTION

„A set of IT projects that is undertaken within an overall strategic


business framework that together will contribute to meeting business or
organisational objectives and which involve the sharing of a relatively
fixed pool of resources in terms of people, equipment and supporting
services‰ (Cadle & Yeates, 2008).

To illustrate programme management, let us assume that there are five


small projects that are required to achieve an organisationÊs business
strategy. This has been agreed by the top management. Let us say ă the
strategy is to achieve a competitive advantage in the retail business.
Therefore, in a way, all the five projects do share the overall objectives in
the long run. But each project has its own project manager with its own
budget and scope of work.

The starting and ending dates for each project could be very different, but
they are closely related and share common resources. Because of so many
projects that are required to be completed, these five projects are placed
under one „programme director‰ who will monitor their progress from
project number one until project number five. Thus, programme
management is an extension of project management. A programme director
can be an experienced project manager or even a non-IT senior manager,
who is business-oriented and is well positioned to champion for the
programme.

(b) Portfolio Management


Portfolio management has a different set of objectives, but it shares the
same concept as programme management. A portfolio manager looks after
a set of projects that often do not share the same objectives and are meant
for different clients. He/she needs to arbitrate between competing projects
and decide which ones shall have the resources. In other words, itÊs the
portfolio manager who decides which projects get the priority in the
selection process, and so will be given the go-ahead permission.

Similar to a programme, a portfolio consists of a set of projects. But the


projects in a portfolio need to be launched almost immediately, while those
in a programme are launched at different times. Thus, in a larger
organisation with a lot of projects going on, project managers need to take
orders from the portfolio manager and the programme manager.

Copyright © Open University Malaysia (OUM)


TOPIC 2 PROJECT SELECTION  29

2.2.2 Problems for Portfolio Managers


Every organisation has two constraints that limit how many projects can be
active at any point in time. One is the amount of money the organisation has or is
willing to invest in organisational change. The other is the organisationÊs
strategic projects, that is, the ones that are most in demand among so many
projects. This determines how many projects can be active at any point in time.
For example, an organisation must complete 20 projects in order to meet its goals,
while it has only the capital to complete 15 of those projects. This poses a major
problem to the organisation, and a challenge for the project portfolio manager.
The latter must find ways to improve project flow, or look for a better project mix
in order to achieve the organisationÊs goals as much as possible (Kendall &
Rollins, 2003).

The four biggest universal problems in project portfolios are as follows:


(a) Too many active projects (often double the number supposed to be);
(b) Wrong projects (i.e. ones that do not provide value);
(c) Projects not linked to strategic goals; and
(d) Unbalanced portfolio (e.g. different projects compete for same resources).

One of the reasons that these major problems exist is because of many projects
having unclear return on investment (ROI). They have active projects that do not
go through the top management. Thus, portfolio management must ensure that
the collection of projects chosen and done must meet the goals of the
organisation.

Just as a stock portfolio manager looks for ways to improve the ROI, so does a
portfolio manager. Stock portfolio managers get and retain their clients because
of their ability to increase stock prices. Similarly, project portfolio managers
retain their jobs based on their ability to achieve organisational goals (Kendall &
Rollins, 2003).

All these issues point to the need for a proper project selection process so that
projects have their clear ROIs. Only projects that can contribute to the strategic
goals of the organisation should get selected with higher priorities than the
others.

Copyright © Open University Malaysia (OUM)


30  TOPIC 2 PROJECT SELECTION

SELF-CHECK 2.1

Why is it important for project managers to understand the business


strategy of the organisation?

2.3 PROJECT SELECTION MODELS


Have you heard of the term „project selection‰? Let us look at the definition of
this term.

Project selection is the process of evaluating a set of the proposed projects and
choosing to implement some of them so that the objectives of the organisation
will be achieved.

There are two basic types of project selection models as shown in Figure 2.1.

Figure 2.1: Two types of project selection models

Both the types of selection models are equally used widely and both the selection
models come under the economic feasibility aspect of the project life cycle. These
selection models will be discussed in detail in the following subtopics.

Copyright © Open University Malaysia (OUM)


TOPIC 2 PROJECT SELECTION  31

ACTIVITY 2.1

We all face choices in our daily lives. Therefore we need to select the
best choice in accordance with numerous factors. What are the factors
that you think are important in the selection of a project?

2.3.1 Non-Numeric Selection Models


Non-numeric models look at a very wide view of the project by considering
items from market share to environmental issues. Non-numeric models do not
use numbers as inputs, whereas numeric models do, but the criteria being
measured may be either objective or subjective.

Non-numeric models are older and simpler, but you need to have a long
experience in order to understand their underlying logic. Indeed, they are
normally the arguments of the top management. Their benefits are largely
intangible in nature because concrete figures are not available.

Non-numeric models have five subtypes, like the ones shown in Figure 2.2.

Figure 2.2: Five non-numeric selection models

Table 2.1 provides some explanation on the five non-numeric project selection
models.

Copyright © Open University Malaysia (OUM)


32  TOPIC 2 PROJECT SELECTION

Table 2.1: Non-Numeric Project Selection Models

Models Explanation
The Sacred In this model, a senior and powerful official in the organisation
Cow suggests the project. The project is considered sacred as it comes from
a very high (godly) authority. Since it is sacred or holy, the project
will have to be accepted and executed until it is complete, or until
the boss personally recognises the idea as a failure and terminates it.
PETRONAS Twin Tower project was considered a sacred cow, since
no reliable numeric data could be produced to justify its (ROI). Such a
building was perceived to be a strategic project that could make
Malaysia well-known ă having the tallest building in the world. By
now, it is certainly proven to be a successful shopping area with
tourists and visitors from all over the world.
The Operating The project is required in order to keep the system running. The
Necessity primary question is whether the system is worth saving at the
estimated cost of the project. If the answer is yes, t h e n project costs
will be examined to make sure that they are kept as low and consistent
with the project success, but the project will be funded. To illustrate
this model ă if a flood is threatening the plant, a project to build a
protective dike does not require much formal evaluation, as the flood
could interrupt the plantÊs continuous operation. This is an example of
the operating necessity model. It is a „must do‰ project in order to
continue running the business.
The In some cases, t h e decision to undertake a project is based on a
Competitive desire to maintain the companyÊs competitive position in the market.
Necessity If such a project is not done, the company would not be able to
compete in the market. If that happens for a long time, the
company would not be able to survive. An example of this project is
the implementation of a bar-coding system in a supermarket. It is not
absolutely necessary, but without such a system, the supermarket
would lose its competitive position and would finally be closing
down. Investment in an operating necessity project takes precedence
over a competitive necessity project.
The Product In this model, a project to develop and distribute new products
Line would be judged on the degree to which it fits the companyÊs existing
Extension product line, fills a gap, strengthens a weak link or extends the line
in a new, desirable direction. Sometimes careful calculations of
profitability are not required. Decision makers can act on their beliefs
about what will be the likely impact on the total system performance
if the new product is added to the line. For example ă in a housing
development area, one product line extension would be to build a
college, in addition to the houses. This would increase the market
value of all houses in the area.

Copyright © Open University Malaysia (OUM)


TOPIC 2 PROJECT SELECTION  33

Comparative This model finds its use in the context, whereby, an organisation
Benefit Model has many projects to consider and compare, and the senior
management would like to select a subset of the projects that
would give most benefits to the firm. The model is widely adopted
for selection decisions on all sorts of projects. Senior management of
the organisation examines all projects with positive recommendations,
and attempts to construct a portfolio that best fits the organisationÊs
aims and its budget. Individual rankings will be developed for the
projects and are examined. Projects can then be selected in the order of
preference. For example, the following subsets of projects are to be
considered for implementation: ABCDE, CDEFG or ABCFG out of
seven projects (A, B, C, D, E, F and G). After due consideration, a
portfolio consisting of CDEFG is found to be the best.

2.3.2 Numeric Selection Models


In essence, system development projects will be evaluated by measuring the
worthiness of proposals to spend money, by comparing the benefits with the
costs. If this measurement is done badly, then it can hamper a firmÊs growth and
employment prospects for years to come, and may even lead to inability to
attract new investors and customers.

Figure 2.3 shows the three popular quantitative techniques to assess the
cost-effectiveness of a project. These constitute the numeric selection models,
being the alternative approach to the non-numeric models already discussed
previously.

Figure 2.3: Numeric selection models

Copyright © Open University Malaysia (OUM)


34  TOPIC 2 PROJECT SELECTION

The three numeric selection models are explained further here.

(a) Payback analysis


The „payback analysis‰ technique is quite simple and is a popular method
for determining if and when an investment will pay for itself. Because
systems development costs are incurred long before benefits begin to
accrue, it will take some time for the benefits to overtake the costs. After
implementation, the project will incur additional operating expenses that
must be recovered too. Payback analysis determines how much time will
lapse before accrued benefits overtake accrued costs. This period is called
the payback period.

(b) Return on investment (ROI)


The „return on investment‰ (ROI) is the ratio of the net income of a project,
divided by the investment in the project. To pass the test, the answer must
be a positive number ă some multiples of the financial investment ă the
higher the better. This is a lifetime figure and not just an annual figure. The
formula is:

ROI = (Estimated Lifetime Benefits ă Estimated Lifetime Costs)


Estimated Lifetime Costs

(c) Net present value (NPV)


The „net present value‰ (NPV) is the benefit that a project is expected to
yield, expressed in current monetary value. This is a more preferred cost-
benefit analysis technique adopted by many managers. Here again, we
initially determine the costs and benefits for each year of the systemÊs
lifetime. Then, we need to adjust all the costs and benefits back to the
present dollar values. Therefore, inflationary and other risky values are
automatically removed.

SELF-CHECK 2.2
1. What are the two major project selection models?
2. List three numeric selection models.
3. List five non-numeric selection models.
4. What does the sacred cow technique mean?

Copyright © Open University Malaysia (OUM)


TOPIC 2 PROJECT SELECTION  35

2.4 COST-BENEFIT ANALYSIS


Cost-benefit analysis is normally the kind of calculations used in the numeric
selection models. If cost exceeds benefit in a certain year, it constitutes a negative
cash flow. However, if benefit exceeds cost in the year, it constitutes a positive
cash flow for the year. In another method known as the Internal Rate of Return
Method (IRR), negative cash flow means cash outflow, while the positive cash
flow means cash inflow.

In the cost-benefit analysis, assessment is based upon the question of whether the
estimated costs are exceeded by the estimated income and other benefits.
Additionally, it is usually necessary to ask whether or not the project under
consideration is the best of a number of options. There might be more candidate
projects that can be undertaken at any one time and, in any case, projects will
need to be prioritised so that scarce resources may be allocated effectively.

The most common way of carrying out an economic assessment of a proposed


information system or other development, is by comparing the expected costs of
development and operation of the system with the benefits of having it in place.
The standard way of evaluating the economic benefits of any project is to carry
out a cost-benefit analysis, which consists of two different steps:
(a) Identifying and estimating all the costs and benefits; and
(b) Expressing these costs and benefits in common units.

Any project that shows an excess of benefits over costs is clearly worth
considering for implementation. Refer to the details of the positive and negative
cash flows calculated using the Payback Method, the NPV Method and the IRR
Method in the following subtopics. But, before that, let us understand the term
„cost‰ and „benefit‰ first.

2.4.1 What is Cost?


In IS/IT systems, costs fall into two categories. There are costs associated with
developing the new system and there are costs associated with operating the
system. The development costs can be estimated from the outset of a project, and
should be refined at the end of each project phase. The operating cost can be
estimated only once the specific computer-based solutions have been defined.
The lifetime benefits must recover both the developmental and the operating
costs.

Copyright © Open University Malaysia (OUM)


36  TOPIC 2 PROJECT SELECTION

The two categories of costs are further explained as follows:

(a) Systems development costs


Systems development costs are usually one-time off, and that will not recur
anymore once the project has been completed. Many organisations have
standard cost categories that must be evaluated, but in the absence of such
categories, the following lists can be the guideline:

(i) Personnel cost


This consists of the salaries of systems analysts, programmers,
consultants, operators and secretaries who work on the project. If they
work on many projects, then their salaries should be pro-rated.

(ii) Computer usage


This constitutes the computer time that will be used for programming,
testing, system conversion, word processing, etc. If a computer centre
charges for the usage of computer resources such as disk storage and
printing, then the cost should be estimated.

(iii) Training cost


If the computer personnel and the end-users have to be trained, then
the training courses may incur some expenses.

(iv) Other expenses


Cost of new computer equipment, software, paper and other supplies
also need to be considered.

(b) Operating costs


The operating costs, on the other hand, tend to recur throughout the
lifetime of the system. The costs of operating a system over its useful
lifetime can be classified as:

(i) Fixed operating costs


Examples of the fixed operating costs are lease payments, software
license payments, pro-rated salaries of IS operators and so on.

(ii) Variable operating costs


Examples of the variable operating costs are CPU time used, terminal
connect time, pre-printed forms, floppy disks, payment to part-time
workers, maintenance and repair charges, telephone and electricity
charges and so on.

Copyright © Open University Malaysia (OUM)


TOPIC 2 PROJECT SELECTION  37

A typical costing for an information system project can have the following
format, as shown in Table 2.2.

Table 2.2: Costing for IS Project

DEVELOPMENT COSTS ANNUAL OPERATING COSTS


1. Personnel cost 1. Personnel cost
2. Computer usage 2. Hardware maintenance
3. Training cost 3. Software licenses
4. Other expenses 4. Other expenses
TOTAL Development Costs TOTAL annual operating costs

2.4.2 What is Benefit?


Benefits are factors that normally increase the profit figures or decrease the costs.
Both are considered very highly desirable outcomes of a new IT project. As far as
possible, they should be quantified in dollars and cents.

Benefits can be classified into the following two categories:

(a) Tangible benefits


Tangible benefits are benefits that can be easily quantified. They are usually
measured in terms of monthly or annual saving, or of profit in the form in
dollars and cents. Alternatively, they might also be measured in terms of
unit cost savings or other non-monetary benefits, such as fewer processing
errors, increase in throughput, decrease in response time, eliminations of
job steps, reduction of expenses, increase in sales, better credit control and
reduction of credit losses.

(b) Intangible benefits


Intangible benefits are benefits that are difficult or impossible to quantify.
Examples of intangible benefits are such as like improved customer
goodwill, improved employee morale, better service to community and
better decision making process. Sometimes, intangible benefits involve an
analysis of economic benefits and risks ă although they are not quantifiable,
they may override decisions made based on numerical benefits. These are
facts like:
(i) Its contribution to the corporate (or strategic) goals;
(ii) Its results in giving a competitive advantage in the marketplace; and
(iii) The cost of not having the proposed new system.

Copyright © Open University Malaysia (OUM)


38  TOPIC 2 PROJECT SELECTION

The project selection models discussed in section 2.3 make use of tangible and
intangible benefits. Tangible benefits can be used in the numeric selection
models, while intangible benefits are applied in the non-numeric selection
models. The numeric models are easier to see as they come with numbers, while
the non-numeric models come without numbers. Only those in senior
management positions are in a better position to understand the importance and
the value of the non-numeric models. Thus, there are occasions when the non-
numerical benefits override the numerical benefits.

SELF-CHECK 2.3

1. Explain the term cost-benefit analysis.


2. Give the advantages of cost-benefit analysis techniques.
3. What do you understand by the terms „tangible‰ and „intangible‰
benefits?

2.5 THE PAYBACK METHOD


The payback method to be described here is the detailed illustration of the
„payback analysis‰ mentioned in section 2.3.2 ă i.e. one of the numeric selection
models. Do you know what payback period is? Now let us look at the definition.

The payback period for a project is the initial fixed investment in the
project divided by the estimated annual net cash inflows from the project.
The ratio of these quantities is the number of years required for the project to
repay its initial fixed investment.

The payback method is very simple. It measures the number of years it is


expected to take to recover the cost of the original investment on the project. It is
calculated by estimating the annual cash flow from the commencement of the
project to the end of its useful life. The cash flow would be negative initially, but
within a year or two from the start of many projects, positive cash flow will be
observed.

The following are two examples that discuss the payback method further.

Example 1
The management of a company set a maximum period of three years within
which any investment must be paid back. They are proposing to invest
Copyright © Open University Malaysia (OUM)
TOPIC 2 PROJECT SELECTION  39

RM200,000 in automated factory equipment to save labour of RM50,000 per year.


The equipment is expected to have a useful life of six years. Calculation of the
payback period is done as shown in Table 2.3.

Table 2.3: Calculation for a Payback Period

Year Annual Cash Flow (RM) Cumulative Cash Flow (RM)


0 ă 200,000 ă 200,000
1 + 50,000 ă 150,000
2 + 50,000 ă 100,000
3 + 50,000 ă 50,000
4 + 50,000 0 (payback completed)
5 + 50,000 + 50,000
6 + 50,000 + 150,000

Based on Table 2.3, the given example is found to have a payback period of four
years. This is then compared with the three-year criterion set by the
management. As such, it would result in this investment being rejected. The
apparent simplicity of this method explains its appeal and why companies find it
quite an attractive method.

Example 2
The same manufacturing company has RM180,000 to invest and is trying to
choose between one project which returns RM50,000 each year for six years, and
another project which returns RM60,000 each year but only for four years. The
company still requires a payback within three years. Comparison of the two
projects by the payback method is done as shown in Table 2.4.

Table 2.4: Comparison of Two Projects by Payback Method

Year PROJECT A PROJECT B


Annual Cash Cumulative Cash Annual Cash Cumulative Cash
Flow (RM) Flow (RM) Flow (RM) Flow (RM)
0 – 180,000 – 180,000 – 180,000 – 180,000
1 + 50,000 – 130,000 + 60,000 – 120,000
2 + 50,000 – 80,000 + 60,000 – 60,000
3 + 50,000 – 30,000 + 60,000 0
4 + 50,000 + 20,000 + 60,000 + 60,000
5 + 50,000 + 70,000 – + 60,000
6 + 50,000 + 120,000 – + 60,000
Payback period of 3.6 years Payback period of 3 years
Copyright © Open University Malaysia (OUM)
40  TOPIC 2 PROJECT SELECTION

Based on the figures in Table 2.4, if the firm relies solely on the quickness of
payback, then, Project B would be selected. This shows one of the weaknesses of
the payback method. Although payback is completed more quickly on Project B
at three years, this is very close to the end of its four-year life. Project A, on the
other hand, goes on for two further years. Therefore, one serious disadvantage of
this method is that any cash received after the completion of the payback period
is totally ignored, and this is not reasonable.

Another disadvantage of this method is that no attempt is made to relate the cash
earned on the investment to the amount actually invested. Table 2.4 shows that
Project A (with a cumulative cash flow of RM120,000) is certainly more profitable
than Project B (with RM60,000) when looking at its total life. Therefore, the
payback method does not attempt to measure this total profitability over the
whole life of the investment. Despite these weaknesses, the payback method is
still being adopted either as an indicator of risk or where a quick cash flow is of
paramount importance.

2.6 NET PRESENT VALUE METHOD


Net present value (NPV) method has been mentioned in section 2.3.2 ă i.e. one of
the numeric selection models. Detailed illustration of the method is to be given
here. Net present value (NPV) is theoretically the correct technique for assessing
investments on IS/IT projects. Managers in the industry can use this discounting
approach to assess the profitability of their investments. The expected cash flows
on the proposed project are set out year by year, and brought to the present value
(PV) by the use of PV factors at an appropriate rate.

Positive PVs are netted off against deficit PVs to arrive at the net present value
(NPV). When this net figure is positive, then a scheme is said to be viable because
the stream of inflows is sufficient to pay the interest at the specified rate. On the
contrary, when the NPV is negative, then the proposed project is not financially
viable.

The following is an example that discusses the net present value method further.

Example
Directors of the same manufacturing company are now considering an
investment of RM150,000 in a website to promote and sell an industrial product.
Profits, before charging any depreciation, are expected to be RM60,000 in each of
the first four years, falling to RM40,000 in year five, and only RM20,000 in year
six.

Copyright © Open University Malaysia (OUM)


TOPIC 2 PROJECT SELECTION  41

After this, the website will be scrapped with no significant recovery value
involved. The company has a cost of capital of 20%, which is used to evaluate all
their investments in IT. The cash flows can be set out and multiplied by the PV
factors at 20% to demonstrate whether this project meets the 20% required rate of
return as calculated in Table 2.5.

Table 2.5: Calculation of NPV at 20% Factor

Year Annual Cash Flow (RM) PV Factors at 20% Present Value (RM)
0 ă 150,000 1.000 ă 150,000
1 + 60,000 0.833 + 49,980
2 + 60,000 0.694 + 41,640
3 + 60,000 0.579 + 34,740
4 + 60,000 0.482 + 28,920
5 + 40,000 0.402 + 16,080
6 + 20,000 0.335 + 6,700
Total: + 28,060

The NPV surplus of RM28,060 means that the forecasted rate of return is more
than the 20% rate of interest used. This is because the annual cash inflows are big
enough to allow for more interest to be deducted, and the investment could still
repay the original investment.

2.7 INTERNAL RATE OF RETURN


The internal rate of return (IRR) of an investment or a project is the discount rate
at which the net present value of costs (i.e. the negative cash flows) of the
investment equals the net present value of the benefits (i.e. the positive cash
flows) of the investment. IRR is sometimes referred to as „economic rate of return
(ERR)‰. The IRR makes use of the cost-benefit analysis, and is somewhat an
alternative method to the Payback or the NPV method. Thus, IRR can be
considered as another numeric selection model.

IRR calculations are commonly used to evaluate the viability of investments or


projects. The higher a project's IRR, the more viable the project. If all projects
require the same amount of up-front money, then the project with the highest
IRR would be the best to start first.

Theoretically, a company can take up all projects with IRRs that exceed the cost
of capital. However, since an investment may be limited by the availability of

Copyright © Open University Malaysia (OUM)


42  TOPIC 2 PROJECT SELECTION

funds, and the companyÊs ability to manage projects, an investment is considered


acceptable if its IRR is greater. The higher a project's IRR, the more viable. As
such, IRR can be used to rank several prospective projects that a company is
considering. The project with the highest IRR would probably be undertaken
first.

The formula is given as follows:

PV of future cash flows î Initial Investment = 0; or


CF1 CF2 CF3
+ + + ... î Initial Investment = 0
( 1 + r )1 ( 1 + r )2 ( 1 + r )3

Where,
(a) r is the internal rate of return;
(b) CF1 is the period one net cash inflow;
(c) CF2 is the period two net cash inflow; and
(d) CF3 is the period three net cash inflow.

If an investment may be given by the following sequence of cash flows:

Year Cash flow


0 –123400 (cash outflow)
1 +36200 (cash inflow)
2 +54800 (cash inflow)
3 +48100 (cash inflow)

Then the IRR r is given by:

36200 54800 48100


NPV  123400    0
1  r  1  r  1  r 
1 2 3

In this case, the answer is 5.96% (in the calculation, that is, r = 0.0596).

Copyright © Open University Malaysia (OUM)


TOPIC 2 PROJECT SELECTION  43

ACTIVITY 2.2

How could a large supermarket chain use information systems for cost
reduction? Discuss in a group.

2.8 FEASIBILITY VS. BUSINESS CASE


A feasibility study is normally carried out after the problem identification stage,
and before the system analysis stage of systems development life cycle (SDLC).
In such a study, the system analyst investigates to find out whether such a
project would be feasible in terms of the technical, financial and operational
aspects. A good feasibility report helps to clarify a lot of things on the feasibility
of the proposed IS/IT project. This report provides a useful input to the
preparation of a business case ă this is required before a project is selected for
going ahead.

Thus, you can say that a feasibility report is the result of an initial investigation,
while a business case is the final report before a project officially takes off.
Different terms are actually used by different parties, at different stages of project
activities, with overlapping content and objectives, to mean almost the same
thing. If you are a project manager or a system analyst, just produce whatever
report that has been requested.

A business case explains, in business terms, why a certain project is to be carried


out. It states the business benefits that are expected to flow from the project,
together with the costs of the project. The business case should describe how a
project will support business strategy. In justifying for the need of a project, you
normally have to provide a numeric analysis of the cost and benefits. Otherwise,
you have to provide the intangible benefits which may come from the non-
numeric aspect of the justification process. These have been covered in detail
earlier.

The format of a business case varies widely between organisations. Some like to
have multi-volume documents, with all the facts and figures carefully recorded,
while others prefer a simple one-page format.

Copyright © Open University Malaysia (OUM)


44  TOPIC 2 PROJECT SELECTION

One simple structure of a business case is outlined in the following (Carroll,


2012):

Purpose of the document


The purpose of this report is to document the justification for understanding a
project based on the estimated cost and the anticipated business benefits to be
gained. The project sponsor will monitor the ongoing viability of the project
against this business case.

Reasons
The project will support business strategy by introducing a new product that
uses and encourages ⁄ It is also expected to produce a positive revenue stream
once established (give the reasons pertaining to your project).

Benefits
Based on initial projections, the product is forecasted to achieve sales of ⁄ and
a gross profit of ⁄ in the first full year of operation (if your benefits are largely
intangible and non-numeric, then present you case here).

Benefit realisation
There will be no benefits during the development year (year 0). Benefits will be
realised with ⁄ per annum from year 1 onwards.

Cost and time scale


The one-off project costs will be ⁄ all in year 0, while the annual operating
costs will be ⁄ from year 1 onwards (the project time-scale too needs to be
clearly stated and updated).

Investment appraisal
In the following table, a discounted cash flow is calculated at ⁄ per annum
(present the table mentioned, however, if you use another method or
technique, then describe it hear).

The previous example is just an outline business case. It is normally based on a


best guess for the costs and benefits. The full business case should be reviewed
continuously. New factors and information about the project and the business
case will continue to come to light throughout the project. So, we need to review
the business case at regular intervals. This can be done through the stage-by-
stage review process. During each of these reviews, the project sponsor and other
stakeholders are given the opportunity to feel satisfied with the project being run
by the project manager. The business case needs to be updated based on the
actual costs-to-date, plus the estimated costs to complete it (Carroll, 2012).

Copyright © Open University Malaysia (OUM)


TOPIC 2 PROJECT SELECTION  45

Thus, the format for a business case is different from that of a feasibility report.
Since the business case is being used and updated regularly throughout the
project, from initiation until termination ă again, this is different from the
feasibility report which is produced and presented only once. Further, a
feasibility report covers not just the financial aspect, but also the technical and
the operational aspects of the proposed project. A business case focuses mainly
on the cost aspect, and the expected business benefits.
SELF-CHECK 2.4
SELF-CHECK 2.4

1. Differentiate a feasibility report and a business case.


2. At what point in the project life cycle should the business case be
prepared?

2.9 PROJECT RISK EVALUATION


Every project involves risk of some form. When assessing and planning a project,
we are concerned with the risk of the project not meeting its objectives. In any
project evaluation, there should be an attempt to identify the risks and quantify
their potential effects.

A sophisticated approach to the evaluation of project risk is to consider each


possible outcome and estimate the probability of its occurring and the
corresponding value of the outcome. The value of the project can be obtained by
summing the cost or benefit for each possible outcome weighted by its
corresponding probability of occurring. Details of the project risk management
will be covered in Topic 6. But, it is important to mention here that evaluation of
the project risk is part of the selection process.

Projects that are likely to face very high risks should be avoided at all costs. An
example of such a high-risk project was the construction of a bridge linking
Sumatra (Indonesia) and Malacca (Malaysia) before the currency turmoil that hit
South East Asia in 1997-98. Had a bank loan been taken in US Dollars before the
turmoil, the construction company would have had to pay so much money in
local currencies after the turmoil. In the process, the company could have become
a bankrupt. Another example of a risky project is the development of a software
product that is inferior to a competitorÊs product.

Copyright © Open University Malaysia (OUM)


46  TOPIC 2 PROJECT SELECTION

ACTIVITY 2.3

Which method would you use to evaluate the viability of the following
tasks?
(a) Developing a computerised toll collection system at the PLUS
highway; and
(b) Constructing the entire PLUS highway to be used for 30 years.

SELF-CHECK 2.5

1. What is the meaning of project risk? Give two examples.


2. Identify the major risks that could affect the success of your
proposed project.

 Projects play important roles in achieving the organisationÊs goals and


strategies.

 Projects are capital investments. They must be selected based on cost and the
expected benefits to be gained.

 Project selection models can generally be classified as either numeric or non-


numeric model.

 The tangible benefits can be quantified using the numeric selection models,
while the intangible benefits are applied in the non-numeric selection models.

 A business case explains, in business terms, why a certain project is to be


carried out. It describes how a project will support business strategy.

 Evaluation of the project risk is part of the selection process. Projects that are
likely to face very high risks should be avoided at all costs.

Copyright © Open University Malaysia (OUM)


TOPIC 2 PROJECT SELECTION  47

Business case Payback analysis


Competitive necessity Portfolio management
Cost-benefit analysis Programme management
Internal rate of return (IRR) Project portfolio
Net present value (NPV) Return on investment (ROI)
Operating necessity Sacred cow

Cadle, J., & Yeates, D. (2008). Project management for information systems (5th
ed.). Harlow, England: Pearson Prentice Hall.
Carroll, J. (2012). Effective project management in easy steps. Southam, England:
In Easy Steps.
Hoffer, J. A., George, J. F., & Valacich, J. S. (1999). Modern system analysis and
design. Reading, MA: Addison-Wesley.
Kendall, G. I., & Rollins, S. C. (2003). Advanced project portfolio management
and the PMO: Multiplying ROI at warp speed. Conyers, GA: J. Ross.

Copyright © Open University Malaysia (OUM)


Topic  Project
3 Initiation

LEARNING OUTCOMES

By the end of this topic, you should be able to:


1. Define project charter;
2. Describe the terms of reference for a project;
3. Explain the importance of project scope and project objectives;
4. State the criteria for a successful project; and
5. Describe how to launch a new project.

 INTRODUCTION
Project initiation is the first phase that starts a project by establishing a need for
the product, facility or service. It starts with producing a project charter which
briefly defines the project to be undertaken. The charter is a very concise but
official document to be signed by the sponsor. This can be expanded into a more
detailed document, usually called the project definition form.

Project initiation requires the project manager to revisit his/her roles and
responsibilities. It includes defining the scope and objectives of the project
together with the preparation of an outline plan. Many activities are required to
achieve the project objectives. This phase of the project life cycle identifies the
tasks which can be transformed into a logic diagram.

This topic discusses the definition of success. The project manager and the team
must understand what is meant by success before trying to achieve it towards
the end. The topic finally ends with a discussion on project launching which
signifies that the project has officially started. In short, project initiation covers all

Copyright © Open University Malaysia (OUM)


TOPIC 3 PROJECT INITIATION  49

the activities prior to project planning which will be discussed further in the next
topic.

3.1 PROJECT DEFINITION


How do you define a particular project? One positive way is to prepare a charter
for each project at the starting point. What is a project charter?

A project charter is a concise written description of the projectÊs intended


work.

According to Harvard Business Review (2012), the charter may contain the name
of the sponsor, the projectÊs benefits to the organisation, a description of the
objectives, the expected time frame and a budget. Indeed, every project should
have a charter that spells out the nature and scope of the work and
managementÊs expectations for results. Creating a project charter would force
senior managers to clearly articulate what the project should do.

A charter is a concise written document containing some or all of the following


(HBR, 2012):
(a) Name of the projectÊs sponsor;
(b) ProjectÊs benefits to the organisation;
(c) Brief description of the objectives;
(d) Expected time frame;
(e) Budget and resources available;
(f) Project managerÊs authority; and
(g) SponsorÊs signature.

Despite being just a brief document, a project charter is a formal document since
it carries the signature of the sponsor. However, if you find that the charter is
too brief, then you can define and expand the document into a more detailed
form by producing a project definition form. This doesnÊt carry a signature of
the sponsor.

As mentioned earlier, it is normal that different terms are being used by different
authors and practitioners, at different stages of the project activities. They may
have similar content and objectives, and they may describe almost the same
thing. Some authors mention about a project charter, while others mention about

Copyright © Open University Malaysia (OUM)


50  TOPIC 3 PROJECT INITIATION

a project definition form. They are meant for different purposes, and targeting at
different audiences.

It is good to document in greater detail at the start of a new project using a


project definition form. This document could be as small as a one-page form or
as large as a ten-page typed document. In either case, it should include the
following items and sections:
(a) Name of the company or organisation;
(b) Departments or other organisational units requesting the project;
(c) The individuals or persons who originated the request for the project;
(d) Date of the project definition being drafted;
(e) Project sponsor who will fund the project;
(f) Title of the project;
(g) Goal of the project;
(h) Priority in terms of quality, cost and time ă ranked as 1, 2 and 3;
(i) Terms of reference;
(j) Business deadline being the completion dates;
(k) Assumptions made in the project; and
(l) Budget for the project.

Figure 3.1 shows an example of a one-page project definition form.

Figure 3.1: Example of a Project Definition Form


Source: McLeod and Smith (1996)
Copyright © Open University Malaysia (OUM)
TOPIC 3 PROJECT INITIATION  51

In project management, whether it is called a project charter, or a project


definition form, or a project statement, it documents a statement of the scope,
objectives and participants in a project. It aims to provide a preliminary
description of the roles and responsibilities of the main stakeholders, the project
manager and so on. It serves as a reference of authority for the future of the
project.

ACTIVITY 3.1
To start any project, project initiation is crucial because during this
period, we establish the scope and the objectives of the project. Think of
the consequences if we fail to define and distinguish the scope and
objectives of a project. Discuss.

3.2 ROLES AND RESPONSIBILITIES


If you are the project manager, then this is the right time for you to verify from
the feasibility report and other documents, the scope of the project to be
undertaken. The project manager must also know the terms of reference for the
project.

The „Terms of Reference‰ is like a simplified contract between two parties ă i.e.
between the project manager and the client organisation. Thus, you need to:
(a) Know the roles of a project manager;
(b) Identify the project sponsor and his roles;
(c) Identify the executive accountable for the project;
(d) Know your job description; and
(e) Know your authority and accountability.

As a project manager, you also need to review your roles and responsibilities.
The following list serves as a guide only. You need to:
(a) Establish clear project objectives, approved by the key stakeholders;
(b) Prepare all project plans, approved by the key stakeholders;
(c) Agree on the approval procedures with the stakeholders;
(d) Establish a control system and measurement criteria;
(e) Produce status reports regularly;
(f) Establish and review the project budget;
Copyright © Open University Malaysia (OUM)
52  TOPIC 3 PROJECT INITIATION

(g) Resolve all conflicts; and


(h) Deliver expected outcomes at each stage, on time and within budget.

During the project initiation phase, you must identify your core team members
so that you can get them involved in the actual planning of the project (refer to
Figure 3.2).

Figure 3.2: Core team members are important in a project


Source: http://www.slingshotvoip.com/hosted-pbx/team-members/

Without the core team members getting involved from the very beginning, you
may face problems during the execution phase later. You should hold inaugural
meetings to wake them up and to give a warm up to these important people.

Your project team may be made up of the following people:


(a) Yourself only (for a very small project);
(b) Yourself plus representatives from other functional departments;
(c) Yourself plus part-time members;
(d) Yourself plus full-time members; or
(e) A combination of the above.

During this phase too, you must identify the key stakeholders. Stakeholders are
people whom you and your team believe have great interest in the project. You
need to handle them properly as they can make or break a project. Stakeholders
include people who are certainly (or likely to be) affected by the project.

Copyright © Open University Malaysia (OUM)


TOPIC 3 PROJECT INITIATION  53

Examples of the stakeholders are:


(a) The customers;
(b) The project sponsor;
(c) The executive accountable for the project;
(d) The consultants who prepared the feasibility report;
(e) The functional line managers who provide resources and data input;
(f) The suppliers of services, raw materials and equipment; and
(g) Sometimes, even the community.

Of course, you need to identify and focus only on the key stakeholders. But, you
must be aware that other stakeholders too can become important at times.

SELF-CHECK 3.1

1. Explain the term „project charter‰.


2. What do you understand by the „terms of reference‰ for a project?

3.3 PROJECT SCOPE AND OBJECTIVES


Have you heard of the term „project scope‰ before this? Now, let us look at the
definition of this term.

Project scope is basically a definition of the end results of the project.

The primary purpose of a project scope is to define as clearly as possible the


deliverables for the end users, and that enables you to focus on the project plan.
After defining the project scope, you can then focus on the project objectives. The
following is the definition of project objectives.

Project objectives describe the things to be achieved in a project and the ways
to achieve them successfully. Objectives should be clearly defined so as to
guide and motivate the project team. Objectives form the basis for dealing
with risks and future decisions.

Copyright © Open University Malaysia (OUM)


54  TOPIC 3 PROJECT INITIATION

Defining the project scope and the objectives sets the stage for developing a
project plan. Many projects fail because the objectives are not clear. Having poor
objectives is a symptom of weak management which does not have a clear sense
of direction. Objectives can actually be derived from discussions with the project
sponsor, customers, other key stakeholders and team members.

The scope should be developed under the direction of the project manager and
customer. The project manager is responsible for seeing that there is agreement
with the owner on project objectives, deliverables at each stage of the project,
technical requirements and so forth. Examples of deliverables are:
(a) In the early stage, it could be the functional specifications;
(b) In the second stage, it could be three prototypes for production;
(c) In the third stage, it could be a sufficient quantity to introduce to the
market; and
(d) Finally, it could be marketing, promotion and training.

Preparing a project specification list helps to narrow down the scope of work. An
example of the specification list includes:
(a) Hardware requirement;
(b) Software requirement;
(c) Special equipment, materials, etc.;
(d) What will not be done;
(e) Project methodology, strategies, etc.;
(f) Project status reporting;
(g) Project monitoring and tracking;
(h) Project time sheet recording;
(i) Control system; and
(j) Early warning system.

It is good to issue a complete set of the specifications list in a bound copy to all
team members and the key stakeholders, so that they are aware of them and they
can propose changes if they do not agree. Issuing such documents regularly will
enable you to refer to them, later, if things go wrong on the way.

Copyright © Open University Malaysia (OUM)


TOPIC 3 PROJECT INITIATION  55

SELF-CHECK 3.2

Define the „scope‰ of a project.

3.4 PROJECT SCOPE CHECKLIST


Scope describes what you expect to deliver to your customer when the project is
completed. It should define the results to be achieved in specific, tangible and
measurable terms. To ensure that the project scope is complete, the checklist
given in Table 3.1 can be used.

Table 3.1: Project Scope Checklist

Project Scope Descriptions


Project  The first step is to define major objectives to meet customerÊs
objectives needs.
 Project objectives answer the questions of what, when and how
much.
 For example, a computer software company decides to develop
a program that automatically translates verbal sentences in
English to French. The project should be completed within two
years, starting from 1st June, at a cost not exceeding RM1
million.
Deliverables  The next step is to define major deliverables of the project.
 Deliverables typically include time, quantity and cost estimates.
 For example, deliverables in the early design phase of a project
might be a list of specifications. In the second phase, deliverables
could be software coding and a technical manual. The next
phase could be to test prototypes. The final phase could be final
tests and approved software. Dates must be specified.
Milestones  A milestone is a significant event in a project that occurs at a
point in time. Similar to the milestones on the road, it shows a
distance that has been covered, and how much more to go.
 Milestones should be natural, important control points in the
project. They should be easy for all project participants to
recognise.
 The milestone schedule is built using the deliverables as a
platform to identify major segments of work and an end date.
 For example, testing completed and finished by November 1 of
the same year ă this can be set as one milestone.

Copyright © Open University Malaysia (OUM)


56  TOPIC 3 PROJECT INITIATION

Limits and  A product or service normally has technical requirements to


exclusions ensure proper performance.
 For example, a technical requirement for a personal computer
might be the ability to accept 120-volt alternating current or 240-
volt direct current without any adapters or user switches.
Examples from IS/IT projects include speed and capacity of
database systems and connectivity with alternative systems.

Source: Jagesh et al. (2009)

The checklist in Table 3.1 is generic. Many companies engaged in contracted


works refer to the scope statements as the statement of work (SOW).

Statement of work (SOW) is a document prepared for the customer during


project initiation and planning that describes what the project will deliver and
outlines generally at a high level all work required to complete the project
(Hoffer et al., 1999).

Other organisations use the term project charter ă but as defined earlier, a project
charter has a different structure with a different meaning.

ACTIVITY 3.2

Limits and exclusions are part of the project scope. They are important
as the client knows about limits and exclusions of a project.
Sometimes it takes a long time in negotiating limits and exclusions.
What is your opinion on shortening the negotiation time and to ensure
a win-win situation between parties involved in a project? Can your
idea be used for other project scopes, such as project objectives,
deliverables and milestones?

SELF-CHECK 3.3
1. What is project deliverable? Give one example.
2. Explain the term „project milestone‰.
3. What does „statement of work‰ mean?
4. What is the difference between limitation and scope?

Copyright © Open University Malaysia (OUM)


TOPIC 3 PROJECT INITIATION  57

3.5 QUALITY, PRIORITY AND EXPECTATIONS


Quality finished products and the ultimate success of a project are now defined
as meeting and exceeding the expectations of customers. Traditionally, quality
was tied into some relative terms such as less error, shorter program codes,
having a longer life-time and so forth. However, now qualities are tied to
customer satisfaction and acceptance.

Figure 3.3 discusses the two types of customers and their descriptions.

Figure 3.3: Two types of customers

The interrelationship among criteria varies. For example, sometimes it is


necessary to compromise the performance and scope of the project to get the
project done quickly or less expensively. Often the longer a project takes, the
more expensive it becomes. However, it may not always be true that there is a
positive correlation between cost and schedule. Sometimes, the cost can be
reduced by using cheaper and lower quality raw materials.

One of the primary jobs of a project manager is to manage the trade-offs among
time, cost and performance. Project managers must clearly define and
understand the nature of the priorities of the project. They need to have a candid
discussion with the customer and the senior management to establish the
relative importance of each criterion.

Copyright © Open University Malaysia (OUM)


58  TOPIC 3 PROJECT INITIATION

Priorities vary from one project to another. For example, for many software
projects, time to market is critical. For example, Microsoft may defer its original
scope requirements to later versions in order to get to the market first. This is
MicrosoftÊs strategy in its product development. The company wants to engage
customers early before they start to taste other products. Any improvement or
additions can always be done later once the target customers have been captured.
Meanwhile, the software can be given a temporary version, called „Beta
Version‰, showing that further testing will be carried out. Customers would be
getting the clean version after it has been fully tested.

You must remember that some key stakeholders may change midway through
the project ă due to resignation, promotions and so on. In such a case, you will
have to go through the process of clarifying the new stakeholderÊs expectations.
You cannot assume that their expectations are the same as the earlier
stakeholders. The new stakeholders might see the job and the product
differently. Thus you must update them and bring their thinking into line with
reality.

3.6 IDENTIFYING PROJECT TASKS


It is important to identify the tasks involved in the project during the project
initiation phase. These tasks will provide the base for preparing a proper project
plan to be discussed in details in the next topic. Project tasks can be identified
through a brainstorming technique which can be conducted together with all the
members of the core project team. These tasks can be clustered together closely
for all the related tasks. This helps to identify key stages of the project.

Using the core project team members, you can then develop a complete
picture of the projectÊs logic diagram out of the key stages and activities
identified. This will map into the following sequence: Activity-1, Activity-2,
Activity-3, until the last activity. The logic diagram is the foundation of the
project. The arrows show the flow of activities.

You can later insert the (tentative) duration for each activity, and prepare a
dependency list as shown in Table 3.2.

Copyright © Open University Malaysia (OUM)


TOPIC 3 PROJECT INITIATION  59

Table 3.2: Examples of Logic Diagram Components

Code Description Duration (Weeks) Dependency


A Activity-1 5 Nil
B Activity-2 1 A
C Activity-3 9 B
D Activity-4 7 A, B
E Others ă ă

This completes the basic outline plan, which overlaps with the initiation phase of
the project life cycle. Outline planning is a warm up to the real planning to
give a structure to the detailed plan. The next stage will be the detailed plan,
called the project planning phase, to be covered in Topic 4. This will consist of the
development of key stages and activities inside the Work Breakdown Structure
(WBS).

3.7 DEFINITION OF SUCCESS


Discussion about the project success should begin early so that you will get
prepared for it as early as possible. The project manager and the team members
should know what to achieve in order to be a success. So, how do you define a
successful project?

Simply, a successful project is the project that delivers to the customer


everything that has been specified, to the quality that has been agreed, on
time and within a specified budget.

But how often is this achieved? One widely known survey was done by the
Standish Group in US. They classify projects under three heading: successful,
challenged and impaired.

The following are a brief description of the three headings.


(a) Successful projects were those that met the definition stated above;
(b) Challenged projects were those where the project was completed and
became operational but cost more, or overran on time and delivered less
functionality; and
(c) Impaired projects were cancelled during the development stages.

Copyright © Open University Malaysia (OUM)


60  TOPIC 3 PROJECT INITIATION

Overall, only 16% were deemed to be successful, 53% were challenged, and 31%
were impaired. If one were to present this in a positive light, however, people
could say that 69% of projects were successful.

The Standish survey report does not pretend to know all the answers, but it does
offer a success potential chart citing user involvement, top management support
and a clear statement of requirements as the three most important factors for
success. It also says that:

„Smaller time frames, with delivery of software components early and often,
will increase the success rate. Shorter time frames result in an iterative
process of design, prototype, develop, test, and deploy small elements. This
process is known as „growing‰ software, as opposed to the old concept of
„developing‰ software. Growing software engages the user earlier, each
component has an owner or set of owners, and expectations are realistically
set. In addition, each software component has a clear and precise statement
and set of objectives. Software components and small projects tend to be less
complex. Making the projects simpler is a worthwhile endeavour because
complexity causes only confusion and increased cost‰ (as cited in Cadle &
Yeates, 2008).

Lewis (2011) produced another set of statistics from the Standish Group which
was collected in 1994. The results were classified as follows: 17% succeeded, 50%
revised and 33% failed. This is not much different from the other results
produced by Cadle and Yeates (2008). Lewis argued that the success rate has not
increased that significantly even after more than 10 years of time difference.
What seems to have changed is that companies now cancel losing projects sooner
than they did in 1994. They have learnt to recognise early which projects are
going to fail.

There is an older definition of success which is not much different from the above
really. McLeod and Smith (1996) defined a project success as the one that can
satisfy all the following three criteria:
(a) It meets requirements ă In terms of the functionality, reliability,
maintainability, portability, efficiency, integration and operability;
(b) It is delivered on time; and
(c) It is delivered within budget.

By following this definition of success, they concluded that only less than 20% of
the IT projects were successful. The IT industry during their times were guilty of

Copyright © Open University Malaysia (OUM)


TOPIC 3 PROJECT INITIATION  61

meeting only the requirements criterion, and even that was only partially. Horror
stories were told that projects were running at several hundred percent over
budget, and took twice as long as anticipated. All these prove that the IT industry
needs a much more disciplined project management.

Lewis (2011) also agreed that, in general, a project would be considered a success
if you can meet the following criteria listed in Figure 3.4.

Figure 3.4: Four criteria for a successful project

These are the standard criteria in the minds of the project team members,
especially the technical people. However, it should be stressed that there are
projects that meet all these targets, but are considered as failures; while there are
those that do not meet any of these targets, but are considered successful. These
do happen in real life, especially when the project has been outsourced
(contracted out) to another party. Customers and other key stakeholders could
change their minds slightly, and the project manager should try to get approval
when the time is right.

To overcome issues of this kind, then the project manager needs to clarify the
requirements by having stakeholders state their expectations, understand what
the results must be, and then determine what the deliverables must be to fulfil
those expectations.

Hence, the only truly successful project is the one that:


(a) Delivers what it is supposed to;
(b) Gets the results; and
(c) Meets stakeholdersÊ expectations.

This last point (stakeholdersÊ expectations) is often part of the politics in project
management. As the key stakeholder expectations may change slightly from time
to time, the final endorsement of the key decision-maker is often the most
important. You must handle this person very carefully and very well.

Copyright © Open University Malaysia (OUM)


62  TOPIC 3 PROJECT INITIATION

3.8 PROJECT LAUNCHING


With your project team being formed, your charter delivered, and the teamÊs
tasks scheduled, you still have a few critical matters to take care of before the
project work commences. Firstly, you need to launch the project by having a
special event that marks its official beginning. The launch represents the very
first project milestone. If conducted properly, it has a substantial symbolic value
ă especially if the project is of a medium or large size. It is great to include a
group dinner in addition to the meeting.

Physical presence at this meeting has great psychological significance,


particularly for the geographically dispersed teams whose members may have
difficulty to come together on a face-to-face basis. Here is the agenda for this
meeting of project launching (HBR, 2012):
(a) Welcome everyone aboard ă Acknowledge and thank all those who will
contribute to the project. Mention each person by name. Some are core team
members, while others are peripheral members, but all are members.
(b) Ask your sponsor to say a few words ă A project sponsor has the
opportunity to articulate why the project is important, and how its
objectives are aligned to the larger organisational goals.
(c) Make introductions ă If the group is not too large, ask the members to
introduce themselves to tell about their background, expertise areas and
what they hope to achieve in this new project.
(d) Share the charter ă Briefly illustrate the project charter officially. Explain
the project goals, the deliverables and the timetables that you have
documented.
(e) Seek consensus ă Ask questions to confirm that every member understands
what the project charter means. Get everyone to agree on the charter.
(f) Describe the resources available ă It is quite important, even at this very
beginning, to set realistic expectations about the amount of support you
will get from the budget, the team members and the senior management.
(g) Describe incentives ă Explain what the members will receive beyond their
normal compensation, if the team meets or exceeds its goals. Explain
incentives for the group as well as for the individual members, if any.

Copyright © Open University Malaysia (OUM)


TOPIC 3 PROJECT INITIATION  63

SELF-CHECK 3.4

1. Explain the term „logic diagram‰.


2. Name four criteria that can make a project successful.
3. Describe briefly how to launch a large new project.

ACTIVITY 3.3

Look into the development of a payroll system and state the following
details.
(a) Define the project scope clearly; and
(b) Identify a few project milestones.

Ć A project charter is a concise written description of the projectÊs intended


work. It is a formal document which carries the signature of the sponsor.

Ć The „Terms of Reference‰ is like a simplified contract between two parties ă


i.e. between the project manager and the client organisation.

Ć Project scope tells about the things to be done and not to be done. It is what
the project is supposed to achieve. A project specification list helps to narrow
down the scope of work.

Ć Project objectives describe the things to be achieved in a project and the ways
to achieve them successfully. Objectives should be clearly defined so as to
guide and motivate the project team.

Ć Project team members must discuss together to identify the project tasks.
These tasks can be transformed into a logic diagram that tentatively
represents the entire project.

Ć A successful project is the project that delivers to the customer everything


that has been specified, to the quality that has been agreed, on time and
within a specified budget.

Copyright © Open University Malaysia (OUM)


64  TOPIC 3 PROJECT INITIATION

Ć In general, a project would be considered a success if you can meet the


following criteria:
 Performance Requirements (P);
 Cost (C);
 Time (T); and
 Scope (S).

Ć Project launching practically and officially starts the project. It involves the
following agenda:
 Welcome everyone onboard;
 Ask your sponsor to say a few words;
 Make introductions;
 Share the charter;
 Seek consensus;
 Describe the resources available; and
 Describe incentives.

Logic diagram Project objectives


Project charter Project scope
Project definition form Project specification list
Project milestone Statement of work

Cadle, J., & Yeates, D. (2008). Project management for information systems (5th
ed.). Harlow, England: Pearson Prentice Hall.
Harvard Business Review (HBR). (2012). HBR Guide to project management.
Boston, MA: Harvard Business School Publishing Corporation.

Copyright © Open University Malaysia (OUM)


TOPIC 3 PROJECT INITIATION  65

Hoffer, J. A., George, J. F., & Valacich, J. S. (1999). Modern system analysis and
design. Reading, MA: Addison-Wesley.
Jagesh, N., Rahim, Y. A., Bakar, N. S. A. A., & Awang, M.Z. (2009). CBPM4103 ă
Information technology project management (2nd ed.). Kuala Lumpur: Open
University of Malaysia.
Lewis, J. P. (2011). Project planning, scheduling & control: The ultimate hands-on
guide to bringing projects in on time and on budget (5th ed.). New York, NY:
McGraw-Hill Professional.
McLeod, G., & Smith, D. (1996). Managing information technology projects.
Danvers, MA: Thomson.

Copyright © Open University Malaysia (OUM)


Topic  Project
4 Planning

LEARNING OUTCOMES

By the end of this topic, you should be able to:


1. Define the scope of a project;
2. Identify functional, quality and resource requirements of a project;
3. List activities involved in a project;
4. Develop an activity plan;
5. Construct a work breakdown structure including the work packages;
and
6. Identify the project milestones.

 INTRODUCTION
This topic introduces important steps and issues in planning for an IT project.
The topic describes what constitutes the scope, objectives and requirements
specifications of a project. During the planning stage, all the team members of the
project should understand their work and targets.

Many activities are required to achieve the objectives of a project. This topic
presents a clear description of the project activities. The activities described for a
project should be carried out in the right order. The activity plan explains the list
of activities and their order to be accomplished.

This topic also describes the meaning, design, and uses of the work breakdown
structure. The section on risk management is also part of the project plan, but
will be discussed in details under Topic 6. It is very important to prepare an
initial plan to take note of the possible risks facing the project, as well as the ways
Copyright © Open University Malaysia (OUM)
TOPIC 4 PROJECT PLANNING  67

to mitigate them. Finally, the topic ends with planning to set the milestones, plus
an idea on how to handle software prototypes.

4.1 PLANNING OVERVIEW


In an earlier topic, we have discussed outline planning being part of the project
initiation phase. This topic will therefore be concerned with detailed planning
being a continuation of outline planning. The entire planning process results in a
document called the „project plan‰. The plan provides a clearer picture of the
project to the customers, the project team members and other key stakeholders.

What is „planning‰? Well, planning is to answer the following questions:


(a) What must be done?
(b) How long will it take?
(c) Who will do it?
(d) How should it be done?
(e) How good does it have to be?
(f) How much will it cost?

Planning can be done briefly or in great detail. Actually, a more detailed plan
would simplify implementation and reduce its problems. Let us take on the
question of who is to do what. This leads to the following list of questions:
(a) Who manages progress?
(b) Who must be consulted?
(c) Who must be informed?
(d) Who is available?
(e) Who is to be referred to?

A project can be broken down into activities that can satisfy various functional
and non-functional requirements. Each activity takes a time duration, which is to
be combined with other activity durations to complete the entire project life
cycle. Project team members and other stakeholders would perform and realise
most of the activities.

The project team would adopt a certain method and approach to ensure proper
execution of the project works. The methodology is to be supported by human
resources, hardware, software, techniques and tools. To be acceptable to the
users and the key stakeholders, various stages of the project need to be
Copyright © Open University Malaysia (OUM)
68  TOPIC 4 PROJECT PLANNING

effectively controlled to ensure quality of the finished product. Finally, a project


is accompanied by an accurate budget, which must be set aside by the project
sponsor.

4.2 RULES IN PROJECT PLANNING


According to Lewis (2011), the first rule of planning is that „the people who
must do the work should participate in the planning‰. Core members of the
project team can see better what is forthcoming, as they are the ones on the job.
Their participation reinforces commitment and provides collective responsibility
along with the project manager.

The following case example shows how important is participation by the


implementers (in addition to the core team members) in any preparation for a
plan.

CASE EXAMPLE
This example illustrates a case of $600,000 error in a building construction
project. A project manager took over a project that was already in progress ă
the construction of a new wing of a hospital. The former project manager had
left to take a new job. As he examined the plans for the project, the new
project manager felt uneasy. Something seemed wrong, but he couldnÊt find
what it was. He told his boss and got the same response, „Stay with it until
you find whatÊs wrong‰, said his boss.

A few days later, he found the problem ă they were already doing site
preparation, with large earth-moving equipment, and it was nowhere in
the plan. When he did an estimate, the site work alone was almost $600,000
on a job targeted originally to be around $2,000,000. Imagine having to tell the
board of directors (BOD) of the hospital that they needed another $600,000 to
complete the project.

It is the omission of work that causes many projects to go over-budget and


miss their deadlines. This often happens when the project manager plans the job
all by himself, thereby, violating one of the cardinal rules of planning t hat
the people who must implement a plan should participate in preparing it.
(Lewis, 1993)

The second rule of planning is that you must be prepared to re-plan. There is no
plan that is really perfect. Changes to the original plan should be made only
when a significant deviation occurs. A significant change will usually be

Copyright © Open University Malaysia (OUM)


TOPIC 4 PROJECT PLANNING  69

specified in terms of percent tolerances relative to the original targets. Causes of


changes should be documented for reference in planning future projects.

4.3 STEPS IN PROJECT PLANNING


Many people take planning for granted as something they have known. Often,
they do not really plan, but rather simply keep things in their mind. If they do
plan, they take a shortcut route and skip many important steps. The result would
be misses and surprises which can develop into what some people term as
„ghosts‰. These ghosts would later come back to haunt them in the form of
serious repair works and corrections.

Thus, proper steps need to be done in the project planning phase as listed below:
(a) Define the problem based on customerÊs requirements;
(b) Develop statements of major objectives;
(c) Develop a project strategy: the waterfall model, prototyping and so on;
(d) Define project boundaries: what will and will not be done;
(e) Develop a work breakdown structure (WBS);
(f) Using WBS, estimate activity duration, resource requirements and costs;
(g) Prepare the project master schedule and the budget;
(h) Decide on the project organisation structure;
(i) Set-up the project notebook; and
(j) Get the plan signed off by all the stakeholders.

IT projects can be simplified as follows:


(a) One project should focus on one system only;
(b) One large project should be broken down into several sub-projects;
(c) One sub-project should focus on one subsystem only;
(d) A hierarchy of sub-projects can be executed sequentially or in parallel;
(e) Each subsystem then has its own life cycle;
(f) Each sub-project then has its own process model; and
(g) In this way, system developers can supply a series of deliverables quite
frequently, thereby assuring the users and stakeholders of getting
improved functionality each time.

Copyright © Open University Malaysia (OUM)


70  TOPIC 4 PROJECT PLANNING

ACTIVITY 4.1

„Failing to plan is planning to fail‰. The importance of planning is


stressed out in this brief but meaningful phrase. Do you really think
that planning is important? Why?

4.4 PROJECT SCOPE AND OBJECTIVES


Scope is often referred to as a functional specification. Actually, it is even more
than that. The scope of a project is a statement that defines the boundaries of the
project. It tells not only what will be done but also what will not be done. The
scope of a project is best achieved by defining the principal deliverables from the
project.

In order to avoid confusion, misunderstanding and argument later, it is


important to also define anything that is not going to be included in the project.
For example, a patient booking system project may include analysing, designing,
building and implementing the software, but not supposed to install the
infrastructure on which it will run.

The scope defines the project objectives in great details in terms of what is to be
included and excluded in the project. The scope of work, consisting of clientsÊ
needs and expectations, is to be adequately defined to ensure the project success.
After initiation of the project, scope would be defined and verified. Changes in
scope are to be controlled properly from time to time during the life of the project
because they may affect the time-frame and the budget.

Project objectives describe the things to be achieved in a project and the ways to
achieve them successfully. Objectives should be clearly defined so as to guide
and motivate the project team. Objectives form a basis for dealing with risk and
future decisions. Headington (2013) advises that when you are setting objectives,
they should be specific, measurable, achievable, realistic and time-bounded
(SMART).

4.5 REQUIREMENTS SPECIFICATION


The starting point for a good project plan is a proper understanding of the
requirements ă i.e. what is it exactly that the project is supposed to achieve. If an
IS/IT project is to be successful, then all the concerned parties must know in
detail what they are trying to do. In an ideal world, the project would start
with a requirements specification of some sort.

Copyright © Open University Malaysia (OUM)


TOPIC 4 PROJECT PLANNING  71

The objectives of a project are carefully defined in terms of the functional


requirements, quality requirements and resource requirements. Refer to Table 4.1
for the details.

Table 4.1: Requirements Specifications

Types of
Explanation
Requirements
Functional  These define the functions of the end product of the project.
Requirements Systems analysis and design methods are designed
primarily to provide functional requirements.
 Examples of the functional requirements are ă the system
should be able to display records, accept credit card
payments and print receipts.
Quality  The quality requirements relate to what the application
Requirements system is supposed to do in order to implement other
attributes of the application.
 Examples of the quality requirements are ă the system
should have a response time of not exceeding 5 seconds;
should operate 24 hours per day and 7 days per week and so
forth.
Resource  These requirements give a clear record of how much the
Requirements organisation is willing to spend on the system. There may be
trade-offs between the cost and the time it takes to
implement the system. There may also be a trade-off
between the functional and quality requirements and the
cost.
 Examples of the resource requirements are ă the system
should utilise the existing computer server, disks, terminals
and the budget should not exceed RM1 million.

Different authors classify requirements differently. Classifying requirements


according to the ones in Table 4.1 is one of the ways. However, all these
requirements must be consistent with the business case.

Copyright © Open University Malaysia (OUM)


72  TOPIC 4 PROJECT PLANNING

Figure 4.1: Types of requirements

SELF-CHECK 4.1

1. Define „scope‰ in a project.


2. Explain the three major requirements of an IS/IT project.
3. Differentiate functional and non-functional requirements.

4.6 PROJECT AND ACTIVITIES


We have always come across the word „project‰, but do we really know its
definition?

A project is composed of a number of interrelated activities.

A project may start when at least one of its activities is ready to start. A project
will be completed when all of the activities it encompasses have been completed.
All the activities that are required to be completed in the project must be
precisely coordinated and done. Now, what is an activity?

An activity may be defined as any task, job or operation which must be


performed to complete the work package and the project.

Copyright © Open University Malaysia (OUM)


TOPIC 4 PROJECT PLANNING  73

An activity must have a clearly defined start-point and a clearly defined end-
point, normally marked by the production of a tangible deliverable. If an activity
requires a resource, then that resource requirement must be forecasted and is
assumed to be required at a constant level throughout the duration of the activity.
The duration of an activity must be forecasted by assuming normal
circumstances, and the reasonable availability of resources. Some activities might
require that others be completed before they can begin.

4.7 ACTIVITY PLAN


An activity plan or action plan describes the list of activities that need to be
carried out and the order in which they appear. An ideal activity plan is one in
which each activity would ideally be undertaken when resources are not a
constraint. The activity plan provides a targeted start and completion date for
each activity which produces some tangible product or deliverable.

The activity plan enables one to:


(a) Ensure that appropriate resources will be available precisely when
required;
(b) Avoid different activities competing for the same resources at the same
time;
(c) Produce a detailed schedule showing which staff member carries out each
activity;
(d) Produce a detailed plan against which actual achievement may be
measured;
(e) Produce a timed cash-flow forecast; and
(f) Re-plan the project during its life to correct drift from the target.

As a project progresses, it is unlikely that everything will go according to plan.


Much of the job of project management has to deal with something going wrong,
identifying the causes, and revising the plan to mitigate the effects. An activity
plan should provide a means of evaluating the activities and their target dates,
together with a guideline on how to bring the project back on target. An example
of an activity plan is shown in Figure 4.2.

Copyright © Open University Malaysia (OUM)


74  TOPIC 4 PROJECT PLANNING

Figure 4.2: Example of a simple activity plan


Source: Jagesh et al. (2009)

ACTIVITY 4.2

After understanding the interrelation between a project and an activity,


can you figure out a sample of an Activity Plan for an office networking
and cabling structure project? Make a list out of the activities that
should occur and other elements that should be accounted for, then plan
accordingly.

SELF-CHECK 4.2

1. What is the difference between a project and an activity?


2. Explain the following term: Activity plan.

4.8 WORK BREAKDOWN STRUCTURE (WBS)


Once the scope and deliverables have been identified, the work of the project can
be successively subdivided into smaller work elements. The outcome of this
hierarchical process is called the work breakdown structure (WBS).

WBS is the result of breaking the work down into smaller elements, thus
providing a greater probability that every major and minor activity will be
accounted for. WBS involves identifying the main (or high-level) tasks required
to complete a project and then breaking each of these down into a set of lower
level tasks. In planning a project, the project manager must structure the work

Copyright © Open University Malaysia (OUM)


TOPIC 4 PROJECT PLANNING  75

into small elements that are manageable, independent, integrate-able and


measurable.

The use of WBS helps to assure project managers that all products and work
elements are identified, and to establish a basis for controls. Basically, WBS is an
outline of the project with different levels of details. WBS starts when the
statement of work (SOW) is completely defined. There should be agreement
between the final SOW and WBS.

WBS is hierarchically structured in accordance with the way the work will be
performed as shown in Figure 4.3.

Figure 4.3: Work breakdown structure


Source: Jagesh et al. (2009)

The WBS reflects the way in which project costs and data will be summarised
and eventually reported. WBS is a communication tool, providing detailed
information to different levels of management. It can be used to provide the basis
for:
(a) Responsibility matrix;
(b) Network scheduling;
(c) Costing;
(d) Risk analysis;
(e) Organisational structure; and
(f) Coordination of objectives and control.
Copyright © Open University Malaysia (OUM)
76  TOPIC 4 PROJECT PLANNING

WBS can take a wide variety of forms that, in turn, serve a wide variety of
purposes. It often appears as an outline with the Level 1 on the left and
successive levels appropriately indented. WBS may also be a picture subdivided
into hierarchical units of tasks, subtasks and work packages. Most current project
management software will generate a WBS on command.

4.8.1 Examples of WBS


WBS provides a tool for planning project activities, including estimates of
resource requirements, activity duration and costs. It should be developed before
scheduling and resource allocation is done, and it is made by people who fully
understand the work involved.

Basically, WBS breaks down a project only to a level sufficient to produce an


estimate of the required accuracy. This tool can be used to estimate resources,
time and labour cost.

Some examples of WBS used for different purposes are given below.

(a) Example 1
Figure 4.4 shows an example of WBS with three levels on „Software for a
Loan System‰.

Figure 4.4: WBS for a software for a loan system

Copyright © Open University Malaysia (OUM)


TOPIC 4 PROJECT PLANNING  77

(b) Example 2
Figure 4.5 shows an example of WBS for „Writing a Computer Book‰.

Figure 4.5: WBS for writing a computer book

(c) Example 3
WBS with six levels is made up of project, sub-project, task, sub-task, work
package and activity (level of effort). An example of WBS with six (6) levels
is given in Figure 4.6.

Figure 4.6: WBS for completing a compiler project

Copyright © Open University Malaysia (OUM)


78  TOPIC 4 PROJECT PLANNING

4.8.2 Uses of WBS


When you have completed drafting the WBS, you can then use this diagram as
the basis for making decisions on who is to do what on the project. You can also
expand the amount of details by including the name of the resource assigned to
each activity. For that, you can even include the start and finish times and dates.

The major benefit of using WBS is that you are not likely to miss important
details that are necessary to be parts of the project. It is also a very convenient
diagram that is easy even for people who are not involved in the project to
understand. Indeed, it is the foundation of all planning at more than one level.

WBS is very useful in project planning because it contains all the component
parts of a project. Drawing WBS can avoid misses and shortcuts. It leads to the
preparation of the work schedule in the form of Gantt chart or network analysis
diagram.

The WBS has four main uses: as a thought process tool, an architectural tool, a
planning tool and a project status reporting tool. Table 4.2 describes the four uses
of WBS.

Table 4.2: Four Uses of WBS

Uses of WBS Explanation


Thought process tool WBS is useful to visualise exactly how the project work can
be defined and managed effectively.
Architectural design tool WBS is a picture of the project work and it gives a picture of
how the items of work are related to one another.
Planning tool WBS gives the project team a detailed representation of the
project as a collection of activities that must be completed
in order to complete the project. E.g., estimating effort,
elapsed time, resource requirements and building schedule.
Project status reporting WBS is used as a structure for reporting the project status.
tool The project activities are consolidated from the bottom as
lower-level activities are completed. WBS defines milestone
events that can be reported to senior management and to
the customer.

Source: Jagesh et al. (2009)

Copyright © Open University Malaysia (OUM)


TOPIC 4 PROJECT PLANNING  79

SELF-CHECK 4.3

Define and discuss the main uses of the WBS.

4.9 WORK PACKAGE ESTIMATES


A work package details the breakdown of tasks, time-utilisation, labour cost and
the total costs. This helps to prepare a budget that is more accurate than the one
prepared earlier. In the beginning, the budget was very briefly and crudely
calculated. Therefore, the work package estimate is a more refined version which
needs to be further endorsed by the steering committee.

The following Table 4.3 shows a work package estimate for „Develop
Illustrations for a Book” based on Figure 4.5.

Table 4.3: Work Package for „Develop Illustrations for a Book‰

Task Time Labour Rate Total Cost


Pull clipart 24 hours RM10 per hour RM240.00
Computer art 40 hours RM15 per hour RM600.00
Past-ups 100 hours RM10 per hour RM1,000.00
Type for art 10 hours RM10 per hour RM100.00
Make stats. 20 hours RM12 per hour RM240.00
Work Package Cost RM2,180.00

Table 4.4 shows a work package estimate for part of the „Compiler Project‰
based on Figure 4.6.

Table 4.4: Work Package for „Compiler Project‰

Task Time Labour Rate Total Cost


Coding module 1 4 man-months RM4000/ mm RM16,000
Coding module 2 6 man-months RM4000/ mm RM24,000
Coding module 3 2 man-months RM5000/ mm RM10,000
Integrating M-123 2 man-months RM8000/ mm RM16,000
Documentation 1 man-month RM6000/ mm RM 6,000
Work Package Cost RM72,000

Copyright © Open University Malaysia (OUM)


80  TOPIC 4 PROJECT PLANNING

4.10 SETTING THE MILESTONES


An IT equivalent of the milestone is needed in IT projects, so that you can feel the
distance you have already travelled and the distance you still need to go on. This
needs to be planned too. Therefore, you need to design several work units, the
completion of which can be tested.

Project milestones are things like:


(a) Elements of specification, e.g. input and output documents;
(b) Units of programs, e.g. program modules;
(c) Elements of system designs, e.g. menu sequence;
(d) Elements of output, e.g. error messages;
(e) Prototype ready for testing; and
(f) Writing of manuals and so on.

The test of completion for each work unit (i.e. after completing it) designed to be
a project milestone is therefore required. Then, for each milestone you need to get
it signed-off by the customer on things like documents, memos and output
messages. It is very good to establish a schedule of the milestones early to ensure
that these are acceptable to the key stakeholders and the project team. This
document allows you to keep everyone in the picture about the project objectives
and how you want them to be achieved through intermediate deadlines that you
have frozen into milestones. Statement of the project milestones is illustrated in
Figure 4.7.

Copyright © Open University Malaysia (OUM)


TOPIC 4 PROJECT PLANNING  81

Figure 4.7: Statement of the project milestones

Project milestones have the start date, and the finish date. Using WBS, you can
decide the most important key stages and assign their completion milestone
status. Various parts of the project plan, including the risk management plan (to
be discussed in Topic 6), are then scrutinised by the group and combined into a
composite project plan.

ACTIVITY 4.3

Based on what you have studied, try applying them to complete the
following tasks:
(a) Write a scope to develop an SMI website;
(b) Prepare an activity plan for a simple package; and
(c) Draw the work breakdown structure for the administration of a
college.

Copyright © Open University Malaysia (OUM)


82  TOPIC 4 PROJECT PLANNING

4.11 HANDLING SOFTWARE PROTOTYPES:


THE PROTOTYPING MODEL
This subtopic is relevant only for software development projects. As explained
earlier, software projects must be treated differently from other projects, or even
from other IT projects. Hence, if you are managing other types of project, you can
simply skip this section of the topic. The main differences between software
projects and other projects have already been discussed earlier too. A simple
software development model, called the life cycle model, was also introduced in
Topic 1. If your software development customer does not agree to follow the
waterfall model, then you must consider the prototyping model. This is trickier,
and will be discussed in the following.

Prototyping is now a common approach in developing many hardware products


like toys, house-hold items, buildings or even cars. Once the hardware prototype
is satisfied and approved, specifications can be finalised, and manufacturing can
then proceed. That can prevent a lot of costly mistakes of the final products being
wrong. In the case of computer software, similarly, system development process
can proceed once the software prototype is satisfied and approved. Thus, users
would find it more acceptable in this way, and the finished application would
face very little chance of rejection by the user.

A prototype is a small working model of the overall system, from which users
can work and suggest modifications. In the IT environment, there can be many
prototypes simulating various corners of the overall system. As soon as the
management feels confident of the prototype, it can then be expanded gradually,
or the real software development can then proceed to completion. This approach
is therefore more relevant to the software component rather than to the entire IT
project as a whole.

Pressman (2001) gives some examples of the situations whereby prototyping is


the best approach. He says „Often, a customer defines a set of general objectives
for software but does not identify detailed input, processing, or output
requirements. In other cases, the developer may be unsure of the efficiency
of an algorithm, the adaptability of an operating system, or the form that
human/machine interaction should take. In these, and many other situations, a
prototyping paradigm may offer the best approach.‰

To illustrate an idea of prototyping, Pressman (2001) gives a very simple flow


diagram (with some adaptations here) as shown in Figure 4.8. Iterations can take
place many times until the customer feels satisfied.

Copyright © Open University Malaysia (OUM)


TOPIC 4 PROJECT PLANNING  83

Figure 4.8: The prototyping model

Prototyping has been made possible with the presence of rapid development
tools. Speed can be overcome by using materials such as databases, 4GLs, very
high-level languages, PCs, screen generators, expert system shells and others.
Examples of the 4GL tools are Dbase 4, Visual Basic and MS Access. Using these
and other tools, a prototype could be quickly developed and modified later, as
required.

Prototypes can also be used to enhance the life cycle model. This is one way to
overcome the rigidities of that model. With prototyping being inserted inside, the
revised lifecycle model would have more strengths and advantages.

SELF-CHECK 4.4

What makes software prototyping approach different?

Ć Scope, activity plan and work breakdown structure play important roles in
planning a project.

Ć The scope document tells about the things to be done and not to be done, as
well as requirement specifications and goals of the project.

Ć The three main requirements of an IS/IT project are functional requirement,


quality requirement and resource requirement.

Copyright © Open University Malaysia (OUM)


84  TOPIC 4 PROJECT PLANNING

Ć Functional requirements consist of requirements that deal with the system


functions while non-functional requirements deal with every other aspect of
the system (i.e. other than its functions).

Ć The team members must understand the objectives of the project and develop
team spirit to achieve them.

Ć A project is composed of many activities; and the activities should be


properly planned to ensure optimal performance.

Ć An activity plan or action plan describes the list of activities that need to be
carried out and the order in which they appear.

Ć The project work should be properly divided into smaller works that are
manageable, independent, integrate-able and measurable.

Ć The project plan should also include risk management plan to manage risks
that encounter the project from time to time.

Ć WBS is the result of breaking the work down into smaller elements, thus
providing a greater probability that every major and minor activity will be
accounted for.

Ć Software projects need to be treated differently from other projects. If the


client organisation is willing to accept the waterfall approach to software
development, then it will be like any other project.

Ć However, if it is likely going to be the prototyping approach, the steps are


going to be trickier. This involves a number of iterations in the process, which
needs to be incorporated into the Project Plan.

Functional requirement Quality requirement


Milestone Resource requirement
Non-functional requirement Work breakdown structure (WBS)
Prototyping approach Work package

Copyright © Open University Malaysia (OUM)


TOPIC 4 PROJECT PLANNING  85

Headington, R. (2013). Monitoring, assessment, recording, reporting and


accountability: Meeting the standards. London, England: David Fulton.
Lewis, J. P. (1993). The project managerÊs desk reference: A comprehensive guide
to project planning, scheduling, evaluation, control & systems. Chicago, IL:
Probus.
Lewis, J. P. (2011). Project planning, scheduling & control: The ultimate hands-on
guide to bringing projects in on time and on budget (5th ed.). New York, NY:
McGraw-Hill Professional.
Pressman, R. S. (2001). Software engineering: A practitionerÊs approach. Boston,
MA: McGraw-Hill.

Copyright © Open University Malaysia (OUM)


Topic  Software
5 Project
Estimates
LEARNING OUTCOMES
By the end of this topic, you should be able to:
1. List the different techniques of estimating software products;
2. State the right technique for different types of software products;
3. Apply software estimation using the mathematical equation;
4. Describe basic, intermediate and advanced COCOMO;
5. Explain the function point analysis (FPA) method; and
6. Identify major differences between COCOMO and FPA.

 INTRODUCTION
Software development projects are distinctly different from other projects. The
reasons for this have been elaborated in Topic 1. Thus, planning and controlling
of a software project need to incorporate an accurate estimation based on the
nature of software. Inaccurate estimation can cause budget overruns and
surprises. In other projects, doubling manpower on the job would reduce the
time taken by half. However, in software projects, the outcome is not necessarily
so, because a lot of communication is required between software engineers. As
such, manpower and the time taken are not linearly related.

There are several techniques commonly used to estimate software development


effort more accurately. This topic will review these techniques, but towards the
end, will focus in details on the constructive cost model (COCOMO) and the

Copyright © Open University Malaysia (OUM)


TOPIC 5 SOFTWARE PROJECT ESTIMATES  87

Function Point (FP) analysis. Other techniques will also be touched together with
their advantages and disadvantages.

5.1 SOFTWARE ESTIMATES AND BENEFITS


Have you heard of software estimates before this? Let us look at its definition.

Software estimates include estimates of effort, costs, time frame and


staffing needs (i.e. the number of persons). Effort is the total time duration
that one person needs to complete a task. Time frame is the total time
duration planned to complete the task.

Estimates for software development projects should have units of measurement.


For example, effort is measured in person-hours, person-weeks, person-months
and so on. This translates into dollars and cents.

Further, estimation is an iterative process which would become more accurate


with further refinements. For every prominent change made to the scope,
necessary modifications will have to be carried out on the parameters like effort,
cost, time-frame, staffing needs and so on.

5.1.1 Stages of Estimates


Estimates are carried out at various stages in the software project life cycle. At
each stage, the reasons for doing the estimate are slightly different. Important
stages and some kind of estimates done are shown in Table 5.1.

Table 5.1: Important Stages of Estimates

Stages of Estimates Explanation


Strategic Planning The costs and benefits of computerising potential applications
are estimated to illustrate priority to be given to each project.
This also helps in deciding the number of people to be recruited
for each project.
Feasibility Study Feasibility study should ascertain that the benefits of the
proposed system would justify the costs.
System Specification The effort needed to implement different design proposals will
need to be estimated. Estimates at the design stage will also
confirm that the feasibility study is still valid.

Copyright © Open University Malaysia (OUM)


88  TOPIC 5 SOFTWARE PROJECT ESTIMATES

Evaluation of Staff evaluating tender proposals (or bids) would scrutinise the
SupplierÊs Proposals system specifications and produce cost estimates.
Project Planning As planning and implementation of a project progresses to
greater levels of detail, more detailed estimates of smaller work
elements will be made.

Source: Jagesh et al. (2009)

5.1.2 Overestimation and Underestimation


An overestimate might cause the project to take longer than it would otherwise.
This can be explained by the application of two laws, originally specified for
software projects, but the principles really apply to all kinds of projects too.
Figure 5.1 describes the application of two laws.

Figure 5.1: Application of two laws

An underestimate might cause the project to take a shorter time than a more
generous estimate. The danger with underestimation is the effect on quality. Less
experienced staff might respond to the pressing deadlines by producing
substandard work. Underestimates may lead to artificial reduction of staff by
their managers. This results in increased pressure on the staff working on the
project.

5.1.3 Software Estimation Process


Software estimation is a continual process that should be used throughout the
project life cycle. The process of estimating the software size, cost and schedule
begins with the definition of the functional requirements of the project. Two or
more people should be involved to develop the estimates. Project managers
Copyright © Open University Malaysia (OUM)
TOPIC 5 SOFTWARE PROJECT ESTIMATES  89

should never rely on any one person or method to develop software estimates.
Generally, the software estimation process consists of at least five procedures as
shown in Table 5.3.

Table 5.2: Procedures in Software Estimation Process

Procedures Explanation
Estimate size Software product size is generally measured in Source Lines Of Code
(SLOC). WBS, and either SLOC or function points may be used to
estimate software product size. The software should be developed
using all new code or from combining new code with the existing
code. The estimation for the adaptation of existing code is as important
as the estimate for new code and sometimes requires as much effort as
if new code had been developed. Estimates of software product size
should be based primarily on historical data, if available, and past
experience.
Estimate cost The key input to this stage is size estimate for the project. The estimate
and effort should include all labour activities charged directly to the task. These
activities include labour charges for different tasks in the project. An
estimate of cost should be be developed early in the project life cycle,
as soon as software requirements are defined. Cost is usually
estimated in effort or person days/weeks, which can then be
translated into cost-based labour rates. For example, the cost of 20-
month project life cycle at 17.8 person-days per month based on a rate
of RM200 per person-day is equal to RM71, 200.
Estimate The purpose of a schedule estimate is to determine the length of time
schedule needed to complete the project and when major milestones and
reviews will occur. Before this process, the functional WBS, size and
cost estimates must be completed. The schedule estimate can be
produced manually or by using an automated estimation model or
both.
Inspect and The purpose of this stage is to improve the quality of the estimates
approve produced and obtain senior management commitment. The objectives
estimate of this stage include confirmation of the software architecture and
functional WBS, verification of the estimation methods used, ensuring
the correctness of the assumptions and input data used to develop the
estimates for deriving the size, schedule and cost estimates, and finally
confirming and recording formally the official estimates for the project.
Track estimates The purpose of this stage is to check the accuracy of the estimate over
time and to develop some empirical data over time. Estimates should
be tracked over time by comparing planned to actual outcomes. This
allows the project personnel to see just how the project is shaping up
and how accurate their planning were.

Source: Jagesh et al. (2009)


Copyright © Open University Malaysia (OUM)
90  TOPIC 5 SOFTWARE PROJECT ESTIMATES

5.1.4 Basis for Software Estimation


There are three important bases for software estimation. Table 5.3 below shows
the bases for software estimation.

Table 5.3: Basis for Software Estimation

Basis Explanation
The need for Most of the estimating methods need information on how
historical data projects have been implemented in the past. This needs judging
the applicability of data to the estimatorÊs own circumstances
because of possible differences in project environmental factors
such as the programming languages used, the software tools
available, the standards enforced and the experience of the staff.
Measure of work The time taken to write a program may vary according to the
competence or experience of the programmer. Implementation
times may also vary because of project environmental factors.
The usual practice is to express the work content of the system to
be implemented independently of effort, using a measure such
as SLOC. In the case of using tables or diagrams, other different
measures of size, such as function points are needed.
Complexity Two programs with the same SLOC or KLOC (also known as
thousands lines of code) will not necessarily take the same time
to write, even if done by the same developer in the same
environment. One program might be more complex. The
complexity of the work should be measured to arrive at
reasonable estimates.

Source: Jagesh et al. (2009)

SELF-CHECK 5.1

1. State the different stages when software estimates are to be done.


2. List the problems being faced by underestimates and
overestimates.
3. What is ParkinsonÊs Law?
4. Explain the following term: SLOC.

Copyright © Open University Malaysia (OUM)


TOPIC 5 SOFTWARE PROJECT ESTIMATES  91

5.2 VARIOUS ESTIMATION TECHNIQUES


This subtopic will discuss several estimation techniques for software
development. Figure 5.2 lists ten main estimation techniques used for software
development.

Figure 5.2: Estimation techniques for software development

Now we will look into the details of all estimation techniques except for two; the
constructive cost model and function point analysis. These two techniques will
be discussed in greater detail in the following subtopics.

The details of the remaining eight estimation techniques are as follows:

(a) Bottom-up estimation


In the bottom-up approach, the estimator breaks the project into its
component tasks and sub-tasks, and then estimates the effort required to
carry out each sub-task leading to task. The total of tasks makes up the
project. This approach is most appropriate when a project is completely
novel, or when there is no historical data involved.

(b) Top-down estimation


This is an overall estimate for the project. It is normally derived from
global properties of the software product. This estimate will usually be
based on previous projects and will include the costs of all the functions in

Copyright © Open University Malaysia (OUM)


92  TOPIC 5 SOFTWARE PROJECT ESTIMATES

a project, such as costs of integration, document, software quality


assurance, configuration management and so on.

(c) Expert Judgment


This method relies on one or more people who are considered experts in
some endeavour related to the problem ă e.g. the application area or the
development environment. This method is perhaps the most widely used
method of manual estimation.

(d) Estimating by Analogy


This method is one of the oldest and most reliable of the methods. It
compares the proposed project to some completed projects of a similar
nature whose costs are known.

The similarity should ideally extend to the:


(i) Type of business involved;
(ii) Overall size of the applications;
(iii) General scope of the systems; and
(iv) Technical methods, standards and languages used.

Where there are differences in any of these areas, suitable adjustments are
made. This method needs historical data. The more data available, the
more accurate the estimates will be. A major advantage of the analogy
method is that it enables a broad-brush estimate for a whole project to be
developed fairly quickly.

(e) Analysis Effort Method


This method is most suited to produce the initial estimates for a project
before detailed analysis has begun. The general idea is to estimate the
effort required to perform the analysis work for an assumed number of
software functions and then to derive the estimates for subsequent
programming stages using ratios to the analysis effort.

(f) Programming Method


This method starts from a different point from the analysis effort method,
namely that of examining the initial programming effort required and
deriving values for the rest of the programming tasks. The simplest way to
assess the programs is to decide if each is likely to be small, medium or
large. The estimator then uses metrics from other projects or his own
experience to establish an effort figure for the remaining stages of the
project.

Copyright © Open University Malaysia (OUM)


TOPIC 5 SOFTWARE PROJECT ESTIMATES  93

(g) Three-point Technique


This method uses the following three estimates for time duration:
(i) Optimistic time (O): This is the shortest time in which the activity
could be completed, barring outright miracles.
(ii) Pessimistic time (P): This is the worst possible time allowing for all
reasonable eventualities.
(iii) Most likely time (M): This is the time usually experienced under
normal circumstances.

Using the above three estimates, the expected time (Te) for an activity is
calculated using the following formula:

Te = (O + 4M + P) / 6

(h) Delphi Technique


This method is based on the idea of obtaining estimates from suitably
qualified people and then synthesising them to produce the final estimate.
Since people have differing levels of experience in estimation, as well as
knowledge of the underlying hardware and software to be used, the
approach has a number of stages:
(i) Each estimator is given a specification of the work (activity, task and
so on) and asked to provide his/her estimate for it;
(ii) The estimates are then summarised anonymously, and the summary
is circulated to each estimator; and
(iii) Estimators reconsider their own estimates in the light of the
summary and provide a revised estimate if they wish.

The above processes are repeated as many times as necessary to achieve a


reasonable consensus. The Delphi technique is a group approach.

SELF-CHECK 5.2
1. List out at least five estimation techniques used for software
development.
2. Explain the following term: Three-point technique.
3. Describe any of the other three estimation techniques in brief.

Copyright © Open University Malaysia (OUM)


94  TOPIC 5 SOFTWARE PROJECT ESTIMATES

5.3 CONSTRUCTIVE COST MODEL (COCOMO)


The COCOMO method was developed by Dr Barry Boehm. It is the best-known
software-costing model. This method comes with three levels of complexity,
called the:
(a) Basic COCOMO;
(b) Intermediate COCOMO; and
(c) Advanced COCOMO.

It computes software development effort and cost as a function of program size


expressed in estimated lines of code. The more complex COCOMO adds in a set
of „cost drivers‰ into the basic one; while the most complex COCOMO further
adds an assessment of the cost driverÊs impact on each step of analysis, design
and so on in the project life cycle.

5.3.1 The Basic COCOMO


This is a static single valued model. It calculates software development effort and
cost as a function of program size expressed in the form of estimated lines of
code. Mathematical equations used are of the form:

Effort (E) = a  (size)k ⁄⁄ units are in pm (person-month)

Where, 1 pm = 152 working hours (19 days  8 hours per day).


Size is measured in thousands of delivered source code instructions (kdsi),
expressed in KLOC (thousand lines of code).

Development Time (D) = b  (Effort)c ⁄⁄ units are in m (months)

Number of Personnel (N) = E ÁD = Effort  Development Time

Here, a, b, k and c are constants whose values depend on the technical nature of
the project system and the development environment. Three classes of software
project systems are defined in Table 5.4.

Copyright © Open University Malaysia (OUM)


TOPIC 5 SOFTWARE PROJECT ESTIMATES  95

Table 5.4: Classes of Software Project Systems

Semi-Detached Mode
Organic Mode Projects Embedded Mode Projects
Projects
These systems are These systems are These systems are
characterised by: characterised by: characterised by:
 Small project size;  Intermediate size and  Tight hardware;
 Low complexity; complexity;  Software and
 Small team size;  Mixed experience in operational constraints;
team, only some  High software
 Familiar application familiar parts of
type in familiar validation costs;
project; and
environment; and  Rigid constraints; and
 Some rigid
 Non-rigid requirements.  Often little experience
requirements. in application area.
For these systems: For these systems: For these systems:
a = 2.4, k = 1.05, a = 3.0, k = 1.12, a = 3.6, k = 1.20,
b = 2.5, and c = 0.38. b = 2.5, and c = 0.35. b = 2.5, and c = 0.32.

Now, let us look at an example of calculations done using the formula provided.

EXAMPLE:
Estimate the number of persons required to do an organic mode software
project with an estimated size of 35,000 deliverable lines of code.
Effort (E) = a  (size)k = 2.4  (35)1.05 = 100 person-months.
Development Time (D) = b  (Effort)c = 2.5  (100)0.38 = 14 months.
Then, Number of Personnel (N) = E  D = 100  14 = 7 people.

5.3.2 Intermediate COCOMO


In addition to project size of the basic COCOMO, the intermediate COCOMO
considers other factors which affect the resources required in a project. The
factors include resource estimates.

In this intermediate model, there are 15 cost drivers which are grouped into four
major categories, namely:
(a) Product attributes (three cost drivers);
(b) Computer or hardware attributes (four cost drivers);

Copyright © Open University Malaysia (OUM)


96  TOPIC 5 SOFTWARE PROJECT ESTIMATES

(c) Project attributes (three cost drivers); and


(d) Personnel attributes (five cost drivers).

The value for each cost driver is again categorised into six, namely:
(a) Very low;
(b) Low;
(c) Nominal;
(d) High;
(e) Very high; and
(f) Extra high.

The values for the cost drivers are multiplied together to obtain an effort
adjustment factor (EAF). The typical range of values of EAF is from 0.9 to 1.4. The
mathematical equation for effort is as follows:

Effort (E) = c1  (size)c2  EAF

The values of the two constants (c1 and c2) are different for the three different
mode projects of the Basic COCOMO.

5.3.3 Advanced COCOMO or COCOMO II


This model considers different factors, which apply during different stages of a
system development and produces more detailed estimates on a phase-by- phase
basis. That is, the model allows for estimates to be made for subsystems, and the
estimates can then be combined for the total project estimates. The model was
undergoing refinement continuously. The approach uses various multipliers and
exponents, the values of which have been set initially by experts.

COCOMO II is actually a hierarchy of estimation models that address application


composition model, early design stage model and post-architecture-stage model.
These models require sizing information on object points, function points and
line of source code. In more advanced COCOMO II models, a variety of scale
factors, cost drivers and adjustment procedures are required (Pressman, 2001).

Copyright © Open University Malaysia (OUM)


TOPIC 5 SOFTWARE PROJECT ESTIMATES  97

5.3.4 Pros and Cons of COCOMO


A major advantage of COCOMO is that we know all its details. Basic COCOMO
yields a simple and hence a crude cost estimate based on simple classification of
projects. It requires a small amount of data (LOC) to determine the effort and
cost. Hence it is a static single-valued model. The formulae would be derived
from a close analysis of a large number of projects and can therefore be claimed
to be based firmly on reality.

If you are not satisfied with the crudeness of Basic COCOMO, then proceed
higher to the Intermediate COCOMO which gives a more accurate estimate. But
you need to take extra care with the extra variables needed to produce the
results. If that is still not satisfactory, then proceed even higher to the Advanced
COCOMO. This would give the most accurate estimate, but it takes the most
effort to be realised.

The disadvantages are that it is an empirical estimation model. The empirical


data that supports its models are derived from a limited sample of projects. This
increases the likelihood of producing inaccurate results since the different
models depend on inaccurate constants. However, using the improved data of
increased number of previous projects, the COCOMO results are likely to
improve as well.

SELF-CHECK 5.3

Give a brief description of the basic, intermediate and advanced


COCOMO.

5.4 FUNCTION POINT ANALYSIS (FPA)


This is a top-down method devised by Allan Albrecht. This method is used to
quantify the functional size of programs independently of the programming
languages in which they had been coded. FPA is based on counting the number
of different data structures that are being used. It is assumed that this number of
different data structures is a good indicator of size. So, the advantage here is that
you donÊt have to worry much about programming ă whether structured or
object-oriented.

The basis of the FPA model is that information systems consist of five major
components that are beneficial to users. They are shown in Table 5.5.

Copyright © Open University Malaysia (OUM)


98  TOPIC 5 SOFTWARE PROJECT ESTIMATES

Table 5.5: Five Major Components of Computer-based Information Systems

Components Explanation
Internal Logical Files (ILF) Logical data files that store information for an
application that generates, uses and maintains the data.
External Logical Files (ELF) These files contain data or control information passed
from, passed to, or shared by another application. These
files allow for output and input that might pass to and
from other computer applications.
External Inputs (EI) Input transactions (from keyboards, communication
lines, tapes or other appliances) that update internal
computer files. In interactive systems, inputs screens
are the major external inputs.
External Outputs (EO) The transactions where data is output to the user. For
example, reports and messages.
External Inquiries (EIQ) Queries from the users.

The analyst has to identify each instance of the components in the project
system. Then each of the above five components is classified as having
either high, average or low complexity. The counts of each external user type in
each complexity band are multiplied by specified weights to get scores. The
weights for different components are given in Table 5.6.

Table 5.6: The Weights for Different Components

External User Multi


Type Low Average High
EI 3 4 6
EO 4 5 7
ILF 7 10 15
ELF 5 7 10
EIQ 3 4 6

The method has three stages:

(a) Analysing the system in terms of its information processing requirements


at a logical level, independent of implementation considerations and
calculating „Unadjusted Function Points‰ (UFPs), for example:

UFP = 4(EI) + 5(EO) + 10(ILF) + 7(ELF) + 4(EIQ)

Copyright © Open University Malaysia (OUM)


TOPIC 5 SOFTWARE PROJECT ESTIMATES  99

(b) A „Processing Complexity Adjustment‰ (PCA) is calculated to allow for


technical considerations such as ease of use, distributed processing and
maintainability. Further, the total degree of influence (DI) is computed
based on a six-point scale which leads to calculating the PCA:

PCA = 0.65 + 0.01(DI)

(c) The UFPs are factored by the PCA to derive the final function point score
(FP) for the project:

FP = UFP  PCA

One problem with FPs is that the question of whether the external user type is
of high, low or average complexity is rather subjective. The Albrecht method has
had many refinements made to it and now it is called as International FP user
group (IFPUG).

Detailed explanation of the FPA is beyond the scope of this text. Attempts to
improve the Albrecht method (FPA) has been made by Charles Symons in UK to
produce the Mark II Approach, which is again beyond the scope of this text.

ACTIVITY 5.1

Do more reading on software estimation techniques and estimate the:


(a) Effort of writing code for a payroll package for a college using
different software estimation techniques; and
(b) Number of persons required to do an embedded mode project
with an estimated size of 40,000 deliverable lines of code.

5.5 COCOMO VERSUS FPA


Software products are not easy to measure. One way of measuring it is based on
its size, and COCOMO is a famous type of size-oriented metrics. Thus, the size or
length of the software is assumed to be a reliable measure of how complex the
software is. The length of software is used to represent all the listed activities of
software engineering. That can be further translated into effort and cost. In this
type of software metrics, „lines of code‰ (LOC) is a key measure. Since there are
normally thousands of lines in todayÊs software, it is better expressed in terms of
KLOC, which means thousands of LOC.

Copyright © Open University Malaysia (OUM)


100  TOPIC 5 SOFTWARE PROJECT ESTIMATES

Proponents of the LOC measurement claim that LOC is an artefact of all software
development projects that can be easily counted. Many existing software
estimation models use LOC or KLOC as their key inputs. So, that makes LOC
still a credible way of estimating the complexity of software, which translates
into effort and cost.

However, opponents argue that LOC measures are programming language


dependent, because some language (such as Assembly Language) needs longer
codes than another (such as COBOL). Further, the size-oriented metrics do
under-value some well-designed but shorter programs. Further, this measure
cannot easily accommodate non-procedural languages.

Function Point Analysis (FPA) is a deepening of the function-oriented metrics.


This type of software metrics uses a measure of the functionality delivered by the
software application as a common denominator. Thus, besides the size, you can
also use the software functions to represent software complexity of some sort.

So in FPA, the system functions or their derivatives are assumed to be a reliable


measure of how complex the software is. Similarly, the functions can be
translated into effort and cost. Albrecht first proposed function-oriented metrics
in 1979, when he suggested a measure called function point for this purpose.

Function points are not counting the software functions literally, but are a sort of
derivatives of the system functions. The components used are data files of
various categories, inputs of various types, various outputs and inquiries. These
are further moderated and adjusted to give a fair representation of the software
complexity, effort and cost.

Once the function points have been calculated, they are used in a manner similar
to LOC to measure software productivity, quality, effort, cost and others. One
clear advantage of using the function-oriented metrics is that they are language
independent. You can use Assembly Language, Pascal, or any other
programming language ă the function points are still the same.

5.6 RECONCILING COCOMO AND FPA


Lines of code (LOC) can be mapped into function points and vice versa. For the
FPA, it does not matter which programming language is being used since the
software functions are independent of the programming language. However, for
the COCOMO, programming languages need to be taken into account.

Table 5.7 provides a rough estimate of the average number of LOC required in
building one function point in various programming languages.
Copyright © Open University Malaysia (OUM)
TOPIC 5 SOFTWARE PROJECT ESTIMATES  101

Table 5.7: Relationship between LOC and FP

Programming Language LOC Per FP (Average)


Assembly 320
C 128
COBOL 106
FORTRAN 106
Pascal 90
C++ 64
Ada95 53
Visual Basic 32
Smalltalk 22
PowerBuilder (code generator) 16
SQL 12

Source: Pressman (2001)

Both LOC and FP measures are often used to derive productivity metrics. They
are relatively accurate predictors of software development effort and cost.

What about programs written in Object-Oriented Language? A majority of


measurement depends on the techniques used in software design. For instance,
for software developed using the object-oriented design, the measures are based
on class diagrams. You can measure the complexity of a program or the whole
software system once you have produced the detailed design. In a detail design
you include the details of each method in a particular class if you use object-
oriented design. Based on Table 5.7, you can see C++, Visual Basic and Smalltalk.
These are object-oriented programming languages. Thus, they too can be
mapped into LOC and FP measurements.

ACTIVITY 5.2

How would you estimate the time and effort required to do the
following?
a) Modify a packaged software application; and
b) Develop a software application that makes use of object-oriented
programming language with reusable components.

Copyright © Open University Malaysia (OUM)


102  TOPIC 5 SOFTWARE PROJECT ESTIMATES

SELF-CHECK 5.4
1. Describe FPA briefly.
2. Briefly differentiate between COCOMO and FPA.
3. After reading this topic, you should be able to grasp the many
software effort estimation techniques. Which technique is suitable
in estimating the software efforts of a paperless medical
information system in a hospital?

Ć Software estimation is very important in software project management. Its


accuracy can prevent budget overruns, exceeding time-frames and other
surprises. Even though budget and other estimates are updated regularly, its
accuracy can further reduce project deviations.

Ć Because of the special characteristics of the software projects and special


problems in estimating their effort, time, cost and resources, suitable
estimation techniques and the resulted estimates should be examined
carefully.

Ć There are various software estimation techniques, such as:


ă Bottom-up estimation;
ă Top-down estimation;
ă Expert judgment;
ă Estimating by analogy;
ă Analysis effort method;
ă Programming method;
ă Three-point technique;
ă Delphi technique;
ă Constructive cost model; and
ă Function point analysis.

Copyright © Open University Malaysia (OUM)


TOPIC 5 SOFTWARE PROJECT ESTIMATES  103

Ć COCOMO is a famous type of the size-oriented metrics. Thus, the size or


length of the software is assumed to be a reliable measure of the complexity
of the software.

Ć COCOMO comes in three forms, which are the Basic COCOMO, Intermediate
COCOMO and Advanced COCOMO.

Ć It computes software development effort and cost as a function of program


size expressed in estimated lines of code.

Ć The more complex COCOMO adds in a set of „cost drivers‰ into the basic
one; while the most complex COCOMO further adds in an assessment of the
cost driverÊs impact on each step of analysis, design and so on in the project
life cycle.

Ć Function Point Analysis (FPA) is a deepening of the function-oriented


metrics. Once the function points have been calculated, they are used in a
manner similar to LOC to measure software productivity, quality, effort, cost
and others.

Ć FPA is based on counting the number of different data structures that are
being used. It is assumed that this number of different data structures is a
good indicator of size.

Ć The advantages of FPA are that you donÊt have to worry much about
programming whether structured or object-oriented and they are language
independent.

BrookÊs Law Function Point


Constructive Cost Model (COCOMO) ParkinsonÊs Law
Delphi technique Source lines of code (SLOC)
Expert Judgment Thousand lines of code (KLOC)

Copyright © Open University Malaysia (OUM)


104  TOPIC 5 SOFTWARE PROJECT ESTIMATES

Jagesh, N., Rahim, Y. A., Bakar, N. S. A. A., & Awang, M. Z. (2009). CBPM4103 ă
Information technology project management (2nd ed.). Kuala Lumpur: Open
University of Malaysia.
Lewis, J. P. (2011). Project planning, scheduling & control: The ultimate hands-on
guide to bringing projects in on time and on budget (5th ed.). New York, NY:
McGraw-Hill Professional.
Pressman, R. S. (2001). Software engineering: A practitionerÊs approach. Boston,
MA: McGraw-Hill.

Copyright © Open University Malaysia (OUM)


Topic  Project Risk
6 and Quality

LEARNING OUTCOMES

By the end of this topic, you should be able to:


1. State the importance of risk in a project environment;
2. Discuss the risk management plan;
3. Describe a disaster recovery plan;
4. Explain the importance of software quality; and
5. Differentiate project quality and process quality.

 INTRODUCTION
Project management must include management of risk and quality. All must be
carefully monitored from the beginning till the end. Thus, a large project that
takes a long time to complete is exposed to more risks, and exposed to the
possibility of not meeting the quality standards than a small one that takes up a
shorter time.

In software engineering projects, risks may come from the technical as well as the
business aspect. For example ă program complexity, unexpected program size,
product obsolescence and the birth of new technology can be considered as
technical risks. On the business aspect ă risk can take the form of losing the
opportunity to sell and losing support of the top management. In each of these
cases, an on-going project may become uncertain.

Project management too is facing quality checks and balances. Firstly, the
management process itself must be good; and secondly the product to be
produced must be good too. Otherwise, the customers and other stake-holders
Copyright © Open University Malaysia (OUM)
106  TOPIC 6 PROJECT RISK AND QUALITY

will be unhappy with the final outcome. This may result in termination of the
project, and rejection of the finished product. This topic will discuss all these
issues in sufficient details.

6.1 RISK MANAGEMENT PROCESS


In choosing the best project strategy, Lewis (2011) advices us to do both SWOT
and risk analyses. SWOT stands for strengths, weaknesses, opportunities and
threats. He singles out the difference between risks and threats. Risk is something
that can simply happen, such as an accident; whereas threat is something that
may be posed by another entity, such as a competitor. For practical purposes,
however, it is fine to combine threats and risks, as you have to look at them ă
they can jeopardise the project.

Project risk management is defined by the Project Management Body of


Knowledge (PMBOK) as „the systematic processes of identifying, analysing
and responding to project risk (throughout the project life cycle)‰ (in Jagesh,
Rahim, Bakar & Awang, 2009).

It includes maximising the results of positive events and minimising the


consequences of adverse events. The Application Performance Management
(APM) book defines risk as a factor that may cause a failure to meet the project
objectives. The generally accepted risk management model subdivides the risk
management process into the following headings (see Figure 6.1):

Figure 6.1: Risk management model


Source: Jagesh et al. (2009)

Copyright © Open University Malaysia (OUM)


TOPIC 6 PROJECT RISK AND QUALITY  107

Reduced to its essentials, risk management requires:


(a) The establishment to keep risks under review and to make sure they
are being addressed;
(b) A means of identifying the potential risks to the project;
(c) An assessment of the likelihood of each risk materialising;
(d) An assessment of the probable impact of each risk;
(e) The formulation of measures to avoid each risk occurring;
(f) Developing fall-back measures to ameliorate the risks if avoidance
actions fail; and
(g) Determining the urgency of the risk and of taking appropriate counter-
measures.

Also vital to successful risk management is the issue of ownership ă that


someone should be responsible for each risk. Each of these issues is addressed in
the sections that follow.

Figure 6.2 shows the risk management in an integrated form.

Figure 6.2: Risk management integrated


Source: Jagesh et al. (2009)

Risk Management Plan


The risk management plan documents how you propose to tackle risk on your
project. Table 6.1 explains the risk management plan further.

Copyright © Open University Malaysia (OUM)


108  TOPIC 6 PROJECT RISK AND QUALITY

Table 6.1: Risk Management Plan

Plan How
Define Define the context of your work and your plan for success. This
objectives defines what you have to achieve to be successful and establishes a
basis for dealing with risk and future decisions.
Identify risk Identify areas of risk, uncertainty and constraints, which may
impact your project and limit or prevent you from achieving your
objectives.
Quantify risk Evaluate the risks and prioritise the level of risk and uncertainty and
quantify their frequency of occurrence and impact.
Develop Define how you are going to respond to the identified risks, which
response may be a combination of the following actions: eliminate, mitigate,
deflect or accept the risks.
Risk control The risk control function implements the risk management plan.
This may involve training team members, and communication with
all stakeholders. As the risks and the work environment are
continually changing, it is essential to continually monitor and
review the level of risk and your ability to effectively respond.

Source: Adapted from Jagesh et al. (2009)

Risk management plan needs to be communicated to all the project participants


and where necessary followed up with appropriate training and practice runs. The
training should not only ensure that the risk management plan is understood, but
also develop a company-wide risk management culture and attitude.

Risk management may become an item on the weekly progress meetings to


prompt discussion, identify new areas of risk and develop appropriate responses.
Risk management plan should be monitored and updated on a regular basis to
ensure you learn from recurring risks and that it is relevant to changing
circumstances, such as:
(a) Changes in the scope of work;
(b) Changes in the build method;
(c) Changes in the team members; and
(d) Changes in the suppliers.

Copyright © Open University Malaysia (OUM)


TOPIC 6 PROJECT RISK AND QUALITY  109

SELF-CHECK 6.1

1. What is a risk management plan?


2. What is in the content of a risk management plan?

6.2 RISK IDENTIFICATION AND


QUANTIFICATION
Having defined your project objectives, the subsequent step is to identify what
areas of risk and uncertainty that could prevent you from achieving the stated
objectives ă i.e. a plan to prevent failure.

Risk identification is probably the hardest and most important part of the risk
management process because if you cannot identify a risk, it will be excluded
from further analysis, and therefore you will probably not respond to it. The
process of risk identification should not be a one-time event, but rather a
continuous process throughout the project. Its frequency depends on the level
of risk on the project and the schedule of meetings.

Using your list of objectives as the starting point, and based on the work
breakdown structure (WBS), you can add another two columns to identify
cause-and-effect scenarios (refer to Table 6.2). This can be tackled from both
directions:
(a) Cause ă if this cause happens, what effect will it have on the objectives?
(b) Effect ă what could result from this undesirable cause, e.g. a failure?

Table 6.2: Sample of Cause and Effect

WBS Objectives Cause Effect


1.1
1.2

Risk identification should be a systematic process to ensure nothing significant is


overlooked. By adding another column, combinations of risks can also be
considered. Seemingly small risks can combine in complex ways, and under a
variety of scenarios, to produce significant risks. Techniques for identifying
risks include the following listed in Figure 6.3.

Copyright © Open University Malaysia (OUM)


110  TOPIC 6 PROJECT RISK AND QUALITY

Figure 6.3: Techniques for identifying risks

The success of these techniques depends on how the risk management team have
been selected and brought together. A balanced team which incorporates
experience, knowledge, judgment, entrepreneurial innovation, creativity,
enthusiasm, internal members and external consultants, stands the best chance of
success.

Questionnaires, interviews and brainstorming are ways that can be used to


generate ideas and feedback from your colleagues, stakeholders, clients,
engineers, suppliers, legal eagles and governing agencies. Checklists, breakdown
structures and flow charts are ways to group and subdivide information for
collation and presentation.

Having identified a range of risks, the next step is to quantify the probability
(likelihood) of the risk occurring and the impact on or consequence to the project,
or to the amount at stake. Risk quantification is primarily concerned with
determining what areas of risk warrant a response and where resources are limited,
a risk priority will determine the areas of risk that should be addressed first.
Copyright © Open University Malaysia (OUM)
TOPIC 6 PROJECT RISK AND QUALITY  111

A probability matrix can be drawn to plot the probability of the risk occurring
against the impact on the project. They are quantified as high, medium or low.
The output from risk quantification should be a table which identifies, quantifies
and prioritises the risk. It is essential to establish which risks should be addressed
first so as to focus your effort.

6.3 RISK RESPONSE AND CONTROL


Having identified, quantified and prioritised the risks, you now need to develop
a risk response plan which defines ways to address adverse risk and enhance
opportunities before they occur. The levels of risk should be compared against
pre-established criteria, and then ranked to establish management priorities. The
responses which should be developed in advance during the planning phase are
shown in Figure 6.4.

Figure 6.4: Risk responses

These are not mutually exclusive responses. Your response may use a
combination of them. A natural sequence would be to first try and eliminate the
risk completely. If you cannot, then try to mitigate it. And for the remaining risk,
the options are to try and deflect it or accept it with a contingency. All these
responses cost money. Therefore, a cost-benefit analysis should be performed as
it may be more cost effective to accept a risk rather than take expensive steps to
eliminate it.

Now, let us look into the risk responses further:

(a) Eliminating risk


This response looks into how a risk can be avoided completely by either
removing the cause or taking an alternative course of action. This should
initially be considered during the concept and design phases, where the
level of influence is high and the cost to change is low.

(b) Mitigating risk


To mitigate a risk means reducing the probability and impact. This could be
achieved by using proven technology and standards to ensure the product
will work. Developing prototypes, simulating and modelling are three
methods which share the notion of using a representation to investigate
selected aspects of requirements in order to be more certain of the outcome.

Copyright © Open University Malaysia (OUM)


112  TOPIC 6 PROJECT RISK AND QUALITY

(c) Deflecting risk


This transfers the risk (in part or whole) to another party. It can be achieved
through contracting, retention, bonding and insurance and other means.
Project contracts are a means of deflecting risks away from the client, to the
contractor. Details of project contracts will be discussed in Topic 9, but
some types of contracts are given in Figure 6.5.

Figure 6.5: Types of contracts

(d) Accepting risk


To accept risk means willingness to face possible problems. This happens
when you cannot eliminate the risk completely, or you cannot mitigate the
risk, or you cannot deflect it. Thus, accepting the risk should be your last
resort. It implies that you must be ready with the contingency plan when
such trouble occurs. The solution must be ready to be applied.

Risk Monitoring and Control


Risk control function is the most important, but surprisingly often neglected. To
illustrate risk management, monitoring and control, let us assume that high
staff turnover is noted as a project risk. Based on history and estimation, the
probability of high turnover is estimated at 70%; the impact on project duration
would be an increase by 20%; and the overall cost would increase by 15%.

Therefore, the following steps are proposed:


(a) Meet the current staff to determine causes for turnover;
(b) Do something to reduce those causes before the project starts;
(c) Once the project starts, assume that turnover occurs and develop some
techniques to ensure continuity when staff leave;
(d) Organise project teams so that information on each activity is widely open
(and known) to others;
(e) Define documentation standards, and ensure that documents are timely;
(f) Conduct peer reviews of all the works, so that more persons understand;
and
(g) Define a backup staff member for every critical engineer.

Copyright © Open University Malaysia (OUM)


TOPIC 6 PROJECT RISK AND QUALITY  113

Risk analysis can absorb a lot of time in the project planning work. All the
activities take time, but the effort is worth it. As Sun Tzu said it 2500 years ago,
„If you know the enemy and know yourself, you need not fear the result of a
hundred battles.‰

ACTIVITY 6.1

1. How should project managers delegate the risks to the responsible


persons or departments?
2. Why is the use of risk management techniques becoming
increasingly more important in IS/IT projects?

6.4 DISASTER RECOVERY PLANNING (DRP)


Do you know what a disaster is? Let us read the following explanation.

A disaster is a sudden, unplanned catastrophe that prevents your company


from providing its critical business functions for a period of time and could
result in a significant damage or loss.

The time factor will determine whether a problem or service interruption is an


inconvenience or a disaster. Losing power for a few hours may be an
inconvenience, but losing power for a few weeks could be a financial disaster.
The objective of disaster recovery management is to reduce the consequence of a
disaster to an acceptable level. This is the ultimate contingency plan!

DRP is essentially a contingency response from your risk management planning,


but due to the unique nature and size of the problems it is probably best
managed separately as a project. The management of the disaster recovery plan
should be assigned to a manager with responsibility to set up a team to:
(a) Develop the disaster recovery plan;
(b) Control the disaster recovery plan; and
(c) Implement the plan quickly and effectively (when the time comes).

DRP essentially follows the same process as the risk management plan, except
now you are focusing on the major risks, which cannot be eliminated, mitigated

Copyright © Open University Malaysia (OUM)


114  TOPIC 6 PROJECT RISK AND QUALITY

or deflected. Controlling the disaster recovery plan may involve training; practice
and frequently updating the database of information (e.g. telephone numbers).

The disaster recovery team should meet regularly so that in the event of a
disaster they can hit the ground running. Figure 6.6 shows an example of a
disaster recovery team, Servpro in the US.

Figure 6.6: An example of disaster recovery team in the US


Source: http://www.mlive.com/business/mid-
michigan/index.ssf/2012/08/servpro_of_saginaw_sending_cre.html

A fire, flood, earthquake or hurricane would be good examples of a disaster


where your office, factory or facility could be completely destroyed or have
restricted access for a long period of time. How are you going to recover?

When a disaster happens, this is the time to implement your carefully developed
and updated disaster recovery plan. The first step is to mobilise the disaster
recovery team, maybe at a prearranged office where all the necessary office
equipment, information and communications are ready. Communicate the
disaster recovery plan to all the key people and stakeholders. Using telephone
trees (one person rings ten people), this would include:
(a) Employees;
(b) Clients;
(c) Suppliers; and
(d) Media.

Copyright © Open University Malaysia (OUM)


TOPIC 6 PROJECT RISK AND QUALITY  115

If necessary relocate the project office by:


(a) Moving to a pre-arranged office accommodation; and
(b) Recovering the critical databases that should have been regularly backed
up and stored off site.

It is essential that you accurately advise your clients how long it will be before
you can offer a normal service again. Statistics from America indicated that 43%
of American businesses are closed immediately by disasters, 51% for as long as
two years, and of these only 6% survive the experience. These are frightening
figures. If your company provides an essential business function, then your
clients will have to move to another supplier.

ACTIVITY 6.2

Do some additional reading and list four differences between a


contingency plan and a disaster recovery plan.

SELF-CHECK 6.2

1. What is disaster recovery planning and what is its main objective?


2. Who should take action in a disaster recovery plan?

6.5 PROJECT QUALITY MANAGEMENT


Quality of the finished product is another factor that customers can use to accept
or reject the product. Quality means something that can satisfy customers ă i.e.
products or services that consumers want at a price they are willing to pay. In
other words, your customer determines your quality ă not you.

In the long past, quality used to be seen as a matter of producing a product or


service that is better in some absolute sense of the word ă e.g. less machine break-
down is better; shorter program codes are better; Rolls Royce is better than
Proton. This is an old concept of quality. Today, quality can be defined as
follows:
(a) The degree to which a system, or component, or process meets specified
requirements, and meets customer or user needs and expectations; or
(b) Meeting the customer's needs in a way that exceeds his expectations; or

Copyright © Open University Malaysia (OUM)


116  TOPIC 6 PROJECT RISK AND QUALITY

(c) The extent to which products, services, processes and relationships are free
from defects, constraints and items which do not add value for customers.

A project is more than just a product. A quality software project can be defined
as a project that can deliver a quality software product that is:
(a) Reasonably bug-free;
(b) Delivered on time;
(c) Completed within specified budget;
(d) Meets requirements and expectations; and
(e) Can easily be maintained.

Other experts define quality based on conformance to requirements and fitness


for use. Conformance to requirements means the projectÊs processes and
products meet written specifications. Fitness for use means a product can be used
as it was intended.

The purpose of project quality management is to ensure that the project will
satisfy the needs for which it was undertaken. Project management involves
meeting or exceeding stakeholder needs and expectations. The project team must
develop good relationships with key stakeholders, especially the main customer
for the project, to understand what quality means to them.

Quality must be on an equal level with project scope, time and cost. If a projectÊs
stakeholders are not satisfied with the quality of the project management or the
resulting products of the project, the project team will need to adjust the scope,
time and cost to satisfy stakeholder needs and expectations.

Project quality management involves three main processes: quality planning,


quality assurance, and quality control. Details are illustrated in Table 6.3.

Table 6.3: Three Main Processes of Project Quality Management

Process Explanation
Quality planning This is concerned with defining how an organisation aims
to achieve software quality. It involves selecting standards
that should be applied to the software development
process. These standards must be embedded in procedures
or processes which are applied during development. These
processes may be supported by tools that may have to be
bought or specially developed during the quality assurance
process.

Copyright © Open University Malaysia (OUM)


TOPIC 6 PROJECT RISK AND QUALITY  117

Quality assurance This involves periodically evaluating overall project


performance to ensure the project will satisfy the relevant
quality standards. The quality assurance process involves
taking responsibility for quality during the project as well
as at the end of the project. Top management must take the
lead in emphasising the roles all employees play in quality
assurance, especially senior managersÊ roles.
Quality control This involves overseeing the software development process
to ensure that quality assurance procedures and standards
are being followed. The quality control process has its own
set of procedures and reports that must be defined and
applied during the development process. As far as possible,
these procedures should be straight-forward and easily
understood by the engineers developing the software.

Various lists of software quality characteristics have been introduced, and ISO
9126 has been chosen here as a guide here for defining software quality
characteristics (refer to Table 6.4).

Table 6.4: ISO 9126 Guideline for Defining Software Quality Characteristics

Characteristics Explanation
Functionality Functions provided by a software product to satisfy user needs.
Reliability Capability of the software to maintain its level of performance.
Usability Effort needed to use the software.
Efficiency Physical resources used when the software is executed.
Maintainability Effort needed to make changes to the software.
Portability Ability of the software to be transferred to a different
environment.

Some of the above characteristics are elaborated in the following:

(a) Reliability: This might be measured in the following terms:


(i) Availability: The percentage of a particular time interval that a system
is usable.
(ii) Mean time between failures: The total service time divided by the
number of failures.
(iii) Failure on demand: The probability that a system will not be available
at the time required or the probability that a transaction will fail.

Copyright © Open University Malaysia (OUM)


118  TOPIC 6 PROJECT RISK AND QUALITY

(iv) Support activity: The number of fault reports that are generated.

(b) Maintainability: This is closely related to flexibility, the ease with which the
software can be modified. The main difference is that before an amendment
can be made, the fault has to be diagnosed. Maintainability can therefore
be seen as flexibility plus diagnose-ability.

ACTIVITY 6.3

In your opinion, why is software quality very important today?

SELF-CHECK 6.3

1. How do you define a quality software project?


2. What are the main characteristics of quality software?

6.6 PRODUCT VERSUS PROCESS QUALITY


Quality characteristics of a certain product can only be measured once the
product is operational. But this is often too late. For example, when you buy a
non-branded personal computer, it is a typical risk you are taking on the product
quality. You will know its quality only after using it for a few years. If the
product can last for at least three years, you are considered very lucky.
Otherwise, you have to repair and upgrade here and there. It is more assured if
measurements are taken during development stage ă i.e. during the process
stage, by following the step-by-step process. By ensuring that development
process goes well, product quality can be better assured without waiting for the
product to be completed and used. Thus, product quality can be assured by
looking at the process quality.

When you buy a branded personal computer such as Dell, Acer, IBM and Apple
you are indeed taking very little risks on the product quality. They are known to
be following a manufacturing process with a high quality standard. Further,
these brands come with a warranty for some period of time, and you are charged
at a slightly higher price. So, you are less worried when buying these products of
well-known brands.

Copyright © Open University Malaysia (OUM)


TOPIC 6 PROJECT RISK AND QUALITY  119

Not only computers, you may choose cars like BMW, Toyota and Honda. You are
also less worried with these brands of cars. Not only for hard products or goods,
you may also choose soft products or services like going for degrees from
Harvard, Oxford and Cambridge. The quality checks are done at every step such
as entry qualifications, examinations, assignment and attendance. All these are
reasons for trusting the process quality.

Similarly, the software development process is made up of a number of activities


that are linked together so that the output from one activity is the input to the
next as shown in Figure 6.7. Therefore, program testing will depend on the
program to test, which will be the deliverable from the program coding stage,
and so on. Thus, by ensuring that the process is of the right quality, the software
product would have the quality too.

Figure 6.7: Sequence of processes


Source: Schwalbe (2004)

Errors should be eradicated by performing careful examination of the


deliverables of each stage before they are passed on to the next. Errors that are
detected at an early stage must be corrected immediately. It is more expensive to
correct at later stages for the following reasons:
(a) The later the error is found, the more rework at many stages of
development will be needed. If an error committed in the specification
stage is known only in the testing stage, it will require reworks at all the
stages between specification and testing; and
(b) Increased complication to rectify the error due to the complexity of the
program.

Copyright © Open University Malaysia (OUM)


120  TOPIC 6 PROJECT RISK AND QUALITY

Standards Organisations
Several national and international standards institutes, professional and
industry-oriented organisations have developed Software Quality Assurance
(SQA) standards and have invested remarkable amount of resources in these
projects.

The following organisations have gained international reputation, and are among
the most prominent developers of SQA and software engineering standards:
(a) IEEE (Institute of Electrical and Electronics Engineers) Computer Society;
(b) ISO (International Organisation for Standardisation);
(c) DOD (US Department of Defence);
(d) ANSI (American National Standard Institute);
(e) IEC (International Electro-technical Commission); and
(f) EIA (Electronic Industries Association).

SELF-CHECK 6.4

What is the difference between product quality and process quality?

6.7 ISO CERTIFICATION


Organisations must meet world quality standards if they want to compete in the
world market. „International Organisation for Standardisation‰ (ISO) is a world
body, located in Geneva that manages and controls the world quality standards,
such as the ISO-9001 (Quality Management Standards). ISO consists of
representatives from participating countries, where „Standards and Industrial
Research Institute of Malaysia‰ (SIRIM) represents Malaysia.

Benefits of ISO certification are listed in Figure 6.8.

Copyright © Open University Malaysia (OUM)


TOPIC 6 PROJECT RISK AND QUALITY  121

Figure 6.8: Benefits of ISO certification

One of the popular standards is ISO 9000, which is meant for Quality
Management. ISO 9000-3, the guidelines offered by the ISO, represent
implementation of the general methodology of quality management to the
special case of software development and maintenance. Both ISO 9001 and ISO
9000-3 are reviewed and updated once every five to eight years.

ISO 9001 and TickIT Initiative


TickIT was launched in the late 1980s by the UK software industry in cooperation
with the UK Department for Trade and Industry to promote development of
methodology for adapting ISO 9001 to the characteristics of the software
industry, known as the TickIT initiative. At the time of its launch, ISO 9001 had
already been successfully applied in the manufacturing industry. However, no
significant methodology for its application to the special characteristics of the
software industry was available.

TickIT is a leading provider of ISO 9001 specification, specialising in information


technology (IT), it covers the entire range of commercial software development
and maintenance services. Figure 6.9 shows the logo of TickIT.

Copyright © Open University Malaysia (OUM)


122  TOPIC 6 PROJECT RISK AND QUALITY

Figure 6.9: Logo of TickIT


Source: http://www.tickit.org/

TickIT is managed and maintained by the DISC Department of British Standards


Institute and it is accredited for certification of IT organisations in the UK and
Sweden. In June 2002, TickIT reported a clientele of 1252 organisations in 42
countries, the majority in the UK (882), Sweden (54) and the US (109). TickIT is
currently authorised to accredit other organisations as certification bodies for the
software industry in the UK.

6.8 CAPABILITY MATURITY MODEL


The Capability Maturity Model (CMM) was introduced by the Software
Engineering Institute (SEI) at Carnegie Mellon University in 1986. The initial
version of the CMM was released in 1992, mainly for receipt of feedback from the
software community. The first version for public use was released in 1993.

CMM assessment is based on the following concepts and principles:

(a) Application of more elaborate management methods based on quantitative


approaches increases the organisationÊs capabilities to control the quality as
well as improve the productivity of the software development process.

(b) The vehicle for enhancement of software development is composed of the


five-level capability maturity model. The model enables an organisation to
evaluate its achievements and determine the efforts needed to reach the
next capability level by locating the process areas requiring improvements.

(c) Process areas are generic. They define the „what‰, and not the „how‰. This
approach enables the model to be applied to a wide range of
implementation organisations because:
(i) It allows the use of any life cycle model;

Copyright © Open University Malaysia (OUM)


TOPIC 6 PROJECT RISK AND QUALITY  123

(ii) It allows the use of any design methodology, software development


tool and programming language; and
(iii) It does not specify any particular documentation standard.

The CMM and its Key Process Areas (KPAs) are presented in Figure 6.10. It
shows increasing levels of maturity for software development process ă i.e. from
a disciplined process (initial) towards a continuously improving process
(optimising).

Figure 6.10: Capability maturity model (CMM)


Source: Schwalbe (2004)

The five CMM levels and its KPAs are shown in Table 6.5.

Table 6.5: CMM Levels and KPAs

Levels KPAs
Level 1: Initial No key process required
Level 2: Repeatable  Software Configuration Management
 Software Quality Assurance
 Software Subcontract Management
 Software Project Tracking and Oversight
 Software Project Planning
 Requirements Management

Copyright © Open University Malaysia (OUM)


124  TOPIC 6 PROJECT RISK AND QUALITY

Level 3: Defined  Peer Reviews


 Intergroup Coordination
 Software Project Engineering
 Integrated Software Management
 Training Program
 Organisation Process Definition
 Organisation Process Focus
Level 4: Managed  Software Quality Management
 Quantitative Process Management
Level 5: Optimising  Process Change Management
 Technology Change Management
 Defect Prevention

ACTIVITY 6.4

How do you value the quality of an educational courseware or a


portal for the blind community? Do the quality value criteria differ in
those projects? List those criteria to support your idea.

Ć IS projects are becoming more complex and are subjected to various types of
risks.

Ć Risks cannot be avoided but they can be managed in such a way that they are
recognised, and their impact can be avoided or mitigated. There are a number
of areas where project risks can arise ă from business, commercial and
contractual risks to technical risks.

Ć The basic sequence for risk management is identification, assessment,


formulation and implementation of risk-reduction actions.

Ć The approach to managing risk on a project should be documented in a


formal risk management plan.

Copyright © Open University Malaysia (OUM)


TOPIC 6 PROJECT RISK AND QUALITY  125

Ć Quality refers to the degree to which a system, or component, or process


meets specified requirements, and meets customer or user needs and
expectations.

Ć Quality software project refers to a project that can deliver a quality software
product that is reasonably bug-free; delivered on time; completed within
specified budget; meets requirements and expectations; can easily be
maintained; etc.

Ć ISO certification is a proof that a company has a built-in quality management


system, and that it produces quality products.

ISO certification Risk management plan


Process quality Risk quantification
Product quality Risk response
Quality Risks
Risk identification Software project quality

Jagesh, N., Rahim, Y. A., Bakar, N. S. A. A., & Awang, M. Z. (2009). CBPM4103 ă
Information technology project management (2nd ed.). Kuala Lumpur: Open
University of Malaysia.
Lewis, J. P. (2011). Project planning, scheduling & control: The ultimate hands-on
guide to bringing projects in on time and on budget (5th ed.). New York, NY:
McGraw-Hill Professional.
Lynch-Morin, K. (2012). Servpro of Saginaw sending crews south to help prepare
for Hurricane Isaac. Retrieved from http://www.mlive.com/business/mid-
michigan/index.ssf/2012/08/servpro_of_saginaw_sending_cre.html
Schwalbe, K. (2004). Information technology project management. Cambridge,
MA: Thomson Course Technology.
TickIT. (2011). Retrieved from http://www.tickit.org/

Copyright © Open University Malaysia (OUM)


Topic  Scheduling,
7 Monitoring
and Control
LEARNING OUTCOMES
By the end of this topic, you should be able to:
1. List the main activities in the execution phase of a project life cycle;
2. Estimate time duration for a project;
3. State the advantages and disadvantages of a Gantt chart;
4. Discuss the importance of scheduling;
5. Describe the concept of earned value analysis; and
6. Identify the priorities in the work of monitoring.

 INTRODUCTION
This topic will discuss three major activities in the execution phase of the project
life cycle (PLC). The first activity is scheduling. This is an activity of producing a
timetable for the plan. The result of scheduling is a plan in the form of a Gantt
chart or a network diagram that graphically portrays activities in the appropriate
inter-dependent sequence to accomplish the project work scope.

The second activity is monitoring of project activities based on the schedule,


while the third one is to control the activities. Any deviation of the activities will
be brought back into the project based on the original schedule. However,
schedules can be revised and updated if required. Some techniques of
monitoring and control will also be introduced in this topic. Estimating the value
of the work done in a project is called „Earned Value‰ analysis. This is very
useful in a contract situation which involves financial claims for the work already
Copyright © Open University Malaysia (OUM)
TOPIC 7 SCHEDULING, MONITORING AND CONTROL  127

done so far. Finally, this topic ends with a very brief introduction to Microsoft
Project, a software tool for scheduling project activities.

7.1 PROJECT EXECUTION


Project execution is the subsequent phase after planning. However during
execution, project planning does not stop. There are always more details to be
added on, and some adjustments to be made. During project execution, a lot of
resources are committed and this requires a lot of attention by the project
manager. Among the activities to be done here includes scheduling, monitoring
and control.

One primary feature that distinguishes project management from the


general management is the special attention to scheduling. A schedule is the
conversion of a project action plan into an operating timetable.

As such, it serves as the basis for monitoring and controlling project activity and,
taken together with the plan and budget, is probably the major tool for the
management of projects.

In a project environment, the scheduling function is more important than it


would be in an on-going operation because projects lack the continuity of day-to-
day operations and often present much more complex problems of coordination.
Indeed, project scheduling is so important that a detailed schedule is sometimes
a customer-specified requirement.

Not all project activities need to be scheduled at the same level of detail. In fact,
there may be even more than one schedules. These schedules are typically based
on the previously determined action plan and work breakdown structures
(WBS), and it is good practice to create a schedule for each major task level in the
WBS that will cover the work packages. It is rarely necessary to list all the work
packages. One can focus mainly on those that need to be monitored for
maintaining adequate control over the project.

The basic approach to all scheduling techniques is to form a network of activity


and event relationships that graphically portrays the sequential relations
between the tasks in a project. Tasks that must precede or follow other tasks are
then clearly identified, in terms of time and function.

Copyright © Open University Malaysia (OUM)


128  TOPIC 7 SCHEDULING, MONITORING AND CONTROL

ACTIVITY 7.1
What is your opinion if someone says that scheduling is one of the most
important elements in project management? Will a project become very
loose without scheduling?

SELF-CHECK 7.1

List three main activities in the project execution phase of PLC.

7.2 PROJECT ACTIVITIES AND DURATION


The first step in establishing a project schedule is to identify the activities and to
estimate how long each activity will take, from the time it is started until the
time it is finished. This duration estimate for each activity must be the total
elapsed time. It means the time for the work to be done plus any associated
waiting time. Typically, the activity duration estimate can be shown in the
lower-right-hand corner of the box in the activity box format of network
diagrams as shown in Figure 7.1.

Figure 7.1: Activity duration estimate (activity-in-the-box format)

The activity duration estimate is shown below the arrow in the activity-on-the-
arrow format in Figure 7.2.
Copyright © Open University Malaysia (OUM)
TOPIC 7 SCHEDULING, MONITORING AND CONTROL  129

Figure 7.2: Activity duration estimate (activity-on-the-arrow format)

An activity duration estimate must be based on the quantity of resources


expected to be used on the activity. The estimate should be aggressive and yet
realistic. It should not include time for a lot of things that could possibly go
wrong, nor should it be too short. It is generally better to be somewhat
aggressive and estimate an activity with a time-duration of five days, say, and
then actually finish it in six days; rather than to be overly conservative and
estimate duration at 10 days and then actually take 10 days. People sometimes
perform to expectations if an activity is estimated to take 10 days, their effort
will expand to fill the whole 10 days allotted, even if the activity could have
been performed in a shorter time.

The required completion time is normally part of the project objective and stated
in the contract. In some cases, both estimated start time and required completion
time are stated ă e.g. the project will not start before 1 June 2014, and must be
completed by 30 September 2014. In other cases, the customer specifies only the
date of completion.

The contractor, however, may not want to commit to completing the project by a
specific date until the customer has approved the contract. In such cases the
contract may state, „The project will be completed within 90 days of the signing
of the contract‰. Here the overall project time is stated in terms of a cycle time
(90 days) rather than in terms of specific calendar dates.

SELF-CHECK 7.2

How do you estimate the time duration of one project? Describe the
general guidelines for this.

Copyright © Open University Malaysia (OUM)


130  TOPIC 7 SCHEDULING, MONITORING AND CONTROL

7.3 SCHEDULING METHODS


The earliest scheduling method worked out in detail was the bar chart. It is also
called the Gantt chart, developed by Henry Gantt around 1903. It was then used
for planning and controlling military campaigns in France. In the late 1940s, Du
Pont developed the Critical Path Method (CPM), which uses the network to
identify activities that are critical to the early delivery of the final product.

In the late 1950s, a scheduling system called the Program Evaluation and Review
Technique (PERT) was developed, and applied to the Polaris submarine project
in the US. The project was shortened by two years. PERT is very similar to CPM.
The major difference is that PERT applies statistics to the network, whereas CPM
does not.

Network Analysis and Critical Path Analysis are terms simply used to describe
PERT and CPM. Although there are some variations in the detailed approach of
each of these methods, the basic assumptions are the same. These tools can assist
project managers to schedule projects, to monitor the progress of activities more
effectively, and to present progress reports to the Steering Committee and other
stakeholders.

To illustrate how a project is scheduled, we need to identify the activities


involved in the project, and the estimated time duration required to complete
each activity. For small projects, it is normally assumed that the activity
durations are based on the time required for one person working full-time to
complete the work, though it is not always the rule.

Table 7.1: Schedule of Activities in IT Projects

Activity Description Estimated Time


A. Obtain agreement on the proposed project 1 week
B. Prepare and agree on the training 1 week
programme
C. Train user staff 4 week
D. Write/code programs 5 week
E. Testing of programs 6 week
F. Systems testing 2 week
G. Parallel run 4 week
H. Cutover 1 week

Copyright © Open University Malaysia (OUM)


TOPIC 7 SCHEDULING, MONITORING AND CONTROL  131

Table 7.1 provides examples of activities found inside a typical IT project. The
given set of activities will become the basis for the Gantt chart and the network
diagram to be drawn in the foregoing sections.

7.4 GANTT CHART


Based on the activities in Table 7.1, a Gantt chart can be drawn by plotting into a
graph with time duration on the x-axis, and activities on the y-axis. The chart
consists of several horizontal bars, where each bar represents each activity in the
project. The length of each bar is proportional to the time duration in the project
that has been planned. See Figure 7.3 for the chart.

Figure 7.3: Gantt chart for IT project activities

The bars are unshaded in the beginning, but when the activities are done, either
fully or partly, they are shaded corresponding to the parts completed. The use of
a vertical cursor will quickly show which activities are behind schedule and
which ones are ahead of schedule. This helps to schedule, monitor and control
project progress.

Table 7.2 discusses the advantages and disadvantages of using Gantt charts.

Copyright © Open University Malaysia (OUM)


132  TOPIC 7 SCHEDULING, MONITORING AND CONTROL

Table 7.2: Advantages and Disadvantages of the Gantt Chart

ADVANTAGES DISADVANTAGES
Ć The main advantage of the Ć A major disadvantage of the Gantt chart
Gantt chart is the simplicity to technique is that it does not show the
be drawn and to be understood interdependence of various activities. For
by ordinary persons. It shows example, it does not show to start Activity-F
the activities on a time-related only after completion of Activity-E, or
basis. So it gives a good overall whether to start Activity-D after Activity-A.
picture of the entire project No matter how you try to arrange the
without going into the nitty- activity list, you still cannot give an accurate
gritty of details. representation of the relationships between
Ć The chart provides a very good the activities, because the activities are
picture for presentation to the disjointed.
top management. Ć Further, this chart also offers no guide on
the effect of a delay on one activity over the
entire project. The bar chart can only display
the planned start of an activity. If any
activity starts late, the implications are not
readily obvious. For this reason, the chart
cannot really represent the true status of a
project. The effect would become even
worse for a large-scale project.

7.5 CRITICAL PATH METHOD


This subtopic discusses critical path method as a technique to schedule projects.
First, letÊs use a simple network. To overcome the disadvantage of the Gantt
chart as discussed in previous section, the network diagram is often used. The
Gantt chart in Figure 7.3 can be easily translated with some modifications into a
network diagram as shown in Figure 7.4.

Figure 7.4: Network diagram for IT project activities

In a network diagram, arrows represent project activities, while circles (nodes)


represent the start and end of such activities. The directions of arrows indicate
directional flow of activities. It is usual and convenient for the flow to be from

Copyright © Open University Malaysia (OUM)


TOPIC 7 SCHEDULING, MONITORING AND CONTROL  133

left to right, and from top to bottom. By using just these two symbols, a complete
project network can be developed.

Besides acting as starters and terminators of activities, the circles (nodes) are also
used to represent the events. Thus, a project starts with circle number 1, which
represents the first event of the project. A project terminates with the last circle
number. This circle is supposed to take the highest number in the series. There is
no more activity after the last circle (node).

7.5.1 Analysis of Network


According to Figure 7.4, Activity-D can indeed start immediately after Activity-
A, instead of waiting for Activity-B to complete first. This decision is reached
after a thorough analysis is made of the activities involved. An analysis of the
activities is shown in Table 7.3.

Table 7.3: Analysis of Activities for Critical Path

Activity (Duration) Early Start Late Start Early Finish Late Finish
Activity-A (1 week) 0 0 1 1
Activity-B (1 week) 1 7 2 8
Activity-C (4 weeks) 2 8 6 12
Activity-D (5 weeks) 1 1 6 6
Activity-E (6 weeks) 6 6 12 12
Activity-F (2 weeks) 12 12 14 14
Activity-G (4 weeks) 14 14 18 18
Activity-H (1 week) 18 18 19 19

According to Table 7.2, it is important to record Early-Start and Late-Start


because some activities can start even later without affecting the overall project
schedule. Consequently, these activities would have a different Early-Finish and
Late-Finish as well. Early-Finish is obtained by adding Early-Start by the activity
time duration. Similarly, Late-Finish is obtained by adding Late-Start by the
activity time duration.

The activities underlined lie on the Critical Path. These activities have the same
Early-Start and Late-Start, and the same Early-Finish and Late-Finish. In Figure
7.4, the critical path is made up of activities A, D, E, F, G and H ă symbolised
with thick arrows. In other words, people working on these activities cannot take
a rest, as there is immediately another activity after a previous activity. All

Copyright © Open University Malaysia (OUM)


134  TOPIC 7 SCHEDULING, MONITORING AND CONTROL

activities along this path are considered critical activities. They have to be closely
monitored and controlled if the project were to be completed on time.

For the non-critical activities, there are times of rest for them. For example,
Activity-B can start as early as after 1 week, or as late as after 7 weeks. Since this
activity is scheduled to take 1 week to complete, Activity-B would end 2-8 weeks
after the start of project. There is thus a slack of 6 weeks in between. Slack (or
float) is the amount of time an activity can be delayed without delaying the
project.

There is also a dotted arrow line in between Node-4 and Node-6 (Figure 7.4). It is
called the „Dummy Activity‰. This activity is only a logical link between the two
nodes. It does not represent any specific operation, and it does not utilise any
resource at all. From the above analysis, it is clear that the project can finish at
week number 19, thereby, giving a saving of one week compared to the Gantt
chart produced earlier.

The Critical Path Method overcomes the major disadvantage of the Gantt chart in
that it reveals the interdependence of activities. It shows precisely and clearly the
activities in consecutive order. Thus, after Activity-A, we can have Activity-B and
Activity-D. Similarly, Activity-F can start only after the completion of Activity-C
and Activity-E. Such possibilities are not clearly shown in the case of the Gantt
chart.

7.5.2 Complex Network Notation


Network diagrams can be drawn in a simple way as shown in Figure 7.4. With
this, you will need a table to analyse the statistics as shown in Table 7.2.
However, the diagram can be drawn using a more complex notation, so that
there is no real need to look at the analysis in a table form.

There are a number of conventions being used; some with three compartments
for the nodes, while others with four compartments. We can now represent the
nodes as illustrated in Figure 7.5 using the four compartments.

Figure 7.5: Complex notation for nodes of a network diagram


Copyright © Open University Malaysia (OUM)
TOPIC 7 SCHEDULING, MONITORING AND CONTROL  135

Thus, Figure 7.6 can now replace the earlier network diagram given in Figure 7.4.

Figure 7.6: New network diagram for IT project activities

The thick arrows along which the slack equals 0 indicate the Critical Path. This
path can be coloured for better appearance. The thin arrows are not in the critical
path where slacks are present, while the dotted arrow represents a dummy
activity.

The purpose of analysing a network diagram is to determine the total project


time (TPT), which is defined as: „The shortest time in which the project can be
completed as determined by the sequence of activities in the network diagram,
which comprise the critical path‰ (Young, 1993).

Table 7.4 discusses the advantages and disadvantages of using network


diagrams.

Copyright © Open University Malaysia (OUM)


136  TOPIC 7 SCHEDULING, MONITORING AND CONTROL

Table 7.4: Advantages and Disadvantages of Network Diagram

ADVANTAGES DISADVANTAGES
Ć A major advantage of the network Ć A major disadvantage of the network
diagram is that it reveals the inter- diagram is that current status of the
dependence of activities. Unlike project cannot be shown clearly on the
those of the Gantt chart, activities diagram, whereas, this is possible in the
can now be linked. case of the Gantt chart because the chart
Ć The network also has the time has the time axis. Thus, the network is
element along the activities. This not very informative for presentation to
enables you to calculate the higher management.
amount of delays allowed, and so Ć Another disadvantage is that there is
it is now possible to use computers often a need to include dummy activities.
to do calculations. Dummy activities can be left out only if
you record early finish and late finish on
the nodes. This is possible only by using
a complex notation.
Ć Finally, the manual preparation of the
network is quite tiresome. The network
can be very difficult to maintain and
keep up-to-date manually. Because of its
appearance and the statistics, a complex
network is generally not acceptable as a
report, especially for top management.

7.5.3 Network Improvement


After completing the network diagram, together with the calculations of both the
activities and the tentative completion date of a project, it is usual to evaluate the
plan against the target completion date originally set for the project. In most
situations, an initial plan would fail to meet the expected completion date. Thus,
a plan must be prepared to be re-planned.

Fortunately, the network diagram and analysis approach is a powerful tool for
supporting this possible change to the plan. Two examples of changes that can be
made to the network are provided below to illustrate the power of this technique:

(a) Reduce activity durations


This can be done by concentrating only on activities on the critical path. If a
certain critical activity can be reduced from 12 weeks to 8 weeks, it suggests
that the project can be reduced by about one month. This reduction of
activity duration below the normally estimated time would normally
increase the cost of the activity as more resources would be required.

Copyright © Open University Malaysia (OUM)


TOPIC 7 SCHEDULING, MONITORING AND CONTROL  137

(b) Change activity sequence


This requires a review of the logical sequence of activities in the initial plan.
Some activities may be undertaken in parallel. Others can start when only
parts of the preceding activities have been completed. These and other
possibilities should focus on activities that lie on the critical path. They may
involve breaking up or merging together of activities.

ACTIVITY 7.2

In project management, why do we need to know the total elapsed time,


especially if we use the network diagrams?

7.6 USING OTHER CHARTS


There are a few more types of charts which can be used as alternatives. We will
be discussing further focusing on two of the following charts:
(a) Job progress chart; and
(b) Ball charts.

Let us learn more about these two charts:

(a) Job Progress Chart (JPC)


As a compromise between the need for a simple tool as the Gantt chart as
well as the flexibility of the network, the Job Progress Chart (JPC) can be
drawn as a possible alternative. It is more like a modified Gantt chart. JPC
records the slack period of the project, as shown in Figure 7.7.

Copyright © Open University Malaysia (OUM)


138  TOPIC 7 SCHEDULING, MONITORING AND CONTROL

Figure 7.7: Job progress chart for IT project activities

(b) Ball Charts


One way of showing whether targets have been met or not is to use a ball
chart as shown in Figure 7.8.

Figure 7.8: Ball chart

In this version of the ball chart, the circles indicate start and completion
points for activities. The circles initially contain the original scheduled
dates. Whenever revisions are produced, these are added as second dates in
the appropriate circle until an activity is actually started or completed when
Copyright © Open University Malaysia (OUM)
TOPIC 7 SCHEDULING, MONITORING AND CONTROL  139

the relevant date replaces the revised estimate. Circles will therefore
contain only two dates, the original and most recent target dates, or the
original and actual dates.

Another advantage of ball charts over Gantt and other types of charts is
that they are relatively easy to keep up-to-date. Only the dates and colours
need to be changed, whereas the others need to be redrawn each time target
dates are revised.

ACTIVITY 7.3

Give your own idea on how to manage an educational software


project for the Ministry of Education by integrating all the knowledge
you have gathered.

SELF-CHECK 7.3

Name two kinds of charts that you can use to schedule project activities.

7.7 EARNED VALUE ANALYSIS


Earned value analysis has gained popularity in recent years and is based on
assigning a value to each task or work package based on the original expenditure
forecasts. The assigned value is the original budgeted cost for the item and is
known as the baseline budget or budgeted cost of work scheduled (BCWS).

A task that has not started is assigned the value zero and when it has been
completed it is credited with the value of the task. The total value credited to a
project at any point is known as the earned value or budgeted cost of work
performed (BCWP) and this can be represented as a value or as a percentage of
the BCWS.

Where a task has been started but is not yet completed, some consistent method
of assigning an earned value must be applied. Common methods in software
projects are shown in Table 7.5.

Copyright © Open University Malaysia (OUM)


140  TOPIC 7 SCHEDULING, MONITORING AND CONTROL

Table 7.5: Common Methods in Software Projects

Methods of Assigning an Earned Value


The 0/100 Technique The 50/50 Technique The Milestone Technique
A task is assigned a value A task is assigned a value A task is given a value
of zero until such time of 50% of its value as soon based on the achievement
that it is completed when as it is started and then of milestones that have
it is given a value of 100% given a value of 100% been assigned values as
of the budgeted value. once it is complete. part of the original budget
plan.

Of all these, the 0/100 is preferred and the 50/50 technique can give a false sense
of security by over-valuing the reporting of activity starts. The milestone
technique might be appropriate for activities with a long duration estimate but it
is better to break that activity into a number of smaller ones.

The Baseline Budget or Budgeted Cost of Work Scheduled (BCWS)


The first stage in setting up an earned value analysis is to create the baseline
budget. The first baseline budget is based on the project plan and shows the
forecast growth in earned value through time. Earned value may be measured in
monetary values but, in the case of staff-intensive projects such as software
development, it is common to measure earned value in person-hour or work-
days.

Monitoring Earned Value or Budgeted Cost of Work Performed (BCWP)


Having created the baseline budget, the next task is to monitor earned value as
the project progresses. Monitoring the completion of tasks will do this. Besides
recording BCWP, the actual cost of each task can be collected as actual cost of
work performed (ACWP). Please refer to Table 7.6.

Table 7.6: Monitoring Earned Value

Earned Value Description


Budget Variance This can be calculated as: ACWP ă BCWS.
It indicates the degree to which actual costs differ from those
planned.
Schedule Variance The schedule variance is measured in cost terms as: BCWP ă
BCWS.
It indicates the degree to which the value of completed work
differs from that planned. For example, schedule variance in
time indicates the degree to which the project is behind
schedule.

Copyright © Open University Malaysia (OUM)


TOPIC 7 SCHEDULING, MONITORING AND CONTROL  141

Cost Variance This is calculated as: BCWP ă ACWP.


It indicates the difference between the budgeted cost and the
actual cost of completed work. It is also the indicator of the
accuracy of the original cost estimates.
Performance Two ratios are commonly tracked:
Ratios Ć The cost performance index (CPI = BCWP Á ACWP)
Ć The schedule performance index (SPI = BCWP Á BCWS)

They can be thought of as a value-for-money index. A value that is greater than


one indicates that work is being completed better than planned, whereas a value
of less than one means work is costing more than and/or proceeding more
slowly than planned.

SELF-CHECK 7.4

1. What is the use of the earned value analysis?

2. What do the following terms mean?


(a) Budget variance;
(b) Schedule variance; and
(c) Cost variance.

7.8 MONITORING AND CONTROL


When monitoring and controlling a project, you will need to follow five basic
steps. Now let us look at Figure 7.9 that shows the five steps.

Figure 7.9: Five basic steps to monitor and control a project


Source: Harvard Business Review (2012)

According to Harvard Business Review (2012), the five steps to monitor and
control a project are explained further as follows:

(a) Tracking project activities ă ItÊs important to check with team members
regularly to make sure that they are completing their tasks and meeting
quality standards. This can be done most effectively through team

Copyright © Open University Malaysia (OUM)


142  TOPIC 7 SCHEDULING, MONITORING AND CONTROL

meetings, if everyone works at the same location. For distributed teams, an


alternative method needs to be done.

(b) Collecting performance data ă A few companies have project management


information systems that automatically generate reports. Besides that, you
should also seek out performance data through short pulse meetings where
team members share status updates either face-to-face or virtually.

(c) Determining whether the plan still holds ă Project activities seldom go
precisely as anticipated. They may take more or less time. They may over-
run or under-run the budget. When a plan does need revising, you may
have to extend the end date, apply budget reserves, remove deliverables or
even cancel the project.

(d) Report progress to your stakeholders ă Regular reviews with the key stake-
holders is not a wasted effort. The main purpose is to manage risk.
Remember that stakeholders care about reaching business goals, not about
following the teamÊs day-to-day activities. When you present problems,
give options for responding to them and discuss the risks. The stakeholders
will decide which risks they want the business to take.

(e) Manage changes to the plan ă When revising a plan, you may make major
or just minor changes. If you propose major changes to the stakeholders,
spell out the costs and risks of adopting them. Compare these with the ones
if you were to stick to the original plan. For a large-scale revision, use the
normal planning techniques and send the new plan to your team members.
Explain any changes that affect them. Minor changes may be handled
without seeking stakeholder approval.

Priorities in monitoring
There are some situations when the project team needs to prioritise some aspects
over the other. The priorities to monitor include the following listed in Table 7.7.

Copyright © Open University Malaysia (OUM)


TOPIC 7 SCHEDULING, MONITORING AND CONTROL  143

Table 7.7: Priorities in Monitoring

Priorities Description
Critical path activities Any delay in an activity on the critical path will cause a delay
in the completion date for the project.
Activities with less It is common practice to monitor closely those activities with
than a specified float less than one week free float.
High-risk activities These activities will be given close attention because they are
most likely to overrun or overspend.
Activities using Activities can be critical because they are very expensive.
critical resources

Almost any project will, at one time or another, be subject to delays and
unexpected events. One of the tasks of the project manager is to recognise when
this is happening and with minimum delay and disruption to the project team.

Change control
Under some circumstances, software requirements are modified because the
users change their requirements due to changes in the company policy or simply
because they have a clearer idea of what are really needed. Internal changes are
also critical when there are inconsistencies in the program specifications that
become apparent only when the programs are coded and these result in
amendments to the specifications. When changes occur, careful control of these
changes is needed because an alteration in one document often implies changes
to other documents and the related system products.

Project control
Control often means power or authority to direct, order or restrain. It can also
mean management guidance, regulating, restraining and keeping in order. So,
project control too can have such a wide perspective in meaning and
implications.

The following points indicate some important elements of project control


practice, especially in IS/IT projects:

(a) Projects should be of manageable size ă try to make sure that times for
completion do not exceed 18 months;

(b) Start the project only after full agreement and commitment;

(c) Project leader must be of mixed skills;

Copyright © Open University Malaysia (OUM)


144  TOPIC 7 SCHEDULING, MONITORING AND CONTROL

(d) Main elements to be monitored are:


(i) Activities completed;
(ii) Materials and machines being used;
(iii) Time spent in man-days or man-weeks; and
(iv) Total costs incurred so far.

(e) If there are deviations from the plan, then corrective actions are required to
bring the project back into the plan;

(f) Apply the milestone reviews at certain strategic points along the project life
cycle. There ought to be overall reviews of the project progress; and

(g) Finish the project as soon as it is accepted.

ACTIVITY 7.4

A change in a program specification will normally be carried through


into changes to the program design and then changes to the code. What
other products might need to be modified?

SELF-CHECK 7.5

List and explain two priorities in the work of monitoring.

7.9 MICROSOFT PROJECT


At present, there are several computerized project management information
systems (PMIS) available in the market. The PMIS can also handle calculation of
costs, earned values, variances, generating management reports and so on.
Earlier PMIS packages ran on large, expensive mainframe computers and hence
were used by larger firms only. Now, many PC-based PMIS are available and are
more sophisticated than earlier systems. An example is Microsoft Project. MS
Excel can also be used as a tool for this purpose.

The availability of computerised PMIS has essentially moved project


management computing away from the data processing department to the
project managerÊs desk. This represents a major shift in the management of

Copyright © Open University Malaysia (OUM)


TOPIC 7 SCHEDULING, MONITORING AND CONTROL  145

information. Of all the PMIS software tools, MS Project is being used by about
50% of the organisations all over the world. Details of MS Project are beyond the
scope of this text, but to be more effective, please use the latest version.

MS Project helps to put together a plan of action, fill in and organise all the
details that must be completed in order to achieve the project goal. The software
handles all the activities right from building a new project to preparing project
documentation, tracking progress, analysing costs, assessing the quality of the
project and managing multiple projects.

Currently, the software is Web compatible, thus, enabling easy communication.


Members in any team can view project data with any browser and exchange
information easily, irrespective of their locations. Programs such as text readers
and speech recognition software can be configured easily to work with the MS
Project software.

The software provides different views for tasks and resources along with other
additional views. With the help of these views, the status of tasks, resources and
costs can be easily monitored by generating respective reports and graphs. A
sample screen of the Microsoft Project software is shown in Figure 7.10.

Figure 7.10: A sample screen of Microsoft project software tool

Copyright © Open University Malaysia (OUM)


146  TOPIC 7 SCHEDULING, MONITORING AND CONTROL

ACTIVITY 7.5

Imagine that you are a project manager. Provide suggestions for the
following issues.
(a) Explain how to cut short the total time taken for a project.
(b) How can you bring back out-of-scheduled projects back on target?

Ć Project execution phase needs the largest amount of effort in the project life
cycle. It covers scheduling, monitoring and controls.

Ć Schedules are developed iteratively from the network by trying various


combinations of resources until a satisfactory balance is achieved between
effective and economical use of resources and meeting the required target
dates.

Ć Planning is pointless unless the execution of the plan is monitored. The result
of monitoring could be a deviation which needs to be controlled.

Ć Activities that are too long are better subdivided to make them more
controllable. Similarly, a large project is better to be subdivided to become a
few small ones.

Ć Progress should be measured through project deliverables. You need to


measure progress, as you cannot control something that you cannot measure.

Ć Gantt chart and Critical Path Method are two famous techniques for
scheduling and monitoring project activities.

Ć A Gantt chart can be drawn by plotting into a graph with time duration on
the x-axis, and activities on the y-axis. The chart consists of several horizontal
bars, where each bar represents each activity in the project.

Ć The main advantage of the Gantt chart is the simplicity, to be drawn and to
be understood by ordinary persons.

Ć A major disadvantage of the Gantt chart technique is that it does not show
the interdependence of various activities.

Copyright © Open University Malaysia (OUM)


TOPIC 7 SCHEDULING, MONITORING AND CONTROL  147

Ć Earned value analysis is very useful in a contract situation, whereby, both the
contractor and the client organisation can measure the amount of work done
and, that translates into monetary value.

Ć Budget variance indicates the degree to which actual costs differ from those
planned.

Ć Schedule variance indicates the degree to which the value of completed work
differs from that planned.

Ć Cost variance indicates the difference between the budgeted cost and the
actual cost of completed work.

Ć There are some situations when the project team needs to prioritise to
monitor some aspects over the other.

Ć High-risk activities will be given close attention because they are most likely
to overrun or overspend.

Critical path Microsoft Project


Critical path analysis Project control
Dummy activity Project monitoring
Earned value Project scheduling
Gantt chart Slack

Harvard Business Review (HBR). (2012). HBR Guide to project management.


Boston, MA: Harvard Business School.
Young, T. L. (1994). Planning projects. Kuala Lumpur: Pelanduk Publications.

Copyright © Open University Malaysia (OUM)


Topic  Resources,
8 Teams and
People
LEARNING OUTCOMES
By the end of this topic, you should be able to:
1. State the key players in an IT project management;
2. Identify the role of project managers and project sponsors;
3. Discuss the importance of the chief programmer team;
4. Explain various types of project structure and team organisations;
and
5. Describe the Reverse PeterÊs and PaulÊs management principles.

 INTRODUCTION
A project resource can be any item or person that is needed to run a project. In
the most general term, resources consist of the following categories: people,
equipment, materials, project space, money, time, services and others. Of these
resources, people are the most critical as they are the ones who execute the
project.

This topic will discuss the project resources, with an emphasis on the people and
the team organisation that move the project from beginning until the end. A
project is a temporary organisation that is required to produce the final product
or service. The people have to do it, and they have to be organised in a certain
way.

Copyright © Open University Malaysia (OUM)


TOPIC 8 RESOURCES, TEAMS AND PEOPLE  149

8.1 PROJECT RESOURCES


To accomplish an IT project, you will need resources. However, in more specific
terms, the core resources for IT projects consist of hardware resources, software
resources and human resources. Figure 8.1 illustrates IT project resources as a
pyramid.

Figure 8.1: IT project resources


Source: Pressman (2001)

The hardware and software tools sit at the foundation of the resource pyramid
and they provide the platform to support the development effort. At a higher
level, you can see reusable software components that can dramatically reduce
development costs and accelerate product delivery, if you use them. At the top of
the pyramid is the most important resource ă the people. These three layers of IT
project resources can be further illustrated by Table 8.1.

Table 8.1: Three Broad Categories of IT Project Resources

Types of Resources Description


Hardware Resource This provides the platform that supports the software tools
required to produce the required products such as PC,
Mainframes and OS.
Software Resource This consists of the reusable software components such as
packages, existing codes and specifications and test data.
Human Resource This consists of IT professionals of various types together with
resourceful users who can contribute effectively in projects.

Tools are extremely useful in IT projects. They can speed up a development


process and increase quality of the products. Examples of the tools that can be
used in IT projects are the project management software, software development
tools and configuration management software. An example of the project
Copyright © Open University Malaysia (OUM)
150  TOPIC 8 RESOURCES, TEAMS AND PEOPLE

management software is the MS Project. Another example of the tools is the


CASE tool.

8.2 KEY GROUP PLAYERS


People can be organised into groups which become a distinct set of resources
compared with the individuals. Group players in a project consist of the
following parties shown in Figure 8.2.

Figure 8.2: Key group players

8.2.1 Project Team


IT projects are generally human and knowledge intensive. A typical project
team consists of mostly the system analysts and programmers. There may be a
network specialist, a database administrator (DBA), or even a web designer as
well. Therefore, the most important resource on the majority of IT projects is
personnel.

Members of the IT project teams are highly specialised. They cannot be easily
replaced too. Indeed, people with expertise constitute as much as 80% of the
budget in a typical system development project. The percentage is even more in
a software engineering project, which focuses more on the production of a huge
software system.

8.2.2 User Group


End-users are people who use the system on a regular basis. Their
representatives can tell what is good and unreasonable for other users. Thus,
user group meetings provide a very good forum for the joint review and
appraisal of latest developments within the project. Ideally, at least one
representative from each of the main departments affected by the new system

Copyright © Open University Malaysia (OUM)


TOPIC 8 RESOURCES, TEAMS AND PEOPLE  151

(project) should attend this group meeting, together with the team leaders,
project leaders and the project manager.

User group meetings can identify and resolve a lot of problems. In relation to
the minor problems faced during such meetings, the project manager normally
has the ability to agree on a course of remedial action to resolve the issues
without further authorisation. Most of the problems are really petty and small.

However, this may not be possible for major problems that may significantly
influence the nature of a project and its objectives, budgets or targeted
completion date. Such major problems will require further discussions and
agreements at meetings to be attended by more senior people, such as at the
steering committee meetings.

8.2.3 Steering Committee


Steering Committee is a high-level advisory committee with the power to set
priorities and steer the project in the direction of corporate objectives. The
committee normally meets once in a month for half a day. It reports to the top
management, such as the President. The committee is often chaired by a
member of the top management, such as the Vice-President and Deputy Director
General (for a government department).

The rationale for the formation of a steering committee arises from a need for
decision makers consisting of the customer, fund provider, other resource
provider, the maintenance people, and users who will operate the final product.
Its membership is drawn from the user departments, some or all of the project
leaders, the project manager and members of the senior management who are
responsible for the system development staff, or whose functional areas are
primarily affected by the development in progress.

A typical project steering committee consists of the following parties shown in


Figure 8.3.

Figure 8.3: Project steering committee

Copyright © Open University Malaysia (OUM)


152  TOPIC 8 RESOURCES, TEAMS AND PEOPLE

The committee advises on and makes key decisions. The kinds of decisions
made by the project steering committee are whether the project should start;
whether to move on to the next stage of the project; the allowable tolerances for
a certain stage; unexpected events; and to close a project.

With these kinds of decisions, the key roles of the steering committee are to:
(a) Provide a forum for discussion on major concerns;
(b) Review the current status of the project;
(c) Review deviations from plan and the alternative corrective actions;
(d) Recommend changes to the project to reflect user requirements; and
(e) Provide advice on policy formulation on system operations.

Although the steering committeeÊs function is nominally to provide advice, it


may have real power, and be able to persuade the executive arm of the
management to adopt its recommendations. This would be particularly true if
the members of the senior management responsible for taking the ultimate
decisions participate fully in the work and meetings of the committee. Thus, the
steering committee is a very important resource in project management. Its
presence needs to be realised and exploited fully for projects to develop in a
healthy manner.

A steering committee is a good idea when different partnering companies, units,


or individuals have a strong stake in the project. Because it represents these
various interests, it is well positioned to sort out complicated inter-firm or inter-
departmental project problems. However, the downside of having a steering
committee is that it involves another level of oversight. Its meetings take up the
time of some of the companyÊs most expensive employees (Harvard Business
Review, 2012).

ACTIVITY 8.1

In your opinion, why is it important for the project team and the users to
develop and agree on a process model for a project?

8.3 KEY INDIVIDUAL PLAYERS


Some of the people associated with projects are key individuals who are very
resourceful. They play more important roles than others in terms of project
executions. Key players are project resources that must be recognised and
Copyright © Open University Malaysia (OUM)
TOPIC 8 RESOURCES, TEAMS AND PEOPLE  153

exploited. Their absence could affect project executions and so their positions
need to be created and filled.

Some of the key individual players in a project are listed in Figure 8.4. The
responsibilities of them will be discussed in the next subtopic.

Figure 8.4: Key individual players

8.3.1 Executive Sponsor


The Executive Sponsor (or Project Sponsor) is someone who champions the
project at the highest level in the company and gets rid of organisational
obstacles. He/she needs to have the clout to communicate effectively with the
CEO and the key stakeholders, provide necessary resources and approve or reject
outcomes.

He/she is the key stakeholder who has the overall responsibility for ensuring
that the project meets the expectations of all stakeholders. In addition, this person
must ensure that project objectives are compatible with the organisationÊs
strategy and long-term objectives.

This person is usually placed very high in the organisation hierarchy to provide
credible support and commitment to you in matters of the project. He is therefore
in a position to influence others when resources and other problems are out-of-
control, and to give valuable input on strategic issues (Young, 1994).

8.3.2 Project Manager


Project manager is the person responsible for organising and building the project.
He understands what the customer wants and knows how to fulfil those wants.
He identifies the central problem and determines how to tackle it. He gets inputs
from the sponsor and the key stakeholders.

Copyright © Open University Malaysia (OUM)


154  TOPIC 8 RESOURCES, TEAMS AND PEOPLE

With the projectÊs objectives and the scope, and the activities required, he then
plans and schedules tasks, oversees day-to-day execution, and monitors
progress. Later, he evaluates performances, brings the project to a close, and
captures the lessons learned. The project manager receives authority from the
project sponsor. In many ways, he is just like a traditional manager, but he has a
tight budget and schedule to comply with.

He is given a number of people to help him to execute the project. Thus, he needs
to have a blend of management, human relations and technical skills. A detailed
list of the kind of knowledge and skills needed are given in Table 8.2.

Table 8.2: Knowledge and Skills of a Project Manager

Types of skills Description of knowledge and skills


Management related skills Skills in planning, conflict management, decision-
making, goal setting, leadership skills, team building
and time management.
Technical related skills Knowledge of IT, total quality management (TQM),
earned-value analysis, scheduling methods, problem
solving, analysis of data and concurrent engineering.
Human relations and Skills in negotiation, written-communication, group
related skills dynamics, interviewing, listening skills, oral
communication, coaching and counselling.

8.3.3 Team Leaders


Large projects may include team leaders who report directly to the project
manager. In small projects, the project manager and team leader can be the same
person, in which case, he may be called just a project leader. As the name implies,
a team leader leads a team inside a bigger project.

There can be many teams, such as application development team, system


support team, communication network team and so on. If the application is big,
then the teams can be labelled to reflect specific application areas like accounts
receivable team, accounts payable team, payroll team, inventory management
team and so on.

The main responsibilities of a team leader will be:


(a) Planning and organising the work of team members on a daily or weekly
basis;
(b) Supervising the activities of each member regularly;

Copyright © Open University Malaysia (OUM)


TOPIC 8 RESOURCES, TEAMS AND PEOPLE  155

(c) Providing advice to team members on technical difficulties;


(d) Reporting progress to the project manager or the user group;
(e) Providing feedback to team members on changes made at more senior
levels;
(f) Coordinating interactions with user departments; and
(g) Implementing changes to the planned activities.

SELF-CHECK 8.1

Describe the roles of the following key individual players:


(a) Project sponsor; and
(b) Project manager.

ACTIVITY 8.2

What kind of relationship and reporting arrangements should the


project manager have with the project sponsor?

8.4 TEAM MEMBERS


Besides the group players and the individual key players as discussed above,
there are individuals who need to be mentioned here. The main five team
members of a project are listed in Figure 8.5. Their responsibilities are described
in the next subtopic.

Figure 8.5: Team members of a project

Copyright © Open University Malaysia (OUM)


156  TOPIC 8 RESOURCES, TEAMS AND PEOPLE

8.4.1 System Analysts


These are senior people in the IT profession. They have a good knowledge of
both the business processes and IT. Normally, these people have progressed to
this position through the more technical ranks of computer programming and
system design. They should be skilful in getting and extracting user requirements
and converting them into models for computerisation. Senior system analysts are
qualified to become project leaders and managers (refer to Figure 8.6).

Figure 8.6: A system analyst at work


Source: http://www.ictlounge.com/html/analysis.htm

8.4.2 Programmers
With some exceptions, these people are generally below the level of the system
analysts. Programmers implement the design prepared by the system analysts.
Junior programmers may be working as coding clerks with limited skills, while
senior programmers may have highly developed skills with capability of
working in a variety of programming language environments. They may also
perform significant program design work before coding. The Chief Programmer
is more like a manager who would assign programming jobs to the right persons,
and would help them when they are faced with problems.

8.4.3 Programmer-Analysts
These people normally have a blend of system analysis and programming skills.
They are very useful in projects, which require the same people to do all the
analysis, design and programming jobs together. Thus, cutting the time for inter-
personal communications between system analysts and programmers can save a
lot of time.
Copyright © Open University Malaysia (OUM)
TOPIC 8 RESOURCES, TEAMS AND PEOPLE  157

8.4.4 Database Administrator (DBA)


A database administrator (DBA) is responsible for the smooth operation,
integrity and efficiency of databases present in the company. Databases have
now become very important, and are a strategic IT asset of many organisations.
They need to be designed and looked after very well by a specialist person with
the technical knowledge of database management system (DBMS) technology. A
DBA is basically a system analyst with a specialty in data and related skills.
Figure 8.7 shows some of the main database management systems.

Figure 8.7: Examples of database management systems


Source: http://www.svtuition.org/2013/02/objectives-of-dbms.html

8.4.5 Network Specialist


This person is responsible for the smooth operation of the telecommunications
network in the organisation. Since most of todayÊs IT projects involve some kinds
of network, a network specialist has become more in demand to support and
advice IT department in its daily operations. Thus, his role in IT projects needs
no introduction.

SELF-CHECK 8.2

Name at least four key players in an IT project management.

Copyright © Open University Malaysia (OUM)


158  TOPIC 8 RESOURCES, TEAMS AND PEOPLE

8.5 ASSIGNMENT OF RESOURCES


Resource allocation is time-consuming. At various intervals of the project, as
more assignments are made, you can issue the assignment charts with copies of
the relevant Gantt charts, calendars and other information to the specific
individuals as confirmation of their accepted commitment. With these updated
documents, there is really no excuse for anyone claiming that they do not know
what they are supposed to do.

Once you have determined the peopleÊs resources, activities and their
dependencies, you need to assign resources and responsibilities on to the
activities. On the Gantt chart, this can be achieved by showing a bar for each
resource under each activity that particular resource participates in, even in only
part of a taskÊs duration.

For example, „Produce final copy‰ is the activity schedule for participation
by three persons ă Ali, Abu and Amin. This can be shown on the bar chart in
Figure 8.8.

Figure 8.8: Bar chart of an activity schedule

When jobs and tasks are assigned to the staff, you need to motivate them to work
hard and complete the task on time. Table 8.3 below summarises the ways a
manager can motivate his/her subordinates.

Table 8.3: Ways to Improve Motivation

Ways to Improve Motivation Explanation


Set specific goals These goals need to be demanding and yet acceptable
to staff. Involving staff in the setting of goals helps to
gain acceptance of them.
Provide feedback Not only goals have to be set, but staff members have
to have regular feedback on how they are
progressing.
Consider job design Jobs can be altered to make them more interesting and
give staff a feeling of responsibility.

Copyright © Open University Malaysia (OUM)


TOPIC 8 RESOURCES, TEAMS AND PEOPLE  159

Two measures often used to enhance job design are job enlargement and job
enrichment. Table 8.4 further explains job enlargement and job enrichment.

Table 8.4: Job Enlargement and Job Enrichment

Job Enlargement Job Enrichment


The person doing the job carries out a The jobholder carries out tasks that are
wider variety of activities. It is the normally done at a higher level. With
opposite of increasing specialisation. For programmers in a maintenance team, they
example, a programmer in a maintenance might be given authority to accept
group might be given the responsibility requests for changes, which involve less
for specifying minor amendments as well than five dayÊs work without the need for
as carrying out the actual code changes. their managerÊs approval.

8.6 PROJECT MANAGEMENT STRUCTURE


Project management structure relates to the position of the project manager and
his team vis-à-vis the rest of the company. While team organisation deals with
how to organise the core project teams internally in isolation from the others,
project management structure deals with how to link the project team with the
user department and even the senior management of the company. The structure
provides the big picture in project management. There are three main project
management structures which will be discussed in the following subtopics.

8.6.1 Management Structure I


This management structure places an IT professional to head the project team.
The post is called „Project Manager‰. Normally, the person is a senior system
analyst or an experienced system analyst, depending on the size of the project.
This structure is illustrated diagrammatically in Figure 8.9.

Copyright © Open University Malaysia (OUM)


160  TOPIC 8 RESOURCES, TEAMS AND PEOPLE

Figure 8.9: Management structure I

In this older structure, the project manager reports to the IT Manager, being his
official boss, and to the project sponsor, being his project boss. So, he has to
please two sets of people in the organisation. He will present progress reports of
the project regularly at the steering committee meetings.

The project manager is the key person in this management structure. He is


expected to understand what the users want and to do accordingly. It is fine if
the project is just a simple and straight-forward system. However, he is often
caught in between the users and the sponsor. While the sponsor presses for a
speedier and cheaper solution, the users are not willing to accept a solution that
is not up to their satisfaction.

The advantage of this management structure lies in the fact that the entire
company can delegate most of the work to the project manager. Staff members of
the user departments are not so much affected by the project because the project
manager is supposed to do almost everything, thus, saving many peopleÊs time.

However, the disadvantage of this approach is that the product delivered may
not be satisfactory to the end-users. This situation is quite expected due to the
lack of communication, involvement and participation from the user side. Each
side keeps blaming the other for the shortfalls of the finished product.

Copyright © Open University Malaysia (OUM)


TOPIC 8 RESOURCES, TEAMS AND PEOPLE  161

8.6.2 Management Structure II


This newer management structure places a user manager or the system owner as
the nominal head of the project team. The post is called (nominal) „Project
Manager‰. So, a business person would be leading the project. He is to be
assisted by a resourceful project leader, being an IT professional person, who
would be very competent technically. This structure is illustrated
diagrammatically in Figure 8.10.

Figure 8.10: Management structure II

Key features of the above structure involve the creation of the two positions ă i.e.
the project manager and the project leader, to be explained below (McLeod and
Smith, 1996):

(a) The Nominal Project Manager is a high-ranking user with enough seniority
and clout to get the resources necessary for the project, and makes decisions
when necessary. This person must lend status and priority to the project.
He will not normally be able to devote more than about 30% of his time to
the project, since he will be in a senior line position. He will carry ultimate
responsibility to the organisation for delivering the project results.

Copyright © Open University Malaysia (OUM)


162  TOPIC 8 RESOURCES, TEAMS AND PEOPLE

(b) The Project Leader is normally an IT person who will manage the team on a
daily basis. He will report to the Project Manager (with a dotted line) and to
the IT Management (with a solid line). This person should have senior
status within the IT function, as well as some business knowledge. IT staff
allocated to the project will report to this person directly.

This new structure evolved into reality because most of the business managers
do not feel satisfied with the outcome of projects headed by an IT professional
project manager. Since they are responsible for the budgets, these managers
deserve satisfactory outcomes from the projects that they pay for. Thus, they
have no better alternative. They should be the ones to lead the project, so that
they would be able to precisely implement what they want. In the process, they
would also realise how difficult, or how easy, or how expensive it is to produce
satisfactory results.

With this new arrangement, there is no more reason to be dissatisfied with the
project outcome, for it is the business manager who has managed the IT project.
The technical IT people would simply implement the choice made by the
business people. In this way, poor communication, misinterpretation and
misunderstanding cannot be the cause of poor project performance. Both parties
would now come to realise the importance for them to work together very
closely.

By the year 2000, the Citibank head-office in Kuala Lumpur, Malaysia, was
already having IT project managers with MBA qualifications. One of them
realised the handicap in holding this position. Thus, he enrolled for an
International Higher Diploma programme in computer studies at a local college
in Kuala Lumpur. With this new knowledge and skills, he felt confident in his
job. This shows that Citibank prefers a business person (or a senior person in the
application area) to be the project manager, rather than an IT technical person.
This is consistent with the Management Structure II.

ACTIVITY 8.3

What do you think are the advantages and disadvantages of a project


managerÊs post held by a professional IT person as opposed to that held
by a business (user) manager?

Copyright © Open University Malaysia (OUM)


TOPIC 8 RESOURCES, TEAMS AND PEOPLE  163

8.6.3 Management Structure III


This management structure III looks very much like the structure in Figure 8.3,
but with its relationship with other parties being modified. This structure, as
shown in Figure 8.11, has been adopted by a huge bank in UK, in the 1990s. In
this bank, the Technology Steering Committee is located above the structure
shown in Figure 8.11.

Figure 8.11: IT project management structure of a UK bank

The Project Sponsor was a client of the IT Division. He was responsible for
identifying specific business problems, which required technical solutions. This
person was described as "an internal customer" and would discuss requirements
with a Senior Business Analyst, being a person who was expected to have dual
skills of technical and business awareness.

8.7 PROJECT TEAM ORGANISATION


How do you organise members of a project team? How do you organise
programmers, system analysts and other participants of an IT project? While
projects in general are quite similar, IT projects consist mainly of people with
high expertise and skills.

However, there is no firm guideline on how to choose an organisational structure


for a project team. It is all based on intuition after considering the nature of the
project, the situation, the advantages and the disadvantages of various structures.
Figure 8.12 lists the five main types of project team organisational structure.

Copyright © Open University Malaysia (OUM)


164  TOPIC 8 RESOURCES, TEAMS AND PEOPLE

Figure 8.12: Types of project team organisational structure

8.7.1 Pure Project Structure


Pure project organisation is also known as the hierarchical structure. The
structure is good when speed is of the essence of product development. Many
building construction projects adopt this structure, where unskilled and semi-
skilled people in big numbers are involved. It is fast because of the simple
structure with a strong command throughout the hierarchy. The group leader,
supported by individual members, can give a high focus.

The structure in Figure 8.13 is one form of a pure project organisation.

Figure 8.13: Pure project structure

This structure was adopted in a huge project on „Airline Reservation System‰ at


the Malaysian Airline System (MAS) in the 1970s.

The project was divided into three sections or groups:


(a) System support group;
(b) Reservation group; and
(c) Message-switching group.
Copyright © Open University Malaysia (OUM)
TOPIC 8 RESOURCES, TEAMS AND PEOPLE  165

Each group was headed by a group leader. About 20 IT professionals were


directly involved in this project from beginning till the end. One senior officer of
the user department was seconded into the project to head the reservation group.

The project teams were so highly motivated that no one left the project before it
was completed. Project members were moulded together throughout the project
duration to create a highly focused group. It took 18 months to implement a pre-
customised package supplied by IBM. The original software was written in
assembly language with about 2,000,000 LOCs. It had taken 600 man-years to
develop the original software.

8.7.2 Matrix Structure


A matrix organisation requires the General Manager to head the day-to-day
operations of the company. He has several functional managers dealing with
various functional areas. To launch a project, you need a project manager with a
temporary organisation to be staffed by a number of people inside the company.
Project team members are drawn from various functional departments of the
company with different skill sets. Figure 8.14 shows the organisation of a matrix
structure.

Figure 8.14: Matrix structure

Copyright © Open University Malaysia (OUM)


166  TOPIC 8 RESOURCES, TEAMS AND PEOPLE

The beauty of this organisational structure lies in the fact that another project can
be launched easily and quickly. Thus, you can find another project manager
launching another project with another group of team members. Members of the
team may come from any functional department of the company. Some members
are specialists ă for example, a network specialist who may be sitting inside more
than one project. Thus, not only the specialists, but the project managers may be
involved in more than one project at any one time. However, this organisation
structure can drag on easily, because of the part-time nature of their team
members.

Many computer vendors like IBM, ICL, Fujitsu and others launched their
business projects using the matrix organisation. Often each of their account
managers plays the role of the project manager focusing on one client
organisation. The project needs the participation of various people like system
analysts and programmers who are drawn from other departments. An account
manager normally has several projects at hand trying to sell this and that to his
different clients. Thus, several projects may be running concurrently at any one
time, with many members on a part-time basis.

8.7.3 Centralised Control Structure


The centralised control structure is based on a hierarchical structure. In IT
projects, it is often called the „Chief Programmer Team‰, because of the way the
chief programmer organises his team. Figure 8.15 shows the centralised control
team structure.

Figure 8.15: Centralised control team structure

The „Chief Programmer‰ knows very well the work he is handling. He is an


expert with extensive experience in programming. Therefore, by having junior
programmers reporting to him, he is indeed able to manage and control the
programming project with strong authority. He is the focal point of this job.
Indeed, the job depends almost entirely on him.

Copyright © Open University Malaysia (OUM)


TOPIC 8 RESOURCES, TEAMS AND PEOPLE  167

8.7.4 Decentralised Control Structure


In IT projects, decentralised control structure is also called „Ego-less
Programming Team‰ simply because nobody is in real control of the others. In
contrast with the centralised control team, this is the other extreme way of team
organisation, where programmers share decision-making and report to the
project manager. There is no management hierarchy here. Figure 8.16 shows the
decentralised control organisational structure.

Figure 8.16: Decentralised control structure

8.7.5 Mixed Control Structure


The mixed control structure attempts to combine the benefits and to minimize
the disadvantages of both the centralized and the decentralized control teams.
Thus, features of the centralized control structure and the decentralized control
structure are present as components inside the mixed control structure. How
many of each type and when ă these depend on where each type is better to be
placed.

An example of the mixed control structure is given in Figure 8.17 with a


decentralized control structure component on the left side, and the centralized
control structure component on the right side.

Copyright © Open University Malaysia (OUM)


168  TOPIC 8 RESOURCES, TEAMS AND PEOPLE

Figure 8.17: Mixed Control Structure

8.8 ASSESSMENT OF TEAM ORGANISATION


Based on the previously mentioned team structures, it is clear that some lessons
can be drawn from the above set of team organisations. It appears that the
decentralised control team works best when communication among engineers is
necessary for achieving a good solution. In this organisation, team members
would communicate well since they are equals.

Centralised control is best when speed of development is the most important


goal and the problem is well understood. So, the chief programmer position is a
very well proven job. On a larger project organisation, the hierarchical (pure
project) structure appears to be able to deliver fast results. This is because of the
highly focused nature of the teams and their members.

The matrix structure is very good in the sense that you can start and get the
project organised very quickly. That advantage however can be over-shadowed
by the relative ease that it can slip through the deadlines. The reason for this is
that team members are less committed, as most of them are not assigned on a
full-time basis. Divided focus may be the main reason, but working culture
inside the company too can be another major reason.

Copyright © Open University Malaysia (OUM)


TOPIC 8 RESOURCES, TEAMS AND PEOPLE  169

Importance of Team Size


It is appropriate for organisations to try to limit the amount of communication
between team members for achieving the project goals ă neither more nor less.
Thus, a very large team is highly discouraged, as more time would be spent on
talking. On the contrary, a very small team may not be productive for lacking the
synergy between members. A project team of five or six members is considered
very appropriate for this purpose.

Table 8.5 illustrates the idea of the optimum team-size. It is assumed that
individual productivity is 500 Lines of Code (LOC) per man-month. The
productivity loss is assumed to be 10% per communication link. Thus, with full
interaction between team members, this results in an optimum team size of 5.5
persons. It simply means that the best team size is theoretically 5.5 persons ă i.e.
either 5 persons or 6 persons. With 5.5 persons, the group productivity is 1512,
which is even higher than those achieved by 5 persons or 6 persons.

Table 8.5: Impact of Team Size on Productivity

Team Size Individual Productivity Group Productivity


1 500 500
2 450 900
3 400 1200
4 350 1400
5 300 1500
5.5 275 1512
6 250 1500
7 200 1400
8 150 1200

Source: Vliet (1993)

8.9 OTHER GOALS AND STRATEGIES


Besides the speed of development, there are also other goals that are equally
important to be achieved. These other goals are:
(a) Lower life cycle cost ă which covers development and maintenance;
(b) Reduced personnel turnover ă by ensuring staff satisfaction in life;
(c) Repeatability of the process ă to enable it to be repeated in future;

Copyright © Open University Malaysia (OUM)


170  TOPIC 8 RESOURCES, TEAMS AND PEOPLE

(d) Development of junior software engineers into senior ones ă through


training; and
(e) Wide-spread dissemination of knowledge and expertise.

A typically small project team is made up of a project leader, system analysts,


programmers and a user representative. A larger project organisation may
consist of a project manager, project leaders, team leaders and team members.
The project director may head a very large project such as the Kuala Lumpur
International Airport (KLIA) project. The KLIA project included many
components ă e.g. civil engineering, electrical engineering, IT and others. Thus,
the IT project was just one component in that very large project that Malaysia
had undertaken.

In IT project management it is better to adopt a strategy of using fewer and better


people to achieve the highest productivity. IT projects are knowledge-intensive.
More people getting involved means more communication is required to
transmit understanding. If one person leaves in the middle of a project, the job
cannot be replaced easily, because of the missing link. Thus, important project
members need to be assured that they would not leave the project before it is
completed.

Similarly, a shorter duration project is better than a longer one. This is because of
the fact that a short duration is less exposed to staff resignation and other project
risks. Thus, if possible, it is better to compress a project by putting in more
resources that can shorten the time taken. Alternatively, it is often better to trim
down (or break down) a large project to make it smaller, or to create two small
projects instead of one large project.

Then try to fit tasks in terms of peopleÊs capability and motivation. To do


otherwise would frustrate the project participants. Thus, excellent programmers
may be promoted to a newly created post with higher technical areas, instead of
promoting him to a managerial position, which he may dislike. It is glamorous to
get a managerial position, but it is frustrating to be unable to perform.

Next is not to pursue the Reverse Peter Principle, which states that people rise
within an organisation to a level at which they become indispensable. That
would be lucky for the person concerned as he is in great demand inside the
company. However, it would be unlucky for the company, as the person cannot
be easily replaced in case he leaves the company one day.

It is also not advisable to pursue the Paul Principle, which states that people rise
in an organisation to a level at which their expertise becomes obsolete within five
years. Technological change causes this possibility, and every effort needs to be
Copyright © Open University Malaysia (OUM)
TOPIC 8 RESOURCES, TEAMS AND PEOPLE  171

taken to ensure that staff threatened by this danger should undergo re-training,
either at companyÊs expense or on his own.

Finally, select people for a well-balanced and harmonious team in terms of


expertise. Project team members must play in a team. Therefore, remove
someone who does not fit into the team.

SELF-CHECK 8.3

Describe the following principles briefly.


(a) Reverse PeterÊs principle; and
(b) PaulÊs principle.

ACTIVITY 8.5
Visit one IT company. Interview one of the project team members to
find out how the project team organise themselves.

Ć The core resources for IT projects consist of hardware resources, software


resources and human resources.

Ć Key group players in a project consist of project team, user group and
steering committee.

Ć Steering Committee is a high-level advisory committee with the power to set


priorities and steer the project in the direction of corporate objectives.

Ć Project manager is the person responsible for organising and building the
project. The project manager receives authority from the project sponsor. In
many ways, he is just like a traditional manager, but he has a tight budget
and schedule to comply with.

Ć There are two main IT project management structures: one structure is led by
an IT person, while the other is led by a business person.

Copyright © Open University Malaysia (OUM)


172  TOPIC 8 RESOURCES, TEAMS AND PEOPLE

Ć IT project team organisations can take many forms: the pure project structure,
the matrix structure and several other structures.

Ć The matrix structure is very good in the sense that you can start and get the
project organised very quickly.

Ć Pure project organisation is also known as the hierarchical structure. The


structure is good when speed is of the essence of product development.

Ć In IT project management, it is better to adopt a strategy of using fewer and


better people to achieve the highest productivity.

Ć The Reverse Peter Principle states that people rise within an organisation to a
level at which they become indispensable.

Ć The Paul Principle states that people rise in an organisation to a level at


which their expertise becomes obsolete within five years.

Centralised control team Project management structure


Decentralised control team Project resources
Job enlargement Project team organisation
Job enrichment Pure project structure
Matrix structure Reusable software
Paul Principle Reverse Peter Principle

Harvard Business Review (HBR). (2012). HBR Guide to project management.


Boston, MA: Harvard Business School.
McLeod, G., & Smith, D. (1996). Managing information technology projects.
Danvers, MA: Thomson.
Pressman, R. S. (2001). Software engineering: A practitionerÊs approach (5th ed.).
Boston, MA: McGraw-Hill International.

Copyright © Open University Malaysia (OUM)


TOPIC 8 RESOURCES, TEAMS AND PEOPLE  173

Vliet, H. V. (1993). Software engineering: Principles and practice. New York, NY:
John Wiley & Sons.
Young, T. L. (1994). Planning projects: 20 steps to effective project planning.
Kuala Lumpur, Malaysia: Pelanduk Publications.

Copyright © Open University Malaysia (OUM)


Topic  Suppliers and
9 Contractors

LEARNING OUTCOMES

By the end of this topic, you should be able to:


1. Identify the areas for IT contracts;
2. List the types of contracts in the field of IS/IT;
3. Identify the cycles in the process of contracting;
4. State the common methods of acquisition in the solicitation cycle; and
5. Select a suitable type of contract for a website development project.

 INTRODUCTION
Suppliers are contractors in the general sense of the word. They supply goods
and services, including manpower, based on certain terms and conditions.
Suppliers provide goods and services based on the requirements specified in the
competitive bids issued by the client organisation. Alternatively, they are
supplied through direct contract negotiations between the contractor and the
client. This topic will discuss all of these issues including many types of contracts
that can take place in IT and other related projects.

9.1 USING SUBCONTRACTORS


In IT project situations, a client organisation can be a company (or just a
department inside a company) that needs IT products and services. The client
makes a request to get this IT job done, certainly, by someone from outside of the
organisation. Once the product, system or service is done, the client will be the
owner of the system, product or services. Thus, the client gets a new IT asset of

Copyright © Open University Malaysia (OUM)


TOPIC 9 SUPPLIERS AND CONTRACTORS  175

considerable value to the organisation. They are called clients because they are
customers to the contractors.

The outside party (or organisation) that performed this job is the contractor. The
contractor secured this job, completed it, and handed the system (product) over
to the client. There was an agreement to be signed between the contractor and the
client organisation. The contractor can be an IT department within the same
company, or even an outside organisation specializing in IT consultancy services.

The organisation that secured this job is called the contractor, or the prime
contractor. Subcontractors are the contractors to the prime contractor. There can
be many subcontractors providing services and hardware products to the prime
contractor. Alternatively, the client organisation can act like a prime contractor
by calling a number of suppliers and contractors separately ă but a client should
not be called a contractor, otherwise confusion may occur.

There are many contract jobs that you can think of. For example, in the IT
industry, the following situations require a contract between two parties:
(a) The IT project ă This whole project could be a contract job offered by an
organisation to an IT consultancy company. If you are managing this kind
of project, then you are managing a contracted work.
(b) Programming ă If your organisation has the personnel resources of a
project manager and systems analysts, but not enough programmers, then
you can engage contract programmers. The entire programming work can
be outsourced.
(c) Network communications ă If your organisation does not have a network
specialist to handle the communication work, you can outsource this
portion of the job to do the cabling and other specialized works in the field.
(d) Data entry ă If your organisation does not have enough manpower to enter
voluminous data to fill up your new database, then you can contract out
this portion of the job to outside companies.
(e) IT provision ă Some organisations decide to outsource the entire IT
provision that was originally handled by their IT departments. Thus, the IT
departments can be closed. The organisations can then focus on their core
and strategic processes.
(f) General suppliers ă These parties may sign a contract with your
organisation in the supply of paper, ink, cables, computer forms and many
others. Traditionally, this kind of supplier comes from the outside.

In the business environment, and during a competitive bidding process,


prospective clients are always concerned about one bid being much lower than
Copyright © Open University Malaysia (OUM)
176  TOPIC 9 SUPPLIERS AND CONTRACTORS

the others. The client may question the validity of the hidden unit, that is,
whether the contract can be achieved with the low bid. In cases such as this, the
client usually imposes incentive and penalty clauses in the contract for self-
protection.

Because of the risk factor, competitors must negotiate not only for the target cost
figures, but also for the type of contract involved, since risk protection is the
predominant influential factor. The size and experience of the clientÊs own staff,
urgency of completion, availability of qualified contractors, and other factors
must be carefully evaluated. The advantages and disadvantages of all basic
contractual arrangements must be recognised to select the optimum arrangement
for a particular project.

SELF-CHECK 9.1

1. Why are contracts very important to organisations?


2. List and explain five different areas that require contracts in the IT
industry.

ACTIVITY 9.1

Can we rely on a contract to distinguish a projectÊs scope and


objectives? Why?

9.2 THE PROCESS OF CONTRACTING


There are five cycles associated with the contracting system, especially for large
projects in large organisations. They are:
(a) Requirement cycle ă the process of specifying the requirements;
(b) Requisition cycle ă the process of making the request;
(c) Solicitation cycle ă the process of inviting potential contractors or bidders;
(d) Award cycle ă the process of giving out the contract; and
(e) Contract administration cycle ă the process of managing the contractors.

Copyright © Open University Malaysia (OUM)


TOPIC 9 SUPPLIERS AND CONTRACTORS  177

9.2.1 Requirement Cycle


Requirement cycle provides the definition of the clientÊs requirements. It specifies
the boundaries of the project that covers the following points:
(a) Defining the needs for the project;
(b) Specifying the statement of work and the work breakdown structure;
(c) Performing a make or buy analysis;
(d) Laying out the major milestones, the timing and the schedule;
(e) Cost estimating, including development and maintenance cost; and
(f) Obtaining authorisation and approval to proceed.

9.2.2 Requisition Cycle


Once the requirements are identified, a requisition form is sent to procurement
department to start making the request. The procurement department evaluates
the request and analyses the sources of supply. This is called the requisition cycle.

The requisition cycle includes:


(a) Evaluating the specifications (e.g. whether they are current);
(b) Confirming sources;
(c) Reviewing past performance of sources; and
(d) Producing solicitation package.

The solicitation package is prepared during the requisition cycle but utilised
during the solicitation cycle. In most situations, the same solicitation package
must be sent to each prospective supplier to ensure a level playing field.

A typical solicitation package would include the following information shown in


Figure 9.1.

Figure 9.1: Content of a typical solicitation package


Copyright © Open University Malaysia (OUM)
178  TOPIC 9 SUPPLIERS AND CONTRACTORS

Bidding documents usually include standard forms for compliance with certain
standards. A listing of qualified vendors appears in order to drive down the cost.
Quite often, one vendor will not bid on the job because it knows that it cannot
submit a lower bid than one of the other vendors. Thus, the cost of bidding on a
job is an expensive process.

Bidder conferences are used so that no single bidder has more knowledge than
others. If a potential bidder has a question concerning the solicitation package,
then it must wait for the bidder conference to ask the question so that all bidders
will be privileged to the same information. This is particularly important in
government contracting. There may be several bidder conferences between
solicitation and award. Project management may or may not be involved in the
bidder conferences.

9.2.3 Solicitation Cycle


Solicitation means asking earnestly, pleading or making appeals. Therefore,
solicitation cycle refers to the ways of getting contractors or bidders to come and
get the job. Selection of the acquisition method is the critical element in the
solicitation cycle.

There are three common methods for acquisition as shown in Figure 9.2.

Figure 9.2: Methods for acquisition

Now, let us look at these methods for acquisition in more detail.

(a) Advertising (for open biddings)


Advertising is when a company goes out for sealed bids. There are no
negotiations. Competitive market forces determine the price and the award
goes to the lowest but credible bidder. Vendor with the most convincing
proposal too may be considered, depending on the flexibility of
specification given to the bidders.

Copyright © Open University Malaysia (OUM)


TOPIC 9 SUPPLIERS AND CONTRACTORS  179

(b) Negotiation (for closed biddings)


Negotiation is sometimes called a negotiated tender or closed tender. In this
case, the tender is not open to all parties. Only a small number of selected
bidders are invited to bid. The price is determined through a bargaining
process.

In such a situation, the client organisation may go out for a:


(i) Request for information (RFI);
(ii) Request for quotation (RFQ); and
(iii) Request for proposal (RFP).

(c) Small purchases (for office supplies)


Small purchases are meant for office supplies only. Examples are paper,
pencils, pens, computer ribbons and ink. Normally, office supplies are not
acquired through tenders or direct negotiations as the amounts are quite
small. What normally happens is that they have established suppliers based
on past experience. These suppliers have been chosen and retained based
on their past performances such as reasonable prices, acceptable quality
and reliability.

9.2.4 Award Cycle


Award cycle refers to awarding the contract to the winning or chosen party. In
other words, the contract is offered to the company that has demonstrated its
ability to perform at the most attractive price.

It should be noted that price is normally the most important criteria for success ă
being the cheapest offer to meet clients stated requirements. But, other criteria
are also important ă e.g. the ability of the contractor based on history and the
project team; the ability to complete early; and others. The successful company
would be informed of the projectÊs outcome, and would be asked to start the
project immediately.

9.2.5 Contract Administration Cycle


Contract administration cycle refers to the process of managing the contractors.
Firstly, the client' organisation must record the list of suitable contractors so that
they are not missed out in any search for suppliers and contractors in future.

In any contract, or supply of materials and services, there must be a kind of


written contract between seller and buyer. So secondly, the organization must
Copyright © Open University Malaysia (OUM)
180  TOPIC 9 SUPPLIERS AND CONTRACTORS

have a standard written contract supposed to be ready all the times to serve as an
example to start with. Detail contract would have to be finalised on a case-by-
case basis according to the coverage of the contract work.

A lawyer is normally involved in the final document of the contract ă this could
be a legal office inside the company, or else an outside legal practitioner is
needed. The client organisation should handle the contractor carefully by
holding proper meetings and giving them sufficient information at the right
times and places. Otherwise, the relationship would suffer and the contract
would not flow smoothly.

SELF-CHECK 9.2

1. List and explain briefly the five cycles of contracting systems.


2. List the three common methods of acquisition.
3. What output will the contractor provide through the award cycle?

9.3 REQUESTS FOR PROPOSALS (RFP)


Do you know what a Request for Proposal is? Now let us know more about it.

Request for Proposal (RFP) is a document given to selected vendors (suppliers)


after functional specifications have been developed for hardware, software or
an application system.

The RFP contains:


(a) The specifications;
(b) Instructions on how the vendor (supplier) is to reply to the RFP; and
(c) The criteria the client organisation will use in evaluating proposals.

RFP can be a binary type or a value type. The binary type of RFP results in a GO
or NO-GO decision. That is, the proposal either meets the criteria set forth in the
RFP or it does not. The value type of RFP, which is generally more useful, results
in the grading of responses. Each proposal is rated on a point system and the
proposal with the highest value selected.

Copyright © Open University Malaysia (OUM)


TOPIC 9 SUPPLIERS AND CONTRACTORS  181

RFP are useful for four reasons:


(a) The analysis needed to prepare the RFP clarifies functional requirements
and decision criteria by which alternatives should be judged. Questions
asked by vendors also help in this process;
(b) The RFP injects a degree of objectivity into the selection process that is
generally not present in a less formal approach. This translates into a
stronger justification for the components that are ultimately selected;
(c) Because the RFP forces a consistent, organized game plan, it ultimately
saves time in the selection process, even though time must be spent to
develop the RFP; and
(d) The RFP is the most effective way to organize competitive bidding.

The RFP process consists of the five stages listed in Figure 9.3.

Figure 9.3: RFP process

Preparation consumes about 50% of the total time. Vendors meetings, telephone
calls and other supporting activities consume about 10%. The selection process
usually takes 30-40% of the total time.

9.3.1 Preparing RFP


Preparation of the RFP requires the development of functional specifications,
vendor instructions and the procedures to be used in evaluating vendor
proposals.

Functional specifications include the following:


(a) System requirements;
(b) Technical constraints e.g. compatibility with specified hardware and
software;
(c) Performance requirements;
(d) Development and installation schedules; and
(e) A glossary if vendors are not likely to be familiar with the terminology.

The functional specification section is the key element of the RFP. Unless the
language and concepts are clear to vendors, an intelligent response will not be
Copyright © Open University Malaysia (OUM)
182  TOPIC 9 SUPPLIERS AND CONTRACTORS

possible. It is particularly important to remember that vendors may not be


familiar with application or industry-specific terminology. Therefore, its use
should be avoided whenever possible.

Vendor instructions explain the mechanics of the bidding process and the
contractual arrangements that will be required. The purchasing, contract
administration and legal departments should participate in their development.

Vendor instructions include the following:


(a) Contract provisions that must be included by the vendor in order to be
responsive to the RFP;
(b) Dates by which proposals are due;
(c) The required format for the proposal. This is important because, if each
response is in a different format, comparisons are very time consuming;
(d) The names, business addresses and/or business telephone numbers of
people that can answer vendor questions; and
(e) Expected proposal contents, i.e. the information that must be included in
the proposal in order for it to be considered responsive. This will probably
include background information on the vendor, and a detailed account of
the solutions the vendor proposes in response to the specification.

The evaluation procedure section describes the methodology that will be used to
evaluate vendor proposals. It specifies the minimum criteria vendor proposals
will be expected to meet in order to be considered responsive, the schedule that
will be followed in making evaluations and planned agendas for meetings that
will take place during the selection process.

9.3.2 Identifying Vendors


Many trade journals and other sources of information exist on vendors of ICT
products and services. These sources can suggest vendors that are likely to offer
the kinds of components that will satisfy the RFP. The selected vendors, usually
10-12, can then be contacted and asked to provide information about their
products. After a review of this information, the RFP should be delivered to the
most likely candidates.

The selection of potential vendors should be done primarily through a review of


the literature. Contact with salesperson should be avoided at this time. It is easy
to be manipulated by persuasive salesperson into prematurely attending
demonstrations and becoming involved in other sales activities that are best left

Copyright © Open University Malaysia (OUM)


TOPIC 9 SUPPLIERS AND CONTRACTORS  183

to a later stage of the selection process. The stress at this stage should be to
review information, not to mingle with vendors.

Shortly after receipt of the RFP, a pre-proposal conference may be held. This is a
formal presentation to selected vendors followed by a question-and-answer
period. The purpose of the pre-proposal conference is to familiarise vendors with
the organisation and to outline the contents of the RFP. A pre-proposal
conference is particularly useful when complex specification or contractual
arrangements are contained in the RFP.

9.3.3 Evaluating Proposals


The evaluating process begins after potential vendors have been identified, the
RFP has been distributed and responses have been received. The selection criteria
developed as part of the RFP are applied to the proposals and are supported by a
variety of tools. A numerical value is usually assigned to the degree of success
each vendor exhibits in satisfying the criteria. Invariably, however, formal
responses do not tell the whole story. Therefore, a series of follow-up meetings,
presentations and site visits to the vendorsÊ customers are needed.

The number of vendors that satisfy most provisions of the RFP, by this time, has
usually shrunk to five or six. A series of presentations clarifying vendorsÊ
capabilities and explaining, in greater details, how they propose to meet the
terms of the RFP are now held. The process continues until a final decision is
made.

9.4 NEGOTIATING THE CONTRACT


Negotiating the contract is the final detail before the contract is awarded to the
successful bidder. During this final negotiation, fine-tuning is done on the details
of items, the total price and the schedule based on the quotation already
tendered.

There are several types of contracts and the award cycle results in a signed
contract. The negotiation process includes selecting the right type of contract.

There are certain basic elements in most contracts:


(a) Mutual agreement ă there must be an offer and acceptance;
(b) Consideration ă there must be a down payment; and
(c) Contract capability ă the contract is binding only if the contractor has the
capability to perform the work.
Copyright © Open University Malaysia (OUM)
184  TOPIC 9 SUPPLIERS AND CONTRACTORS

The final contract is usually referred to as a definitive contract, which follows


normal contracting procedures such as the negotiation of all contractual terms,
conditions, cost and schedule prior to initiation of performance. Unfortunately,
negotiating the contract and preparing it for signatures may require months of
preparation.

However, if the customer needs the work to begin immediately, then the
customer (client) may provide the contractor with a letter of intent. This letter is a
preliminary written instrument authorizing the contractor to begin work
immediately. The final contract price may be negotiated after performance
begins, but the contractor may not exceed the face value of the contract. The
definitive contract must still be negotiated.

ACTIVITY 9.2

1. What output will the contractor provide through the award cycle?
2. When does the negotiation process normally take place between a
contractor and the client organisation?

9.5 TERMS OF CONTRACT


A contract is a formal agreement between two parties whereby one party (the
contractor) obligates itself to perform a service, while the other party (the client)
obligates itself to do something in return, which is usually in the form of a
payment to the contractor. Indeed, a contract is more than just an agreement
between two parties. It is a codification of the private law, which governs the
relationship between the parties to it. It also defines the responsibilities, spells
out the condition of its operations, defines the rights of the parties in relationship
to each other, and grants remedies to a party if the other party breaches its
obligations.

Bunni (2005) describes a contract as simply an elaborated agreement between


two or more parties. It can be more than two parties, whereby, one or more
parties (the contractor) provide products and services in return for something
like payment by other parties (the client). So in the end, there would be two
groups ă the contractors and the clients.

Usually, the type of contract used for project engagement varies depending on
the type of the system solutions and the nature of the industry. Gatti (2013) says
that the contract type is the key relationship between the parties engaged in the

Copyright © Open University Malaysia (OUM)


TOPIC 9 SUPPLIERS AND CONTRACTORS  185

project. One type implies a kind of relationship which differs from the other
kind. Besides that, the contract type also determines the project risk.

Project contracts are a means of deflecting risks, usually away from the client, to
the contractor. Figure 9.4 illustrates a triangular diagram showing the reciprocal
risk between a client and a contractor. All the key words above the descending
line in Figure 9.4 refer to the different types of contracts.

Figure 9.4: Contract risk

Details of these types of contracts will be discussed in the next section. Whatever
the type of contract is signed between the client and the contractor, the following
terms and issues are normally part of the contract:
(a) Retention money;
(b) Bond; and
(c) Insurance.

Let us learn more about these elements.

(a) Retention
The client retains a percentage of the contractorsÊ income against the
contractor failing to complete their contractual obligations. The retention is
usually 10% of the monthly progress payments until it reaches 5% of the
contract value and then it is held until the end of the warranty period.

Copyright © Open University Malaysia (OUM)


186  TOPIC 9 SUPPLIERS AND CONTRACTORS

(b) Bond
The contractor offers the client a bond through a bank. The bond could be
held against lack of performance or poor quality of work. If the contractor
fails to perform, the client is compensated by the bond company which in
turn will take the agreed upon assets from the contractor to cover the bond.
Some contractors prefer this arrangement compared to retention, as they
are paid their progress claims in full, thus improving their cash-flow.

(c) Insurance
A third party accepts insurable risks for the payment of a premium. The
premium is now the quantified impact of this risk on the project. Insurance
could cover:
(i) Direct property damage;
(ii) Indirect consequential loss (business interruption);
(iii) Legal liability; and
(iv) Personnel liability.

9.6 TYPES OF CONTRACTS


There are many types of contract, but only the following six will be explained
briefly here. Some of them will be explained further in subsequent subtopics. The
six are:
(a) Fixed price contract;
(b) Cost plus contract;
(c) Unit rates contract;
(d) Turnkey contract;
(e) Partnership contract; and
(f) BOOT contract.

Now, let us learn further about these types of contracts:

(a) Fixed Price Contract


This is also called lump sum price. This contract requires the contractor to
complete the scope of work for a fixed price, which is written into the
contract. This contract will include all the costs associated with labour,
materials, plant, inflation and risk.

Copyright © Open University Malaysia (OUM)


TOPIC 9 SUPPLIERS AND CONTRACTORS  187

A detailed scope of work is required from the client before the contractor
can tender. This effectively prevents fast tracking between design and
construction. Once the project has started, any changes in the scope of work
will have to be negotiated. This type of contract is becoming more popular
among clients because it passes much of the project risk onto the
contractorÊs side. The client, in the form of an escalation clause, however
often accepts the risk of inflation.

(b) Cost-Plus Contract


Also called the reimbursable, plus-fee contract, the cost-plus contract is
considered to be the most flexible as the client pays all the direct costs to the
contractor plus an agreed fee or percentage profit. This type of contract is
often used at the beginning of a project when there may be many design
changes, requiring close client/contractor liaison, thereby allowing work to
proceed while the details are still being discussed. Once the scope of work
is finalized the type of contract may change, for example, the Channel
Tunnel contract changed from cost-plus to a fixed price.

Cost-plus contracts are usually criticized on the grounds that the contractor
has little incentive to control costs and increase productivity, since their fee
is proportional to the total cost of the project. It is therefore up to the client
to closely monitor the contractorÊs performance.

(c) Unit Rates Contract


Also called billed rates, parameter costs or schedule of rates. This type of
contract works on the basis of negotiated rates for specific work. All
payments will be based on measurement of the work completed using the
unit rates. At the tender stage the quote will be based on a bill of material
(BOM). This type of contract is suitable for projects where the client cannot
supply sufficient data for the contractor to give a lump sum quote. Thus the
client can start their project sooner than a lump sum price and design the
project progressively.

Even on a fixed price contract, unit rates can be agreed at the outset as a
framework for costing additional work. Unit rates do offer the contractor an
incentive to maximize their profits through efficiency. The client will be
responsible for the measurement of the work done, which can be integrated
with the planning and control function. This type of contract is appropriate
for projects where the scope of work cannot be defined at the tender stage ă
e.g. maintenance and ship repair projects.

Copyright © Open University Malaysia (OUM)


188  TOPIC 9 SUPPLIERS AND CONTRACTORS

(d) Turnkey Contract


This is also known as the design and construct contract. Here the contractor
is responsible for the project, from the design phase right through to the
commissioning phase. This reduces the clientÊs input to a minimum while
contractually ensuring that the contractor is responsible for making the
project or facility operational.

The contractor takes the undivided responsibility for the design and
construction of the project, which invariably leads to a pure lump sum
principle, but in practice, this is rarely the case due to variations caused by
employer (client) interference as the project proceeds. As a general rule, the
more expertise the employer (client) has, the more likely they are to
interfere!

(e) Partnership
This is also called a joint venture. Both the client and the contractor share
the risks and benefits of the project.

(f) BOOT Contract


BOOT contract stands for Build, Own, Operate and Transfer. It is also
sometimes called:
(i) BOT contract (Build, Operate and Transfer);
(ii) ROT contract (Refurbish, Operate and Transfer); or
(iii) PPP (Public Private Partnership).

It transfers the risk completely to the contractor, not only to design and
build a facility, but also to finance the building and operation of the facility.
The contractor then operates the facility for a period of time and charges the
users for the product. For example, a contractor, or consortium would build
and operate a power station for 25 years, during which time they will
charge their customers for the electricity and this income will pay for the
building of the facility. It is also often used for toll roads, railways, bridges
and tunnels.

9.7 FIXED PRICE CONTRACT


This is the simplest type of all contracts of which the terms are quite straight-
forward and easy to understand (Ould, 1999). This is a contract that is fixed in
price as agreed by the contractor (supplier) and the client organisation. Within
this agreement there could be a level of risk passed over. However, this risk will
be incorporated into the price by the contractor and agreed by the client. With

Copyright © Open University Malaysia (OUM)


TOPIC 9 SUPPLIERS AND CONTRACTORS  189

this type of contract, it would be the contractorÊs responsibility to absorb any


issues or risk. The main advantage of this type of contract is that the contractor
knows the total project cost before the project commences.

Symes (2005) concludes that a fixed-price contract gives both the contractor and
client a predictable scenario, offering stability for both during the duration of the
contract. The client may be worried about the cost of a good or service suddenly
increasing, adversely affecting project plans. The contractor too may be worried
about the value of the finished goods or services dropping suddenly without
warning. A client may also benefit from the predictability of a fixed-price
contract, since any degree of uncertainty on the final cost of the project exceeding
initial estimates shifts entirely to the contractor.

While a fixed-price contract gives a contractor more predictability of the future


costs of the goods or service negotiated in the contract, this predictability may
come with a price. The contractor may realise the risk that he is taking by fixing a
price and so will charge more than he would on a regular basis to account for the
greater risk to him.

When market forces change the value of a goods or service, including any
materials or supplies necessary in the production of the goods or service, the
fixed-price contract can be a benefit or a detriment. If market forces cause the
value of the goods or service to increase dramatically, the client receives a benefit
while the contractor loses potential profits.

Even though a fixed-price contract may cost a client more money up front, the
client has the ability to budget for the costs of the contract and ensure that it has
enough funds to fulfil its end of the agreement. When the costs of the goods or
service increase dramatically, the contractor may no longer have the means to
honour the contract, meaning that the contractor must take a loss and weigh the
option of legal action.

In a fixed-price or lump-sum contract, the contractor must carefully estimate the


target cost. The contractor is required to perform the work at the negotiated
contract value. If the estimated target cost was low, the total profit is reduced and
may even vanish. The contractor may not be able to underbid the competitors if
the expected cost is overestimated. Thus, the contractor assumes a large risk.

This contract provides maximum protection to the owner for the ultimate cost of
the project, but has the disadvantage of requiring a long period for preparation
and adjudications of bids. Also, there is the possibility that because of a lack of
knowledge of local conditions, all contractors may necessarily include an
excessive amount of contingency. This form of contract should never be

Copyright © Open University Malaysia (OUM)


190  TOPIC 9 SUPPLIERS AND CONTRACTORS

considered by the owner unless, at the time bid invitations are issued, the
building requirements are known exactly. Changes requested by the owner after
a contract on a lump sum basis has been awarded, may lead to troublesome and
sometimes extra costs.

9.7.1 Fixed-Price-Incentive-Fee
Besides the pure lump sum (fixed price) contract, there is also the fixed-price-
incentive-fee contract. This is the same as a fixed-price contract except that it has
a provision for adjustment of the total profit by a formula that depends on the
final total cost at completion of the project and that has been agreed on in
advance by both the owner (client) and the contractor. For this type of contract,
the project or contract requirements must be firmly established. This contract
provides an incentive to the contractor to reduce costs and therefore increase
profit. Both the owner and contractor share in the risks and savings.

9.7.2 Guaranteed Maximum-Share Savings


It is also possible that the contractor is paid a fixed fee for his profit and
reimbursed for the actual cost of engineering, materials, construction labour and
all other job costs, but only up to the ceiling figure established as the „guaranteed
maximum‰. Savings below the guaranteed maximum are shared between owner
and contractor, whereas the contractor assumes the responsibility for any
overrun beyond the guaranteed maximum price. This is called the „guaranteed
maximum-share savings‰ contract.

This form of contract essentially combines the advantages as well as a few of the
disadvantages of both lump sum and cost-plus contracts. This is the best form of
a negotiated contract because it establishes a maximum price at the earliest
possible date and protects the owner from being over-charged, even though the
contract is awarded without competitive tenders. The guaranteed maximum-
share savings contract is unique in that the owner and contractor share the
financial risks and both have a real incentive to complete the project at the lowest
possible cost.

9.8 COST-PLUS CONTRACT


Traditionally, the cost-plus-fixed-fee (CPFF) contract was employed when it was
believed that accurate pricing could not be achieved any other way. In the CPFF
contract, the cost may vary but the fee remains firm. This is because in a cost-plus
contract, the contractor agrees only to use his best efforts to perform the work.
Good performance and poor performance are, in effect, rewarded equally. The
Copyright © Open University Malaysia (OUM)
TOPIC 9 SUPPLIERS AND CONTRACTORS  191

total dollar profit tends to produce low rates of return, reflecting the small
amount of risk that the contractor assumes. The fixed fee is usually a small
percentage of the total or true cost. The cost-plus contract requires that the
company books be audited.

With this form of contract the engineering-construction contractor bids a fixed


dollar fee or profit for the services to be supplied by the contractor with
engineering, materials, and field labour costs to be reimbursed at actual cost. This
form of bid can be prepared quickly at a minimal expense to the contractor and is
a simple bid for the owner to evaluate. Additionally, it has the advantage of
establishing an incentive to the contractor for quick completion of the job.

If it is a cost-plus-percentage-fee (CPPF) contract, it provides maximum flexibility


to the owner and permits owner and contractor to work together cooperatively
on all technical, commercial, and financial problems. However, it does not
provide financial assurance of ultimate cost. Higher building costs may result,
although not necessarily so, because of the lack of financial incentive to the
contractor compared with other forms. The only meaningful incentive that is
evident today is the increased competition and prospects for follow-on contracts.

The cost-plus-incentive-fee contract is the same as the cost plus contract except
that it has a provision for fee adjustments as determined by a formula that
compares the total project cost to the target cost. This formula is agreed to in
advance by both the owner and contractor. This contract is usually used for long-
duration or R&D type projects. The company places more risk on the contractor
and forces him to plan ahead carefully and to strive to keep costs down.

SELF-CHECK 9.3

List and explain five types of contracts.

9.9 TIME AND MATERIAL BASIS CONTRACT


In this kind of contract, the contractor is paid based on the time spent and the
cost of materials being used. The cost of materials is known from the supplier
which can be paid back easily, while the time spent is paid at the rate specified
by the contractor. So, the contractor needs to give a quotation on the rate of the
consultantÊs time before starting the contract.

Copyright © Open University Malaysia (OUM)


192  TOPIC 9 SUPPLIERS AND CONTRACTORS

ACTIVITY 9.2
1. Have you ever been involved in a contract? Are there any other
types of contracts than what you have read in this topic? If so, how
different are those contracts?
2. Which contract type is suitable for a website development project?
Why?

Ć Suppliers are contractors and they are becoming more important and more
complex in the field of IS/IT.

Ć A contract is basically an agreement between two parties:


ă A client who needs a service or a product; and
ă A contractor who performs the service or makes the product.

Ć In the IT industry, the following are some of the situations that require a
contract between two parties:
ă IT project;
ă Programming; and
ă Data entry.

Ć There are five cycles associated with the contracting system:


ă Requirement cycle ă the process of specifying the requirements;
ă Requisition cycle ă the process of making the request;
ă Solicitation cycle ă the process of inviting potential contractors or bidders;
ă Award cycle ă the process of giving out the contract; and
ă Contract administration cycle ă the process of managing the contractors.

Ć There are three common methods for acquisition which are advertising,
negotiation and small purchases.

Ć Negotiating the contract is the final detail before the contract is awarded to
the successful bidder.

Copyright © Open University Malaysia (OUM)


TOPIC 9 SUPPLIERS AND CONTRACTORS  193

Ć A request for proposal (RFP) is one common way to do a negotiated tender


process.

Ć Two very common and very straight-forward types of contracts are fixed-
price contract and cost-plus contract.

Ć More complicated types of contracts are turnkey contract and BOOT contract.

Award cycle Request for proposal


Contract administration cycle Request for quotation
Contractors Requirement cycle
Cost-plus contract Requisition cycle
Fixed-price contract Solicitation cycle
Request for information Turnkey contract

Bunni, G. N. (2005). The FIDIC forms of contract (3rd ed.). Oxford, England:
Wiley-Blackwell.
Gatti, S. (2013). Project finance in theory and practice: Designing, structuring, and
financing private and public projects. Waltham, MA: Academic.
Ould, A. M. (1999). Managing software quality and business risk. Chichester,
England: John Wiley & Sons.
Symes, S. (2005). Advantages & disadvantages of a fixed-price contract. Retrieved
from http://smallbusiness.chron.com/advantages-disadvantages-fixedprice-
contract-21066.html

Copyright © Open University Malaysia (OUM)


Topic  Project
10 Termination

LEARNING OUTCOMES

By the end of this topic, you should be able to:


1. Discuss how to prepare a checklist and a final report for project
closedown;
2. Describe how to manage a post-project review with the customer and
project team; and
3. Explain why projects fail and how to avoid it.

 INTRODUCTION
This is the final stage of the project life cycle. During this termination phase, the
project will be evaluated and then will be handed over to the customer ă i.e. the
client organisation and the system owner. However, most of the time, the project
team members tend to relax and forget that their work is still not finished until
the project is formally delivered to the customer.

Whenever or wherever the teams are working on a project, whether big or small,
or whether on a short-term or long-term basis, the principles behind completing
the project are the same ă i.e. in order to complete any project properly, the teams
have to continue the positive momentum and to bring the project to the finishing
line. The project organisation would be officially disbanded only after this time.

Copyright © Open University Malaysia (OUM)


TOPIC 10 PROJECT TERMINATION  195

10.1 TRACKING THE PROGRESS


During the final phase of the project life cycle, it is very important to be still in
the fighting spirit and to remember that the project is not yet finished. Deadlines
are still haunting the project members where last minute surprises could still
happen. It is a mistake to slow down the work and to assume that everything
will be fine. The project manager should frequently motivate the project team to
continue working as usual, because the project team members would tend to take
things for granted while the work is still ongoing at a very critical moment.

In most situations, especially during software development, going out of


schedule is inevitable. This undesirable situation might give rise to increased
project costs as well as project team stress level. The project manager would also
face constant pressure from the customer, and worst of all, possible breach of
contract. Figure 10.1 will demonstrate the tasks, from start to finish as seen from
the project managerÊs point of view. Towards the end of the project, the public
will become more aware about the outcome, and that increases the commitment
of the project manager.

Figure 10.1: The final tasks in a project require the project managerÊs full attention

That fact becomes quite evident when the project team and the project manager
realise that they are not prepared to complete the project on schedule. Now the
project manager looks for ways to speed up the process to complete the job on
time. This usually means additional hours, nights and weekends. The project
team has to be prepared to work the hardest in the final days of projectÊs
implementation if the project is off schedule even by just a few days.
Copyright © Open University Malaysia (OUM)
196  TOPIC 10 PROJECT TERMINATION

ACTIVITY 10.1
„Every new beginning comes from some other beginningÊs end‰. Do you
think that the final phase of a project has the same importance as the
early phase of a project? Give your reasons and compare your view
with your friends.

10.2 REASONS FOR TERMINATION


Project termination could be due to success or failure of the project. Projects may
come to an end for several reasons including:
(a) Final achievement of the objectives;
(b) Poor initial planning and market prognosis;
(c) A better alternative having been found;
(d) A change in the companyÊs interest and strategy;
(e) Allocated time having been exceeded;
(f) Budgeted costs having been exceeded;
(g) Key people having left the organisation;
(h) Personal whims of management; and
(i) A problem that is too complex for the resources available.

Of the above reasons, only the first one is the real successful completion of the
project. It delivers a product or service that conforms to the stated objectives and
within the required scope of work. The other reasons are project failures, and the
project had been asked to terminate by the steering committee or the project
sponsor.

Based on these examples, a project is exposed to a lot of risk of being cancelled


because of so many reasons. Project risks need to be identified and must be
closely monitored so that failure will not become a surprise to the project
manager and the project team.

The project is complete when the project goal has been reached. The goal may
have been changed many times in the course of the project, but those changes
had been approved by the steering committee, and accepted by both the

Copyright © Open University Malaysia (OUM)


TOPIC 10 PROJECT TERMINATION  197

contractor and the client. The team must have managed and documented the
project clearly and accurately. Thus, it would finally be completed at some point
in time, unless the project was cancelled prematurely. When finished, all the
tasks assigned to the members of the project team will have been dispatched. As
they finished their tasks, the team members might have been reassigned to other
projects, or perhaps, they would go back to their regular jobs.

For projects that have a fuzzy scope statement, an advice to the project manager
is to meet with his stakeholders to compare the projectÊs accomplishments with
the contract or the scope statement. Ask them to agree on whether the project is
considered finished. In not, then have them set an end point. Following a
meeting for such purpose, document the stakeholdersÊ decision and circulate it so
that there is no confusion later on (Harvard Business Review, 2012)

One important rule in the last phase of project management is to finish the
project once it is accepted by the client. There could be multiple reasons for
accepting and rejecting a completed project. They could be technical reasons,
business reasons or even psychological reasons. If the project still drags on and
on, there could be some new requirements being added on. This makes finishing
very difficult, and the contract price too could be dragged into questions.
Therefore, another advice to the project manager is to regularly test the level of
acceptance by the client. Once they are satisfied with the final product or service,
get it documented and signed by the client. You can then proceed to finish and
close the project.

ACTIVITY 10.2
What are other possible reasons that might bring any project to
termination?

10.3 CHECKLIST FOR PROJECT CLOSEDOWN


To eliminate loose ends and misunderstandings, all project teams benefit from a
checklist for project closedown or closeout. For a software development project,
for example, the checklist can be brief but is supported by a detailed contract and
supporting specifications. However, a more general checklist can be adapted and
applied to most projects is shown in Table 10.1. Along with these final items, a
number of reports and meetings should finalise the project.

Copyright © Open University Malaysia (OUM)


198  TOPIC 10 PROJECT TERMINATION

Table 10.1: Checklist for Project Closedown

No. Checklist for a Completed Project Done Not done


1. The customer has accepted the end product, as spelt out in
the project definition, project specifications and statement
of work.
2. All major milestones and other milestones have been met.
3. All project tasks have been completed in compliance with
completion criteria.
4. All follow-up responsibilities, such as customer interface
and support, have been identified and resources have
been assigned.
5. Project performance reviews or performance contracts
have been completed and delivered to the line managers
of team members.
6. Team members have been recognised and rewarded.
7. Team members have been informed of current and future
project opportunities.
8. All team members have been reassigned as activities were
completed.
9. Final project reports to the customer are complete.
10. Final project reports to management are complete.
11. Post-project review meetings have been scheduled and
held with the customer or client.
12. Post-project review meetings have been scheduled for the
project team.
13. Final payments have been made to suppliers and
subcontractors, including for any incomplete tasks. Work
orders and contracts have been finalised.
14. Final costs have been validated.
15. Final payments have been made to the main contractor,
including for any incomplete tasks.
16. Agreements have been signed for follow-up customer
support.
17. Project history has been documented, including
engineering documentation, plan versus actual
comparisons and lessons learned.

Source: Jagesh, Rahim, Bakar & Awang (2009)


Copyright © Open University Malaysia (OUM)
TOPIC 10 PROJECT TERMINATION  199

10.4 THE FINAL REPORT


As with every other phase of the project, documentation is certainly required.
The final documentation of the project does not have to be an in-depth novel of
all of the work completed. Once the project team has completed cumulative
progress reports throughout the project, the final report is considered as one last
cumulative record with a few extra ingredients. The collection of all the
cumulative reports may serve as a final record of each phaseÊs work with a few
extra parts.

The contents of the final report consist of some or all of the following items to be
addressed or referred to:
(a) The project vision statement that introduced the project;
(b) The project proposal that may have been used to sell to the management
the idea of technical implementation or the supporting information for the
project that was assigned to the team;
(c) The scope statement;
(d) The statement of work;
(e) The project schedule;
(f) The Work Breakdown Structure;
(g) The minutes from each team meeting;
(h) Any Project Change Requests forms that were approved (some project
managers may choose to include the denied Project Change Request forms
to verify why the request was not included in the deliverables);
(i) Variance reports;
(j) All communication relevant to the project deliverables (some project
managers include all memos, letters and e-mail in the report);
(k) Total cost of the project and the calculated value of the implementation;
(l) Scope verification agreement; and
(m) Post-project audit report.

As a project manager, you can check with your project sponsor and client on how
detailed the final report should be. You can prepare a draft and let them see if
anything else is to be added in. In this way, all parties would be satisfied with the
final report.

Copyright © Open University Malaysia (OUM)


200  TOPIC 10 PROJECT TERMINATION

SELF-CHECK 10.1

1. What should be checked before a project can be considered


complete?
2. List ten items which are part of the contents of the final report.

10.5 POST-CLOSING REVIEW


By now, you must have executed your project. This is therefore the time to
measure your success and finalise activities. You certainly need to transfer
control of the new system or facilities to the customer and the system owner. You
also need to present deliverables to the stakeholders.

Success means ability to achieve the goals defined in the project charter, even if
some of the tasks on your Gantt chart are not finished. You need to validate those
goals to see whether they have been achieved. Since the stakeholders care far
more about realising business benefits, at this final stage, the project team needs
to sharpen its focus on those benefits as the project reaches its completion point
(Harvard Business Review, 2012).

To improve planning for future projects, it is useful to identify what the team did
well, as well as how it can improve. For this, two meetings are suggested:
(a) The post-project review with the customer (client); and
(b) The post-project internal review with the team members, including other
internal stakeholders.

This will be described separately under a different sub-section below.

10.5.1 Review with the Customer


The post-project review meeting with the customer is usually held at a customer-
designated site some 30 to 60 days after project completion. It is often linked to a
final event or the completion of the last major milestone, such as installation. It
may be based on a previously established success criterion. Participants may
include the project manager and key members of the project team, the program
manager, the customer, key members of the customerÊs staff and upper
management from both companies.

Copyright © Open University Malaysia (OUM)


TOPIC 10 PROJECT TERMINATION  201

This meeting is primarily for the benefit of the customer or client. Participants at
this meeting should include the project leader or project manager and key
members of the project team, the client or his liaison, key members of the clientÊs
staff and the upper management from each department. The following post-
project review agenda in Table 10.2 is suggested.

Table 10.2: Post-Project Review Agenda

Agenda Explanation
Project goal State the original, agreed-on goal of the project. Then, discuss the
changes in the goal and the reasons for the changes, such as a
broader scope, a narrower scope, a choice of different materials.
Major Review the major milestones and dates from the baseline plan.
milestones Explain or review changes in the specifications or the statement of
work that resulted in changes in the milestones. For each major
milestone, identify the significant events that influenced the flow of
the project. Include deliverables that were provided on time, late
deliverables, and how to avoid late deliverables in the future.
Assumptions, Revisit the original assumptions, risks and contingency plans.
risks and Review them for accuracy and completeness. Which assumptions
contingency were on target? Which assumptions were inaccurate or not
plans identified? How accurate were risk assessments? Were the
contingency plans adequate in eliminating delays and catastrophes?
Variance All project activities and tasks with significant schedule variances
analysis: will need to be reviewed for the accuracy and completeness of the
Schedule scheduling process. Were initial time estimates broken down to
sufficient granularity? Was work omitted from the initial plan? The
team and other stakeholders will have determined the length of
time that constitutes a significant variance at the time planning was
done. It may be one week or one month, depending on the size and
type of project.
Variance Review all tasks with significant variances in costs, along with the
analysis: Costs reasons for them. Did certain contractors, suppliers or vendors bid
low and then apply for amendments? Was the project scope
allowed to expand without control? Were erroneous time estimates
on new tasks to blame?
Customer When the product has been installed or provided, were all terms
support and conditions spelt out in the agreement? How will the customer
be supported now that the project is complete? Will customer
support be required regularly? Will the customer need parts, kits or
training? Who is the key contact or liaison? Can the contact be made
easier for the customer? Have follow-up meetings been scheduled
at appropriate intervals?

Copyright © Open University Malaysia (OUM)


202  TOPIC 10 PROJECT TERMINATION

Letters of Now that the project has been successfully completed, the team
reference members have an excellent opportunity to obtain letters of
reference and testimonials from customers.

Source: Jagesh et al. (2009)

10.5.2 Review with the Project Team


The post-project review (with the project team) meeting is the meeting at which
the project team and other key stakeholders review their results. The meeting
brings the project team and other stakeholders together for the last time, during
which everyone evaluates project results against the success criteria. They will
identify what they did well so that they can repeat it. They will also analyse what
they did wrong without placing the blame on anyone, while improving future
planning and scheduling and enhancing customer benefits.

Every project is always different. You and your team members should therefore
learn from what you have just done. Companies with a project management
office (PMO) normally conduct a lessons-learned session, post-mortem or an
after-action review as a formal part of each projectÊs closeout. Whether your
company has or has no PMO, it is important to capture learning while the
experience is still fresh. For a long-term project where staff resignation is likely to
keep only one or two members by the time it winds down, it is advisable to learn
lessons after each project phase rather than doing it at the end of the project life
cycle.

According to the Harvard Business Review (2012), the lessons-learned session


consists of the following four steps discussed in Table 10.3.

Table 10.3: Steps in a Lessons-learned Session

Steps Description
Evaluate the You have to gauge whether the project has met senior
business case management expectations as clarified in the project selection and
approval process. Projects were approved on the basis of
forecasted business benefits. Has the benefit been realised? If not,
were the original assumptions and justifications inaccurate?
Evaluate the Were there necessary activities being excluded, while
project plan unnecessary activities were being included? Look at the cost and
schedule estimates for each activity. Review the initial risk
assessment and see if risks were correctly anticipated. Finally,
think of the practices established for communication between the
project team and the stakeholders.

Copyright © Open University Malaysia (OUM)


TOPIC 10 PROJECT TERMINATION  203

Evaluate the Was the organisationÊs project management methodology


project beneficial? How relevant are the procedures? Do they need to be
management changed?
methodology
Evaluate Ask the full team to help identify the super-heroes among them.
individualsÊ The outcomes would encourage the members to contribute their
performance best during the project duration in future. For the members with
poor performance, just advise them individually.

Source: Harvard Business Review (2012)

The observations, suggestions and lessons learned are then combined into a
project history document that can be stored in a safe place and used by future
project teams. The agenda for the internal post-project review meeting should
include all the items included in the post-project review meeting with the
customer.

To determine the profit and payback period for the project, gather all project cost
data and use the same method for selecting the project. To improve the project
teamÊs proficiency in planning, the following questions need to be answered:
(a) How accurate were time estimates?
(b) How accurate were cost estimates?
(c) What should be repeated on similar projects in the future?
(d) What should be avoided in the future?
(e) Should the project management methodology be changed?
(f) Can we make recommendations to current and future project teams
concerning materials, equipment and methods?

SELF-CHECK 10.2

List five agenda to be discussed in the post-closing project review


meeting with the:
(a) Customer; and
(b) Project team.

Copyright © Open University Malaysia (OUM)


204  TOPIC 10 PROJECT TERMINATION

10.6 WHY PROJECTS FAIL


Projects fail because of many reasons, not least of which is due to a lack of
professional project management. Project managers are often judged on whether
their projects achieve time, cost and quality targets. Another more telling
criterion is whether the project manager was able to steer the project through a
minefield of problems. Any one of them is just waiting to derail the project.

Thus, expertise seems to be the key. Expertise includes and is directly related to
effective leadership skills. Without effective leadership skills, a project manager
is not a project manager (refer to Figure 10.2).

Figure 10.2: Project manager has to lead a project effectively

Similarly, an effective leader would know how to think strategically, how to


communicate effectively, and how to manage possible risks proactively. Since a
project managerÊs skills are central to all other skills, a project manager with
effective expertise can communicate the project benefits to executives as well as
the other stakeholders at large. Thus he/she can enjoy their support. A lack of
this expertise can lead to failure.

However, you can also consider these aspects that contribute to the failure of a
project:

(a) Innovation
If your level of innovation is too low, your product may not be able to
compete in the market. Conversely, if your level of innovation is too high,
you may be forever trying to iron out design problems. This is important if
the project is to develop a product to be sold.

Copyright © Open University Malaysia (OUM)


TOPIC 10 PROJECT TERMINATION  205

(b) Concurrency
Concurrency is developing your product before your clientsÊ requirements
are fully defined. Some customers prefer to „fly-before-buy‰ so that
prototypes can be tested before making a product selection. This approach
may prevent procurement disaster. For the prototyping approach, please
refer to Topic 4.

(c) Stakeholders
Failure to recognise stakeholder interests, particularly related to the
environmentalists, can bring in problems. Concorde was an engineering
and aviation success, but a commercial disaster because it failed to
recognise that the environment lobby would prevent it flying
supersonically over land.

(d) Communication
Failure to establish effective communications between individuals, groups
or organisations involved in the project can results in the failure of a
project. For example, NASAÊs Mars probe crash landed on the surface of
Mars because of a mix up between imperial and metric measurements used
by the designers.

(e) Scope of work


Misinterpreting the scope of work is a common cause of project failure.
Some of the common causes of misinterpretation are:
(i) Mixing and confusing tasks, specifications, approvals and special
instructions;
(ii) Using imprecise or vague language, for example the usage of words
like „nearly‰, „optimum‰, „about‰ or „approximately‰ ă this can lead
to confusion, ambiguity or misinterpretation;
(iii) The project has no pattern, structure or chronological order. The work
breakdown structure (WBS) and critical part method (CPM)
techniques have not been used;
(iv) A wide variation in the size of the tasks and work packages, again,
caused by not using the WBS to subdivide all the work packages to a
common level of detail;
(v) Wide variation in how to describe work details; and
(vi) Failing to get a third-party review or verification from either the
client, subcontractors or suppliers.

Copyright © Open University Malaysia (OUM)


206  TOPIC 10 PROJECT TERMINATION

(f) Budget
According to Burke (2010), IT projects have a poor track record for
delivering systems within budget, based on the following findings:
(i) Only 18% of software projects are completed within budget;
(ii) 50% overrun their budget; and
(iii) 30% are so expensive that they are abandoned before substantial
completion.

(g) Other drawbacks in the project


Other common reasons for project failure include:

(i) Not working closely with the client;

(ii) Poor estimating;

(iii) Inadequate planning;

(iv) Insufficient reviews and controls;

(v) A lack of commitment (buy-in of participants and stakeholders) to


gain commitment by involving the people responsible in the planning;

(vi) Incomplete information ă for example, during the tendering process


the contractor attempts to assess the correct market price:
Ć For a project not yet built;
Ć For a design which is subject to revision;
Ć On a site about which there is little information; and
Ć For a labour force not yet recruited.

(vii) Poor planning ă material and equipment not available on time;

(viii) Lack of understanding of project management techniques; and

(ix) Lack of support from team members.

SELF-CHECK 10.3

What are the possible reasons for project failure and how can we
overcome them? Discuss.

Copyright © Open University Malaysia (OUM)


TOPIC 10 PROJECT TERMINATION  207

10.7 CRITICAL SUCCESS FACTORS


The critical success factors (CSF) in any project or any operation are those few
essential activities that must go right if the operation (project) is to be successful.
They are generally few, about half a dozen or less. After all, not every activity is
absolutely essential.

Factors that are most critical to the success of a project have been identified. They
will make conceptual sense to managers, and is general enough to be supported
across a wide range of project types ă whether IT projects or other projects. These
factors are listed and described in Table 10.4 below.

Table 10.4: Project Critical Success Factors (CSF)

Factors Explanation
Project mission Initial clarity of goals and general direction must be there.
Top management There must be willingness of top management to provide the
support necessary resources and authority or power for project
success.
Project schedule/plan Detailed specification of the individual action steps for
project implementation must be there.
Client consultation There must be communication and consultation with, and
active listening to, all affected parties.
Personnel Recruitment, selection and training of the necessary
personnel for the project team must be actively carried out.
Technical tasks The required technology and expertise to accomplish the
specific technical action steps must be available.
Client acceptance The act of selling the final project to its intended users must
be there so that clients will accept well.
Other factors Other factors are concerned with monitoring and feedback,
communication and troubleshooting.

Source: Lewis (1993)

IT projects must support the companyÊs business strategy. Thus, the goals of any
project must be in line with the general direction of the organisation. They must
be made clear to the project team at the outset so that team members are equally
aware and committed to the project mission. If the project mission is not clear,
those involved in the project may be doing it merely for the sake of obeying an
order from a higher authority, but the commitment may be weak.

Copyright © Open University Malaysia (OUM)


208  TOPIC 10 PROJECT TERMINATION

Top management must be responsive and willing to provide the necessary


resources and authority for project success. If such a support were absent, the
project manager will become discredited and be left alone to battle against people
who are even more senior than him. In the end, the project manager will become
demoralised and let the project slide into failure.

Recruitment, selection and training of the necessary personnel for the project
team must be ongoing, so that there is sufficient manpower to complete the
project on time. Team members must understand their role and how their
performances are evaluated. Thus, job descriptions must be clearly written,
distributed and understood so that they become focused and specialised.

Knowing the CSF is therefore very important, as they constitute the internal
factors that can bring a project to success or failure. Project risks can be internal
or external to the company. CSF contributes to a list of risks that may come from
inside the company. So they can be predicted clearly. If the factors can be
addressed well, then the risk of failure can be minimised to a great extent.

Ć Project termination could be due to success or failure of the project. Projects


may come to an end for several reasons including:
ă Final achievement of the objectives;
ă Poor initial planning and market prognosis; and
ă A better alternative having been found.

Ć During this final stage, the project is not yet considered as finished. The
project is complete only when the goal has been reached.

Ć The checklist to verify and to make sure that the project can be considered as
complete should have been prepared in the very beginning, and should be
followed.

Ć Post-project reviews with the customer and the project team are undoubtedly
very important events, during which you can verify the checklist against
what has been completed.

Ć The agenda for the internal post-project review meeting should include all
the items included in the post-project review meeting with the customer.

Copyright © Open University Malaysia (OUM)


TOPIC 10 PROJECT TERMINATION  209

Ć Project termination consists of the final activities that must be performed once
the project is completed.

Ć The customer, the project team members and other stakeholders can confirm
whether the project can be considered as complete.

Ć These final activities include releasing resources, transferring the project to


clients and if necessary, reassigning project team members to other duties.
The project organisation can then be disbanded.

Ć Projects fail because of many reasons, not least of which is due to a lack of
professional project management.

Critical success factor Post-project review


Fuzzy scope statement Project closedown

Burke, R. (2010). Project management: Planning and control techniques.


Chichester, England: John Wiley.
Harvard Business Review (HBR). (2012). HBR Guide to project management.
Boston, MA: Harvard Business School.
Jagesh, N., Rahim, Y. A., Bakar, N. S. A. A., & Awang, M. Z. (2009). CBPM4103 ă
Information technology project management, (2nd ed.). Kuala Lumpur: Open
University of Malaysia.
Lewis, J. P. (1993). The project managerÊs desk reference: A comprehensive guide
to project planning, scheduling, evaluation, control & systems. Chicago, IL:
Probus.

Copyright © Open University Malaysia (OUM)


MODULE FEEDBACK
MAKLUM BALAS MODUL

If you have any comment or feedback, you are welcome to:

1. E-mail your comment or feedback to modulefeedback@oum.edu.my

OR

2. Fill in the Print Module online evaluation form available on myINSPIRE.

Thank you.

Centre for Instructional Design and Technology


(Pusat Reka Bentuk Pengajaran dan Teknologi )
Tel No.: 03-27732578
Fax No.: 03-26978702

Copyright © Open University Malaysia (OUM)


Copyright © Open University Malaysia (OUM)