Syllabus

M.C.A. (Sem-IV), Paper-V

Software Project Management
1. Introduction
a. What is project?
b. What is project Management
c. The role of project Manager
d. The project Management Profession
e. Project life cycle

2. Technology Context
a. A system view of project management
b. Understanding organizations
c. Stakeholder management
d. Project phases and the project life cycle
e. The context of information technology projects

3. Introduction
a. Developing the project schedule
b. Project management software tools
c. Developing the project budget
d. Finalizing the project schedule and budget
e. Monitoring and controlling the project
f. The project communications plan
g. Project metrics
h. Reporting performance and progress
i. Information distribution

4. The importance of project risk management

a. Risk management planning
b. Common sources of risk on information technology projects
c. Risk identification
d. Qualitative risk analysis
e. Quantitative risk analysis
f. Risk response planning
g. Risk monitoring and control
h. Using software to assist in project risk management

5. The importance of project procurement management

a. Planning purchase and acquisitions
b. Planning contracting
c. Requesting seller responses
d. Selecting sellers
e. Administering the contract
f. Closing the contract
g. Using software to assist in project management
h. Outsourcing

6. Change management
 2

a. The nature of change

b. The change management plan
c. Dealing with resistance and conflict

7. Leadership & Ethics in Projects

a. Project leadership
b. Ethics in projects
c. Multicultural projects

8. Introduction
a. Project implementation
b. Administrative closure
c. Project evaluation

References:
1. Information Technology Project Management: Kathy
Schwalbe Thomson Publication.
2. Information Technology Project Management providing
measurable organizational value Jack Marchewka Wiley
India.
3. Applied software project management Stellman & Greene
SPD.
4. Software Engineering Project Management by Richard
Thayer, Edward Yourdon WILEY INDIA.



 3

1
INTRODUCTION

Unit Structure:
1.1 What is a project?
1.1.1 Project Definition
1.2 Project Attributes
1.3 Project Constraints
1.3.1 Time
1.3.2 Cost
1.3.3 Scope
1.4 What is Project Management
1.4.1 Features of projects
1.4.2 Project Classification
1.4.3 Project Management Tools and techniques
1.4.4 Project Success Factors
1.5 The Role of Project Manager
1.5.1 Responsibilities of a Project Manager.
1.6 Project Life Cycle
1.6.1 Project Initiation
1.6.2 Planning & Design
1.6.3 Execution & Controlling
1.6.4 Closure

Project management has been practiced since early

civilization. Until the beginning of twentieth century civil engineering
projects were actually treated as projects and were generally
managed by creative architects and engineers. Project
management as a discipline was not accepted. It was in the 1950s
that organizations started to systematically apply project
management tools and techniques to complex projects. As a
discipline, Project Management developed from several fields of
application including construction, engineering, and defense
activity. Two forefathers of project management are commonly
known: Henry Gantt, called the father of planning and control
techniques who is famous for his use of the Gantt chart as a project
management tool; and Henri Fayol for his creation of the five
management functions which form the foundation of the body of
 4

knowledge associated with project and program management. The

1950s marked the beginning of the modern Project Management
era. Project management became recognized as a distinct
discipline arising from the management discipline.

1.1 WHAT IS A PROJECT?

All of us have been involved in projects, whether they be our

personal projects or in business and industry. Examples of typical
projects are for example:
 Personal projects:
 obtaining an MCA degree
 writing a report
 planning a party
 planting a garden
 Industrial projects:
 Construction of a building
 provide electricity to an industrial estate
 building a bridge
 designing a new airplane

Projects can be of any size and duration. They can be

simple, like planning a party, or complex like launching a space
shuttle.

1.1.1 Project Definition:

A project can be defined in many ways :

A project is “a temporary endeavor undertaken to create a

unique product, service, or result.” Operations, on the other hand, is
work done in organizations to sustain the business. Projects are
different from operations in that they end when their objectives
have been reached or the project has been terminated.

A project is temporary. A project’s duration might be just one

week or it might go on for years, but every project has an end date.
You might not know that end date when the project begins, but it’s
there somewhere in the future. Projects are not the same as
ongoing operations, although the two have a great deal in common.

A project is an endeavor. Resources, such as people and

equipment, need to do work. The endeavor is undertaken by a
team or an organization, and therefore projects have a sense of
 5

being intentional, planned events. Successful projects do not

happen spontaneously; some amount of preparation and planning
happens first.

Finally, every project creates a unique product or service.

This is the deliverable for the project and the reason, why that
project was undertaken.

1.2 PROJECT ATTRIBUTES

Projects come in all shapes and sizes. The following

attributes help us to define a project further:
- A project has a unique purpose. Every project should have a
well-defined objective. For example, many people hire firms
to design and build a new house, but each house, like each
person, is unique.
- A project is temporary. A project has a definite beginning
and a definite end. For a home construction project, owners
usually have a date in mind when they’d like to move into
their new homes.
- A project is developed using progressive elaboration or in an
iterative fashion.
Projects are often defined broadly when they begin, and as
time passes, the specific details of the project become
clearer. For example, there are many decisions that must be
made in planning and building a new house. It works best to
draft preliminary plans for owners to approve before more
detailed plans are developed.
- A project requires resources, often from various areas.
Resources include people, hardware, software, or other
assets. Many different types of people, skill sets, and
resources are needed to build a home.
- A project should have a primary customer or sponsor. Most
projects have many interested parties or stakeholders, but
someone must take the primary role of sponsorship. The
project sponsor usually provides the direction and funding
for the project.
- A project involves uncertainty. Because every project is
unique, it is sometimes difficult to define the project’s
objectives clearly, estimate exactly how long it will take to
complete, or determine how much it will cost. External
factors also cause uncertainty, such as a supplier going out
of business or a project team member needing unplanned
time off. This uncertainty is one of the main reasons project
management is so challenging.
 6

1.3 PROJECT CONSTRAINTS

Like any human undertaking, projects need to be performed

and delivered under certain constraints. Traditionally, these
constraints have been listed as scope, time, and cost. These are
also referred to as the Project Management Triangle, where each
side represents a constraint. One side of the triangle cannot be
changed without impacting the others. A further refinement of the
constraints separates product 'quality' or 'performance' from scope,
and turns quality into a fourth constraint.

The time constraint refers to the amount of time available to

complete a project. The cost constraint refers to the budgeted
amount available for the project. The scope constraint refers to
what must be done to produce the project's end result. These three
constraints are often competing constraints: increased scope
typically means increased time and increased cost, a tight time
constraint could mean increased costs and reduced scope, and a
tight budget could mean increased time and reduced scope.

The discipline of project management is about providing the

tools and techniques that enable the project team (not just the
project manager) to organize their work to meet these constraints.

Another approach to project management is to consider the

three constraints as finance, time and human resources. If you
need to finish a job in a shorter time, you can allocate more people
at the problem, which in turn will raise the cost of the project, unless
by doing this task quicker we will reduce costs elsewhere in the
project by an equal amount.

1.3.1 Time:

For analytical purposes, the time required to produce a

product or service is estimated using several techniques. One
method is to identify tasks needed to produce the deliverables
documented in a work breakdown structure or WBS. The work
effort for each task is estimated and those estimates are rolled up
into the final deliverable estimate.

The tasks are also prioritized, dependencies between tasks

are identified, and this information is documented in a project
schedule. The dependencies between the tasks can affect the
length of the overall project (dependency constraint), as can the
availability of resources (resource constraint). Time is not
considered a cost nor a resource since the project manager cannot
 7

control the rate at which it is expended. This makes it different from

all other resources and cost categories.

1.3.2 Cost:

Cost to develop a project depends on several variables

including : labor rates, material rates, risk management, plant
(buildings, machines, etc.), equipment, and profit. When hiring an
independent consultant for a project, cost will typically be
determined by the consultant's or firm's per diem rate multiplied by
an estimated quantity for completion.

Figure 1.1 : The Project management Triangle

1.3.3 Scope:

Scope is requirement specified for the end result. The overall

definition of what the project is supposed to accomplish, and a
specific description of what the end result should be or accomplish
can be said to be the scope of the project. A major component of
scope is the quality of the final product. The amount of time put into
individual tasks determines the overall quality of the project. Some
tasks may require a given amount of time to complete adequately,
but given more time could be completed exceptionally. Over the
course of a large project, quality can have a significant impact on
time and cost or vice versa.

Together, these three constraints viz. Scope, Schedule &

Resources have given rise to the phrase "On Time, On Spec, On
Budget". In this case, the term "scope" is substituted with
"spec(ification)"
 8

1.4 WHAT IS PROJECT MANAGEMENT

Project management is “the application of knowledge,

skills, tools and techniques to project activities to meet the project
requirements.” The effectiveness of project management is critical
in assuring the success of any substantial activity. Areas of
responsibility for the person handling the project include planning,
control and implementation. A project should be initiated with a
feasibility study, where a clear definition of the goals and ultimate
benefits need to be determined. Senior managers' support for
projects is important so as to ensure authority and direction
throughout the project's progress and, also to ensure that the goals
of the organization are effectively achieved in this process.

Knowledge, skills, goals and personalities are the factors

that need to be considered within project management. The project
manager and his/her team should collectively possess the
necessary and requisite interpersonal and technical skills to
facilitate control over the various activities within the project.

The stages of implementation must be articulated at the

project planning phase. Disaggregating the stages at its early point
assists in the successful development of the project by providing a
number of milestones that need to be accomplished for completion.
In addition to planning, the control of the evolving project is also a
prerequisite for its success. Control requires adequate monitoring
and feedback mechanisms by which senior management and
project managers can compare progress against initial projections
at each stage of the project. Monitoring and feedback also enables
the project manager to anticipate problems and therefore take pre-
emptive and corrective measures for the benefit of the project.
Projects normally involve the introduction of a new system of
some kind and, in almost all cases, new methods and ways of
doing things. This impacts the work of others: the "users". User
interaction is an important factor in the success of projects and,
indeed, the degree of user involvement can influence the extent of
support for the project or its implementation plan. A project
manager is the one who is responsible for establishing a
communication in between the project team and the user. Thus one
of the most essential quality of the project manager is that of being
a good communicator, not just within the project team itself, but
with the rest of the organization and outside world as well.

1.4.1 Features of projects:

 9

 Projects are often carried out by a team of people who have

been assembled for that specific purpose. The activities of this
team may be co-ordinated by a project manager.
 Project teams may consist of people from different backgrounds
and different parts of the organisation. In some cases project
teams may consist of people from different organisations.
 Project teams may be inter-disciplinary groups and are likely to
lie outside the normal organisation hierarchies.
 The project team will be responsible for delivery of the project
end product to some sponsor within or outside the organisation.
The full benefit of any project will not become available until the
project as been completed.

1.4.2 Project Classification:

In recent years more and more activities have been tackled

on a project basis. Project teams and a project management
approach have become common in most organisations. The basic
approaches to project management remain the same regardless of
the type of project being considered. You may find it useful to
consider projects in relation to a number of major classifications:

a) Engineering and construction

The projects are concerned with producing a clear physical
output, such as roads, bridges or buildings. The requirements
of a project team are well defined in terms of skills and
background, as are the main procedures that have to be
undergone. Most of the problems which may confront the
project team are likely to have occurred before and therefore
their solution may be based upon past experiences.

b) Introduction of new systems

These projects would include computerisation projects and the
introduction of new systems and procedures including financial
systems. The nature and constitution of a project team may
vary with the subject of the project, as different skills may be
required and different end-users may be involved. Major
projects involving a systems analysis approach may
incorporate clearly defined procedures within an organisation.

c) Responding to deadlines and change

An example of responding to a deadline is the preparation of an
annual report by a specified date. An increasing number of
projects are concerned with designing organisational or
environmental changes, involving developing new products and
services.
 10

1.4.3 Project Management Tools and techniques:

Project planning is at the heart of project management. One

can't manage and control project activities if there is no plan.
Without a plan, it is impossible to know if the correct activities are
underway, if the available resources are adequate or of the project
can be completed within the desired time. The plan becomes the
roadmap that the project team members use to guide them through
the project activities. Project management tools and techniques
assist project managers and their teams in carrying out work in all
nine knowledge areas. For example, some popular time-
management tools and techniques include Gantt charts, project
network diagrams, and critical path analysis. Table 1.1 lists some
commonly used tools and techniques by knowledge area.

Knowledge Area Tools & Techniques

Integration Project selection methods, project
management management
methodologies, stakeholder analyses,
project charters, project management
plans, project management software,
change requests, change control boards,
project review meetings, lessons-learned
reports
Scope management Scope statements, work breakdown
structures,
mind maps, statements of work,
requirements
analyses, scope management plans,
scope verification techniques, and scope
change controls
Cost Management Net present value, return on investment,
payback
analyses, earned value management,
project portfolio management, cost
estimates, cost management plans, cost
baselines
Time management Gantt charts, project network diagrams,
critical-path analyses, crashing, fast
tracking, schedule
performance measurements
Human resource Motivation techniques, empathic listening,
management responsibility assignment matrices,
project
organizational charts, resource
histograms, team
building exercises
 11

Quality management Quality metrics, checklists, quality control

charts,
Pareto diagrams, fishbone diagrams,
maturity models, statistical methods
Risk management Risk management plans, risk registers,
probability/impact matrices, risk rankings
Communication Communications management plans,
management kickoff
meetings, conflict management,
communications
media selection, status and progress
reports, virtual communications,
templates, project Web sites
Procurement Make-or-buy analyses, contracts,
management requests for
proposals or quotes, source selections,
supplier
evaluation matrices

Table 1.1 : Project Management Tools and Techniques

1.4.4 Project Success Factors:

The successful design, development, and implementation of

information technology (IT) projects is a very difficult and complex
process. However, although developing IT projects can be difficult,
the reality is that a relatively small number of factors control the
success or failure of every IT project, regardless of its size or
complexity. The problem is not that the factors are unknown; it is
that they seldom form an integral part of the IT development
process.
Some of the factors that influence projects and may help them
succeed are
- Executive Support
- User involvement
- Experienced project managers
- Limited scope
- Clear basic requirements
- Formal methodology
- Reliable estimates

1.5 THE ROLE OF PROJECT MANAGER

The project manager is the driving force in the management
control loop. This individual seldom participates directly in the
activities that produce the end result, but rather strives to maintain
the progress and productive mutual interaction of various parties in
such a way that overall risk of failure is reduced.
 12

A project manager is often a client representative and has to

determine and implement the exact needs of the client, based on
knowledge of the firm he/she is representing. The ability to adapt to
the various internal procedures of the contracting party, and to form
close links with the nominated representatives, is essential in
ensuring that the key issues of cost, time, quality, and above all,
client satisfaction, can be realized.

In whatever field, a successful project manager must be able

to envisage the entire project from start to finish and to have the
ability to ensure that this vision is realized.

When they are appointed, project managers should be given

terms of reference that define their:
 Objectives;
 Responsibilities;
 Limits of authority.

1.5.1 Responsibilities of a Project Manager:

The objective of every project manager is to deliver the

product on time, within budget and with the required quality.
Although the precise responsibilities of a project manager will vary
from company to company and from project to project, they should
always include planning and forecasting. Three additional areas of
management responsibility are:
 ·interpersonal responsibilities, which include:
- leading the project team;
- liaising with initiators, senior management and suppliers;
- being the 'figurehead', i.e. setting the example to the
project team and representing the project on formal
occasions.
 informational responsibilities, which include:
- monitoring the performance of staff and the implementation
of the project plan;
- disseminating information about tasks to the project team;
- disseminating information about project status to initiators
and senior management;
- acting as the spokesman for the project team.
 decisional responsibilities, which include:
- allocating resources according to the project plan, and
adjusting those allocations when circumstances dictate (i.e.
the project manager has responsibility for the budget);
- negotiating with the initiator about the optimum
interpretation of contractual obligations, with the
 13

company management for resources, and with project

staff about their tasks;
- handling disturbances to the smooth progress of the project
such as equipment failures and personnel problems.
1.6 PROJECT LIFE CYCLE

The Project Life Cycle refers to a logical sequence of

activities to accomplish the project’s goals or objectives.
Regardless of scope or complexity, any project goes through a
series of stages during its life. There is first an Initiation or Starting
phase, in which the outputs and critical success factors are defined,
followed by a Planning phase, characterized by breaking down the
project into smaller parts/tasks, an Execution phase, in which the
project plan is executed, and lastly a Closure or Exit phase, that
marks the completion of the project. Project activities must be
grouped into phases because by doing so, the project manager and
the core team can efficiently plan and organize resources for each
activity, and also objectively measure achievement of goals and
justify their decisions to move ahead, correct, or terminate. It is of
great importance to organize project phases into industry-specific
project cycles. Why? Not only because each industry sector
involves specific requirements, tasks, and procedures when it
comes to projects, but also because different industry sectors have
different needs for life cycle management methodology. And paying
close attention to such details is the difference between doing
things well and excelling as project managers.

Diverse project management tools and methodologies

prevail in the different project cycle phases. Let’s take a closer look
at what’s important in each one of these stages:

1.6.1 Project Initiation:

The initiation stage determines the nature and scope of the

development. If this stage is not performed well, it is unlikely that
the project will be successful in meeting the business’s needs. The
key project controls needed here are an understanding of the
business environment and making sure that all necessary controls
are incorporated into the project. Any deficiencies should be
reported and a recommendation should be made to fix them.

The initiation stage should include a plan that encompasses the

following areas:

 Analyzing the business needs/requirements in measurable

goals.
 Reviewing of the current operations.
 14

 Conceptual design of the operation of the final product.

 Equipment and contracting requirements including an
assessment of long lead time items.
 Financial analysis of the costs and benefits including a
budget.
 Stakeholder analysis, including users, and support personnel
for the project.
 Project charter including costs, tasks, deliverables, and
schedule.

Figure 1.5 : Project Life Cycle

1.6.2 Planning & Design:

After the initiation stage, the system is designed.

Occasionally, a small prototype of the final product is built and
tested. Testing is generally performed by a combination of testers
and end users, and can occur after the prototype is built or
concurrently. Controls should be in place that ensures that the final
product will meet the specifications of the project charter. The
results of the design stage should include a product design that:

- Satisfies the project sponsor (the person who is providing the

project budget), end user, and business requirements.

- Functions as it was intended.

 15

- Can be produced within acceptable quality standards.

- Can be produced within time and budget constraints.

1.6.3 Execution & Controlling:

Monitoring and Controlling consists of those processes

performed to observe project execution so that potential problems
can be identified in a timely manner and corrective action can be
taken, when necessary, to control the execution of the project. The
key benefit is that project performance is observed and measured
regularly to identify variances from the project management plan.

Monitoring and Controlling includes:

 Measuring the ongoing project activities (where we are);

 Monitoring the project variables (cost, effort, scope, etc.)
against the project management plan and the project
performance baseline (where we should be);
 Identify corrective actions to address issues and risks
properly (How can we get on track again);
 Influencing the factors that could circumvent integrated
change control so only approved changes are implemented

In multi-phase projects, the Monitoring and Controlling

process also provides feedback between project phases, in order to
implement corrective or preventive actions to bring the project into
compliance with the project management plan.

Project Maintenance is an ongoing process, and it includes:

 Continuing support of end users

 Correction of errors
 Updates of the software over time

In this stage, auditors should pay attention to how effectively

and quickly user problems are resolved.

Over the course of any IT project, the work scope may

change. Change is normal and expected part of the process.
Changes can be the result of necessary design modifications,
differing site conditions, material availability, client-requested
changes, value engineering and impacts from third parties, to name
a few. Beyond executing the change in the field, the change
normally needs to be documented to show what was actually
developed. This is referred to as Change Management. Hence, the
owner usually requires a final record to show all changes or, more
specifically, any change that modifies the tangible portions of the
 16

finished work. The record is made on the contract documents –

usually, but not necessarily limited to, the design drawings. The end
product of this effort is what the industry terms as-built drawings, or
more simply, “as built.”

When changes are introduced to the project, the viability of

the project has to be re-assessed. It is important not to lose sight of
the initial goals and targets of the projects. When the changes
accumulate, the forecasted result may not justify the original
proposed investment in the project.

1.6.4 Closure:

Closing includes the formal acceptance of the project and

the ending thereof. Administrative activities include the archiving of
the files and documenting lessons learned.

This phase consists of:

 Project close: Finalize all activities across all of the process

groups to formally close the project or a project phase.
 Contract closure: Complete and settle each contract
(including the resolution of any open items) and close each
contract applicable to the project or project phase.

Sample Questions

1. Why is there a new or renewed interest in the field of project

management?

2. What is a project, and what are its main attributes? How is a

project different from what most people do in their day-to-day
jobs? What is the triple constraint?

3. What is project management? Briefly describe the project

management framework, providing examples of stakeholders,
knowledge areas, tools and techniques, and project success
factors.

4. Discuss the relationship between project, program, and portfolio

Management and their contribution to enterprise success.

5. What are the roles of the project, program, and portfolio

managers? What are suggested skills for project managers?
What additional skills do program and portfolio managers need?
 17





2
TECHNOLOGY CONTEXT
Unit Structure:
2.1 A systems view of project management.
2.1.1 The Three Sphere model for Systems management
2.1.2 A Case
2.2 Understanding Organisations
2.2.1 The key roles
2.2.1.1 Top management
2.2.1.2 The Project Board
2.2.1.3 Project Manager
2.3 Stakeholder Management
2.3.1 Stakeholder Agreements
2.4 The Context of Information Technology Projects
2.4.1. Software Projects
2.4.2 Software Development Process
2.4.3 Requirements Engineering

2.1 A SYSTEMS VIEW OF PROJECT MANAGEMENT

There are many aspects of project management that are

important and worthy of comment. There are so many details that
must be handled in order for a project to be successful. To be able
to handle the day to day details while still keeping your eye of the
strategic whole is a demanding task but one that can be learned
and improved.

As the project is a temporary, one-time endeavor undertaken

to solve a problem or take advantage of an opportunity, It usually
has a customer or customers (either internal or external to the
 18

organization that are doing the project), a budget or a set of scarce

resources that must be managed and some kind of
timeframe/constraint for completion or operation. Before one can
undertake a project to solve a problem one must first understand
the problem. Not only understand the details of the problem but
also understand who has the problem and the context and
environment that must be taken into consideration in addressing
the problem.

A key practice in getting things clear is to look at the problem

from the customers and users perspectives.

- What is important to the customer?

- How will the user actually be using the system.

- What does the world look like from their perspective?

- What do they value and what is the solution worth?

- Engineers tend to focus on features while customers are

interested in benefits; how will this help them solve their
problems.

One way to get this perspective is to spend time with the

customers and users and enter into a dialog with them. If project
managers run projects in isolation, these projects will never serve
the needs of the organisation for which it is undertaken. Project
managers thus should consider projects within the greater
organizational context and take a holistic view of a project. Systems
thinking describes this holistic view of carrying out projects.

A systems approach is an overall model for thinking about

things as systems. Systems are sets of interacting components
working within an environment to fulfill some purpose. System
analysis is a problem-solving approach that requires defining the
scope of the system, dividing it into its components, and then
identifying and evaluating its problems, its opportunities constraints
and needs. Once this is completed, the systems analyst then
examines alternative solutions for improving the current situation,
identifies an optimum, or at least satisfactory, solution or action
plan, and examines that plan against the entire system. Systems
management addresses the business, technological, and
organizational issues associated with creating, maintaining, and
making a change to a system.

Using a systems approach is critical to successful project

management. Top management and project managers must follow
 19

a systems philosophy to understand how projects relate to the

whole organisation.

2.1.1 The Three Sphere model for Systems management:

The three-sphere model of systems management deals with

the business, organizational and technological aspects and/or
issues related to the project that should be defined and considered
in order to select and manage projects effectively and successfully.
In terms of addressing its advantage on the business side, a project
should supplement or serve as an answer to the business goals;
whereas, the technological sphere should state the proper
hardware and software issues to be resolved. As for the
organizational aspect, matters involving the stakeholders should be
taken into full consideration. If the project manager would be able to
point out as early as possible the aforementioned issues and
integrate it to the project it would definitely aid in determining if an
organization should invest and produce the project.

Figure 2.1 : Three Sphere model for systems management

 20

2.1.2 A Case:

A programmer was given a task to convert a static website of

a magazine into a dynamic PHP website; what prompts the
management to engage into this project is the fact that the web has
become more sophisticated and that there has been a major shift of
“print” audience to the internet. You’ll find below the business,
organizational and technological issues of the said project.

Business issues:

1. Would the website be the medium in response to the impact

of the internet in a publishing company?
2. Would the website supplement the magazine in terms of
advertising?
3. What will the project cost the company?
4. What would be the impact of the website to the sales of the
magazine?
5. What would be the cost of maintaining the whole system for
the website?

Technological issues:

1. What operating system, server platform, scripting language

and database should be used?

2. What will be the server and desktop specifications?

3. Does our current network setup allow employees to develop

this project, or do we need an upgrade?

4. Do we have the right internet connection to support this

project?

Organizational issues:

1. Do we have the existing manpower to develop the project?

2. What would be the impact of the website to the magazine’s

print division?

3. How will the website affect our print audience?

The most important issues are from the business and

organization spheres, since these two primarily follows the
business philosophy – it would definitely be pointless if a project
fails to meet the endeavors either on the business or organizational
 21

side – it’s doomed to fail if that is the case. Among the three, I
guess the technological issues are the easiest to resolve.

2.2 UNDERSTANDING ORGANISATIONS

Every project must have its own management structure

define d at the start and dismantled at the end. The definition of the
management roles, responsibilities, relationships and
accountabilities and authorities provides the basis of the
governance arrangements for the project. Note that it is unlikely
that an existing line management structure will be sufficient or
appropriate to use as a project management organisation, except
perhaps where a small task is being run within a single business
unit with no external impact.

A typical organisation structure is depicted in the figure below

Top Management

Project Board &

other functionaries

Project manager

Project team

Figure 2.2 Organizational Structure

A well-designed organisation will involve the right people

with the right skills and the right levels of authority so that, once
approved, the project may proceed with minimal requirements to
refer outside the project organisation other than to deal with
 22

exception situations outside authority of the project’s Senior

Responsible Owner.

There is not a ‘one-size fits all’ model for the project

organisation; you must design it to suit such things as a project’s:
 Criticality to the business
 Size/complexity
 Degree of impact within the parent body
 Degree of impact on external bodies (OGDs, Private Sector)
 Cost
 Staff resources required
 Types/levels of interested parties

Designing the structure and getting people to agree to take

on roles takes time and may require many discussions/negotiations
with management at appropriately senior levels.

2.2.1 The key roles:

2.2.1.1 Top management: (in certain circumstances/environments

known as Project Sponsor(PS) or Programme Director).
The management is the project’s owner and champion and is
ultimately accountable for delivery of the project and so must:
 provide leadership and direction to other members of the
Project Board and to the Project Manager
 ensure that all key stakeholders are committed to the project
and adequately represented in the project’s organisation
structure
 ensure that budget holders and resource owners are
committed to the proj ect and that the necessary funds and
other resources are made available when required
 ensure that project governance arrangements of appropriate
rigour are put in place
 brief senior stakeholders on the current and forecast status
of the project
 receive, consider and act on regular frequent
reports/briefings from the Project Manager
 chair meetings of the Project Board
 ensure that all members of the Project Board understand
their roles the commitments they must make in order that the
required outcomes/benefits from the project are achieved
 ensure that the Project Manager is empowered to lead the
project on a day to day basis
 23

 ensure that the Project Manager is aware of the limits of

her/his authority and understands that issues outside those
limits must be escalated to the PS at the earliest opportunity.
 negotiate with senior stakeholders to broker solutions to
project issues that are outside the level of authority of the
Project Manager

As you can see, the PS is not just a figurehead, it is an

active role as a key member of the project management team. If the
project involves a number of organisations working together and/or
has a cross cutting impact, it may require more than one person to
be the decision-making authority. If this is the case, you may wish
to set up a Project Board with the PS as Chair.

2.2.1.2 The Project Board:

The Project Board should include:

 the Top Management representing the ‘business’ interests of
the sponsoring organisation as a whole
 senior representative(s) from areas that will be impacted by
the outcome and must adopt changes ;
 senior representative(s) from the organisation(s) that will
design, build and implement the solution to meet the
business need, (Senior Supplier role).

The Project Board must jointly:

 create an environment where the project can succeed in
delivering the changes necessary for the benefits to be
realised
 set the direction for the project and to approve key
milestones
 approve the Project Initiation Document
 ensure the appropriate resources required by the projects
within the project are made available in accordance with the
latest agreed version of the Project Plan
 take decisions as necessary throughout the life of the project
 give the Project Manager the authority to lead the project on
a day to day basis.

Members of the Project Board should decide how they will

assure themselves that the integrity of those aspects of the project
for which they are accountable is being maintained.
 24

2.2.1.3 Project Manager:

The Project Manager will be responsible on behalf of the PS
for day to day execution of the project plan and for dealing with
issues that might affect achievement of the plan. The Project
Manager must:
 prepare the Project Initiation Document(PID)
 submit the PID to the Project Board for approval
 submit any revised versions of the Project Plan and
Business Case to the Project Board for approval
 monitor progress of the project and identify and take action
to deal with any potential/actual exceptions that might
jeopardise achievement of the project’s objectives,
 maintain a Risk Register/Log and actively manage risks
using resources and approaches within limits of delegated
authority
 escalate to the Project Board recommendations for risk
mitigations actions outside the scope of delegated authority
limits
 report progress to, and take advice from, the PS at regular
intervals as agreed between PS and Project Manager during
Project Initiation
 manage stakeholder relationships and communications (in
accordance with an agreed Communications Plan);
 liaise with any nominated Project Assurance staff throughout
the project.

2.3 STAKEHOLDER MANAGEMENT

The importance of stakeholder management is to support an

organization in achieving its strategic objectives by interpreting and
influencing both the external and internal environments and by
creating positive relationships with stakeholders through the
appropriate management of their expectations and agreed
objectives. Stakeholder Management is a process and control that
must be planned and guided by underlying Principles.

Stakeholder Management, within business or projects,

prepares a strategy utilising information (or intelligence) gathered
during the following common processes:

 Stakeholder Identification - Interested parties either

internal or external to organisation/project.
 25

 Stakeholder Analysis - Recognise and acknowledge

stakeholder's needs, concerns, wants, authority, common
relationships, interfaces and align this information within the
Stakeholder Matrix.

 Stakeholder Matrix - Positioning stakeholders according to

the level of influence, impact or enhancement they may
provide to the business or it's projects.

 Stakeholder Engagement - Different to Stakeholder

Management in that the engagement does not seek to
develop the project/business requirements, solution or
problem creation, or establishing roles and responsibilities. It
is primarily focused at getting to know and understand each
other, at the Executive level. Engagement is the opportunity
to discuss and agree expectations of communication and,
primarily, agree a set of Values and Principles that all
stakeholders will abide by.

 Communicating Information - Expectations are

established and agreed for the manner in which
communications are managed between stakeholders - who
receives communications, when, how and to what level of
detail. Protocols may be established including security and
confidentiality classifications.)

2.3.1 Stakeholder Agreements: A collection of agreed decisions

between stakeholders. This may be the lexicon of an organisation
or project, or the Values of an initiative, the objectives, or the model
of the organisation, etc. These should be signed by key stakeholder
representatives.

Contemporary or modern business and project practice

favours transparent, honest and open stakeholder management
processes.

2.4 THE CONTEXT OF INFORMATION TECHNOLOGY

PROJECTS

2.4.1. Software Projects:

Software development is a complex process involving such
activities as domain analysis, requirements specification,
communication with the customers and end-users, designing and
producing different artifacts, adopting new paradigms and
technologies, evaluating and testing software products, installing
and maintaining the application at the end-user's site, providing
customer support, organizing end-user's training, envisioning
 26

potential upgrades and negotiating about them with the customers,

and many more.

In order to keep everything under control, eliminate delays,

always stay within the budget, and prevent project runaways, i.e.
situations in which cost and time exceed what was planned,
software project managers must exercise control and guidance
over the development team throughout the project's lifecycle. In
doing so, they apply a number of tools of both economic and
managerial nature. The first category of tools includes budgeting,
periodic budget monitoring, user chargeback mechanism,
continuous cost/benefit analysis, and budget deviation analysis.
The managerial toolbox includes both long-range and short-term
planning, schedule monitoring, feasibility analysis, software quality
assurance, organizing project steering committees, and the like.

All of these activities and tools help manage a number of

important issues in the process of software development. Figure
1.1 illustrates some of the issues, but definitely not all of them.

2.4.2 Software Development Process:

One of the primary duties of the manager of a software

development project is to ensure that all of the project activities
follow a certain predefined process, i.e. that the activities are
organized as a series of actions conducing to a desirable end . The
activities are usually organized in distinct phases, and the process
specifies what artifacts should be developed and delivered in each
phase. For a software development team, conforming to a certain
process means complying with an appropriate order of actions or
operations. For the project manager, the process provides means
for control and guidance of the individual team members and the
team as a whole, as it offers criteria for tracing and evaluation of
the project's deliverables and activities.
 27

Figure 2.3: Certain important issues in Software Project

Management
Software development process encompasses many different
tasks, such as domain analysis and development planning,
requirements specification, software design, implementation and
testing, as well as software maintenance. Hence it is no surprise at
all that a number of software development processes exist.
Generally, processes vary with the project’s goals (such as
time to market, minimum cost, higher quality and customer
satisfaction), available resources (e.g., the company’s size, the
number, knowledge, and experience of people -- both engineers
and support personnel -- and hardware resources), and application
domain.
However, every software developer and manager should
note that processes are very important. It is absolutely necessary to
follow a certain predefined process in software development. It
helps developers understand, evaluate, control, learn,
communicate, improve, predict, and certify their work. Since
processes vary with the project's size, goals, and resources, as well
as the level at which they are applied (e.g., the organization level,
the team level, or the individual level), it is always important to
define, measure, analyze, assess, compare, document, and
change different processes.
There are several well-known examples of software
development processes. Each process relies on a certain model of
software development. The first well established and well-
documented software development process has followed the
waterfall model. One of its variants is shown in Figure 1.2. The
model assumes that the process of software development proceeds
through several phases in a more-or-less linear manner. The
phases indicated in Figure 1.2 are supposed to be relatively
independent.
 28

Figure 2.4 : Waterfall Model for Software Development

There is not much feedback and returning to previous
phases other than the one directly preceding the phase in focus. In
other words, once a certain phase is finished it is considered
closed, and the work proceeds with the next phase. Many
developers have criticized the waterfall model for its rigidity in that
sense, and for its failure to comply with the reality of everchanging
requirements and technology. However, the waterfall model is at
least partially present in most of the other models as well, simply
because of its natural order of phases in software development.

There have been many attempts to overcome the limitations

of the waterfall model. Two common points in all such attempts are
introduction of iterations in software development activities and
incremental development. Iterative and incremental software
development means going through the same activities more than
once, throughout the product's lifecycle, each time producing new
deliverables and/or improving the old ones. The main advantage of
working in that way is that each individual developer works on a
small ``work packet" at any given moment, which is much easier to
control.

A classical example of iterative and incremental models is

the spiral model , sketched in Figure 1.3. In the spiral model, there
are five core tasks: planning and design (largely corresponding to
the classical analysis phase), approval (requirements specification),
realization (design and implementation), revision (testing and
modification), and evaluation (integration and system-level testing).
The process iterates through these tasks, getting closer and closer
to the end by adding increments (e.g., new functions, new design,
new modules, new or improved testing procedures, new or
improved parts of the user interface, new integration and testing
certificates, and so on) to the product in each iteration.
 29

Figure 2.5 : Spiral Model for Software Development

The spiral model underlies many processes, such as DBWA
(Design By Walking Around), and PADRE (Plan-Approve-Do-
Review-Evaluate). The DBWA process combines the spiral model
with multiple design views, flexible structuring of development
teams, and dynamic changes in modes of working (e.g., working
individually, working in pairs, or working in small teams), in order to
improve the process efficiency and parallelism. The PADRE
process uses the spiral model at multiple levels - the project level,
the phase level, and the individual software module level - thus
creating the ``spiral in a spiral in a spiral" effect.

2.4.3 Requirements Engineering:

Requirements engineering is the discipline of gathering,

analyzing, and formally specifying the user's needs, in order to use
them as analysis components when developing a software system .
Requirements must be oriented towards the user's real needs, not
towards the development team and the project managers.

Almost all software development processes one way or

another stress requirements analysis and specification as one of
their core workflows. The reasons are simple. It is necessary to
manage requirements as well as possible because a small change
to requirements can profoundly affect the project's cost and
schedule, since their definition underlies all design and
implementation . Unfortunately, in most practical projects it is not
possible to freeze the requirements at the beginning of the project
and not to change them. Requirements develop over time, and their
development is a learning process, rather than a gathering one.
The intended result of this process is a structured but evolving set
of agreed, well understood, and carefully documented requirements
. This implies the need for requirements traceability, i.e. the ability
to describe and follow the life of a requirement, in both a forward
and backward direction, ideally through the whole system's life
cycle.

The importance of constantly involving the users in the

process of requirements analysis and specifications cannot be
overemphasized. Only the users know their domain properly, and
for that reason they should certainly participate in defining the
system's functions, designing them, and evaluating their
implementation and testing. The users should also participate in
creating, verifying, and updating the requirements specification
 30

document for the project. The users should share with the
developers the responsibility for the requirements' completeness
and consistency. It is the project managers' duty to establish and
maintain good relations with the users throughout the development
process, as well as to consult them whenever the project gets stuck
due to the development team's lack of domain understanding.
It is essential to make as explicit as possible all the
requirements that reflect the user's work and the tasks that the
software system under development is supposed to automate. Any
situation in which users can find themselves when doing their job is
the context that must be taken into account through requirements
engineering. It is equally important not to concentrate on a single
user's task, but to cover communication between users when the
task requires collaboration.

There is a wide spectrum of techniques for requirements

engineering. Whatever technique is applied, it is always desirable
to involve the user to increase the correctness of the requirements
specification. Some of the techniques are:
 Structured interviews and questionnaires that the user fills in
(inquiry based requirements gathering); diagram-based
requirements analysis (using multiple diagrams to sketch
relevant parts of the user's.
 Work process and describe the requirements graphically).
 Using metaphors of the user's work process (e.g., the office
metaphor, or the agent/agency metaphor);
 Scenario analysis (scenario is a typical sequence of
activities characterizing the user's work process, hence it
reflects what the user will do with the system and helps
define the test procedures).
 Using special-purpose software tools for requirements
gathering (some of them can be simulation-based)
 Requirements completeness and consistency checks (some
of them can be automated, others must be performed
manually).
 Using special-purpose requirements-specification languages
in order to describe requirements more formally and hence
provide more automated requirements tracing.
 Prototype system development, in order to make the
requirements clear and to establish better mutual
understanding with the users.
 31






3
PROJECT SCHEDULING
Unit Structure:
3.1 Developing the Project Schedule
1.1 3.1.1. Schedule Inputs
1.2 3.1.2. Scheduling Tools
3.2 Project Management Software Tools
1.3 3.2.1. Allocate Resources to the Tasks
1.4 3.2.2. Identify Dependencies
1.5 3.2.3 Create the Schedule
2 3.2.4 RISK PLAN
3.3 Developing the Project Budget.
3.3.1 Costing
3.3.2 Budgeting
3.4 Monitoring and Controlling the Project
3.4.1 Checkpoints
3.4.1.1 Checkpoint design
3.4.2 Handling significant deviations from plan
3.4.3 Monitoring System Performance
3.5. The Project Communication Plan
3.5.1 Two Types of Communications Plans for Your Project
3.5.2 Building Your Plan
3.6 Project Metrics
2.1.1 3.6.1 Reasons for Project Metrics
3.6.2 Key Project Metrics
3.6.3 Developing Project Metrics
3.7 Reporting Performance & Progress
 32

3.7.1 Project Status Report

3.1 DEVELOPING THE PROJECT SCHEDULE

Can you imagine starting a long car trip to an unfamiliar

destination without a map or navigation system? You're pretty sure
you have to make some turns here and there, but you have no idea
when or where, or how long it will take to get there. You may arrive
eventually, but you run the risk of getting lost, and feeling
frustrated, along the way.

Essentially, driving without any idea of how you're going to

get there is the same as working on a project without a schedule.
No matter the size or scope of your project, the schedule is a key
part of project management. The schedule tells you when each
activity should be done, what has already been completed, and the
sequence in which things need to be finished.

Luckily, drivers have fairly accurate tools they can use.

Scheduling, on the other hand, is not an exact process. It's part
estimation, part prediction, and part 'educated guessing.'

Because of the uncertainty involved, the schedule is

reviewed regularly, and it is often revised while the project is in
progress. It continues to develop as the project moves forward,
changes arise, risks come and go, and new risks are identified. The
schedule essentially transforms the project from a vision to a time-
based plan.

Schedules also help you do the following:

 They provide a basis for you to monitor and control project

activities.
 They help you determine how best to allocate resources so
you can achieve the project goal.
 They help you assess how time delays will impact the
project.
 You can figure out where excess resources are available to
allocate to other projects.
 They provide a basis to help you track project progress.

Project managers have a variety of tools to develop a project

schedule - from the relatively simple process of action planning for
small projects, to use of Gantt Charts and Network Analysis for
large projects. Here, we outline the key tools you will need for
schedule development.
 33

2.2 3.1.1. Schedule Inputs:

2.3
You need several types of inputs to create a project schedule:
 Personal and project calendars - Understanding working
days, shifts, and resource availability is critical to completing
a project schedule.
 Description of project scope - From this, you can
determine key start and end dates, major assumptions
behind the plan, and key constraints and restrictions. You
can also include stakeholder expectations, which will often
determine project milestones.

 Project risks - You need to understand these to make sure

there's enough extra time to deal with identified risks - and
with unidentified risks (risks are identified with thorough Risk
Analysis).

 Lists of activities and resource requirements - Again, it's

important to determine if there are other constraints to
consider when developing the schedule. Understanding the
resource capabilities and experience you have available - as
well as company holidays and staff vacations - will affect the
schedule.

A project manager should be aware of deadlines and

resource availability issues that may make the schedule less
flexible.

2.4 3.1.2. Scheduling Tools:

Here are some tools and techniques for combining these

inputs to develop the schedule:

 Schedule Network Analysis - This is a graphic

representation of the project's activities, the time it takes to
complete them, and the sequence in which they must be
done. Project management software is typically used to
create these analyses - Gantt charts and PERT Charts are
common formats.

 Critical Path Analysis - This is the process of looking at all

of the activities that must be completed, and calculating the
'best line' - or critical path - to take so that you'll complete the
project in the minimum amount of time. The method
calculates the earliest and latest possible start and finish
times for project activities, and it estimates the dependencies
among them to create a schedule of critical activities and
dates.
 34

 Schedule Compression - This tool helps shorten the total

duration of a project by decreasing the time allotted for
certain activities. It's done so that you can meet time
constraints, and still keep the original scope of the project.
You can use two methods here:

 Crashing - This is where you assign more resources to an

activity, thus decreasing the time it takes to complete it. This
is based on the assumption that the time you save will offset
the added resource costs.

 Fast-Tracking - This involves rearranging activities to allow

more parallel work. This means that things you would
normally do one after another are now done at the same
time. However, do bear in mind that this approach increases
the risk that you'll miss things, or fail to address changes.

3.2 PROJECT MANAGEMENT SOFTWARE TOOLS

There are many project scheduling software products which

can do much of the tedious work of calculating the schedule
automatically, and plenty of books and tutorials dedicated to
teaching people how to use them. However, before a project
manager can use these tools, he should understand the concepts
behind the work breakdown structure (WBS), dependencies,
resource allocation, critical paths, Gantt charts and earned value.
These are the real keys to planning a successful project.
2.5 3.2.1. Allocate Resources to the Tasks:
The first step in building the project schedule is to identify
the resources required to perform each of the tasks required to
complete the project. A resource is any person, item, tool, or
service that is needed by the project that is either scarce or has
limited availability.

Many project managers use the terms “resource” and

“person” interchangeably, but people are only one kind of resource.
The project could include computer resources (like shared
computer room, mainframe, or server time), locations (training
rooms, temporary office space), services (like time from
contractors, trainers, or a support team), and special equipment
that will be temporarily acquired for the project. Most project
schedules only plan for human resources—the other kinds of
resources are listed in the resource list, which is part of the project
plan.

One or more resources must be allocated to each task. To

do this, the project manager must first assign the task to people
who will perform it. For each task, the project manager must identify
one or more people on the resource list capable of doing that task
 35

and assign it to them. Once a task is assigned, the team member

who is performing it is not available for other tasks until the
assigned task is completed. While some tasks can be assigned to
any team member, most can be performed only by certain people.
If those people are not available, the task must wait.
2.6 3.2.2. Identify Dependencies:
Once resources are allocated, the next step in creating a
project schedule is to identify dependencies between tasks. A task
has a dependency if it involves an activity, resource, or work
product that is subsequently required by another task.
Dependencies come in many forms: a test plan can’t be executed
until a build of the software is delivered; code might depend on
classes or modules built in earlier stages; a user interface can’t be
built until the design is reviewed. If Wideband Delphi is used to
generate estimates, many of these dependencies will already be
represented in the assumptions. It is the project manager’s
responsibility to work with everyone on the engineering team to
identify these dependencies. The project manager should start by
taking the WBS and adding dependency information to it: each task
in the WBS is given a number, and the number of any task that it is
dependent on should be listed next to it as a predecessor. The
following figure shows the four ways in which one task can be
dependent on another.

Figure 3.1: Task Dependency

2.7 3.2.3 Create the Schedule:
Once the resources and dependencies are assigned, the
software will arrange the tasks to reflect the dependencies. The
software also allows the project manager to enter effort and
duration information for each task; with this information, it can
calculate a final date and build the schedule.
 36

The most common form for the schedule to take is a Gantt chart.
The following figure shows an example:

Figure 3.2: Gantt Chart

Each task is represented by a bar, and the dependencies

between tasks are represented by arrows. Each arrow either points
to the start or the end of the task, depending on the type of
predecessor. The black diamond between tasks D and E is a
milestone, or a task with no duration. Milestones are used to show
important events in the schedule. The black bar above tasks D and
E is a summary task, which shows that these tasks are two
subtasks of the same parent task. Summary tasks can contain
other summary tasks as subtasks. For example, if the team used
an extra Wideband Delphi session to decompose a task in the
original WBS into subtasks, the original task should be shown as a
summary task with the results of the second estimation session as
its subtasks.
 37

The following figure shows an example of a Gantt chart created in

Microsoft Projects :

Figure 3.3 Gantt Chart drawn using Microsoft Project.

4
5

6 3.2.4 RISK PLAN

A risk plan is a list of all risks that threaten the project, along
with a plan to mitigate some or all of those risks. Some people say
that uncertainty is the enemy of planning. If there were no
uncertainty, then every project plan would be accurate and every
project would go off without a hitch. Unfortunately, real life
intervenes, usually at the most inconvenient times. The risk plan is
an insurance policy against uncertainty.

Once the project team has generated a final set of risks, they
have enough information to estimate two things: a rough estimate
of the probability that the risk will occur, and the potential impact of
that risk on the project if it does eventually materialize. The risks
 38

must then be prioritized in two ways: in order of probability, and in

order of impact. Both the probability and impact are measured
using a relative scale by assigning each a number between 1
and 5.

These numbers are arbitrary; they are simply used to

compare the probability or impact of one risk with another, and do
not carry any specific meaning. The numbers for probability and
impact are assigned to each risk; a priority can then be calculated
by multiplying these numbers together. It is equally effective to
assign a percentage as a probability (i.e. a risk is 80% likely to
occur) and a real duration for impact (i.e. it will cost 32 man-hours if
the risk occurs). However, many teams have trouble estimating
these numbers, and find it easier to just assign an arbitrary value
for comparison.

Many people have difficulty prioritizing, but there is a simple

technique that makes it much easier. While it’s difficult to rank all of
the risks in the list at once, it is usually not hard to pick out the one
that’s most likely to occur. Assign that one a probability of 5. Then
select the one that’s least likely to occur and assign that one a
probability of 1. With those chosen, it’s much easier to rank the
others relative to them. It might help to find another 5 and another
1, or if those don’t exist, find a 4 and a 2. The rest of the
probabilities should start to fall in place. Once that’s done, the same
can be done for the impact.

After the probability and impact of each risk have been

estimated, the team can calculate the priority of each risk by
multiplying its probability by its impact. This ensures that the
highest priority is assigned to those risks that have both a high
probability and impact, followed by either high-probability risks with
a low impact or low-probability risks with a high impact. This is
generally the order in which a good project manager will want to try
to deal with them: it allows the most serious risks to rise to the top
of the list.

This can be very easily done using tools like Microsoft

Project or even by using any spreadsheet package that provides
some basic statistical functions.

3.3 DEVELOPING THE PROJECT BUDGET.

If scheduling is an art then costing could be considered a

black art. Some projects are relatively straightforward to cost but
most are not. Even simple figures like the cost per man/hour of
labour can be difficult to calculate.
 39

Accounting, costing and budgeting are extensive topics in

themselves. Some fundamental principles to keep in mind are
derived from accounting practices:

• The concept of 'prudence' – you should be pessimistic in your

accounts (“anticipate no profit and provide for all possible
losses”).Provide yourself with a margin for error and not just show
the best possible financial position. It’s the old maxim: promise low-
deliver / high once again

• The 'accruals' concept- revenue and costs are accrued or

matched with one another and are attributed to the same point in
the schedule. For example if the costs of hardware are in your
budget at the point where you pay the invoice, then ALL the costs
for hardware should be “accrued” when the invoice is received.

• The ‘consistency’ concept. This is similar to accruals but it

emphasises consistency over different periods. If you change the
basis on which you count certain costs you either need to revise all
previous finance accounts in line with this or annotate the change
appropriately so people can make comparisons on a like-for-like
basis.

Note that the principles are listed in order of precedence. If the

principle of consistency comes into conflict with the principle of
prudence, the principle of prudence is given priority.

3.3.1 Costing:

At a basic level the process of costing is reasonably simple.

You draw up a list of all your possible expenditure and put a
numerical value against each item; the total therefore represents
the tangible cost of your project. You may also however need to
consider “intangible” items.

Tangible costs:

• Capital Expenditure – any large asset of the project which is

purchased outright. This usually includes plant, hardware, software
and sometimes buildings although these can be accounted for in a
number of ways.

• Lease costs – some assets are not purchased outright but are
leased to spread the cost over the life of the project. These should
be accounted for separately to capital expenditure since the project
or company does not own these assets.

• Staff costs – all costs for staff must be accounted for and this
includes (but is not limited to): salary and pension (superannuation)
 40

costs; insurance costs; recruitment costs; anything which can be

tied directly to employing, training and retaining staff.

• Professional services –all large-scale projects require the input

of one or more professional groups such as lawyers or
accountants. These are normally accounted for separately since a
close watch needs to be kept upon expenditure in this area.
Without scrutiny the costs of a consultant engineer, accountant or
lawyer can quickly dwarf other costs.

• Supplies and consumables – regular expenditure on supplies is

often best covered by a single item in your budget under which
these figures are accrued. They are related to overhead below.

• One-off costs – one-off costs apply to expenditure which is not

related to any of the above categories but occurs on an irregular
basis. Staff training might be an example. While it might be
appropriate to list this under staff costs you might wish to track it
independently as an irregular cost. The choice is yours but the
principles of prudence and consistency apply.

• Overheads – sometime called indirect costs, these are costs

which are not directly attributable to any of the above categories but
never-the-less impact upon your budget. For example it may not be
appropriate to reflect the phone bill for your project in staff costs,
yet this still has to be paid and accounted for. Costing for
overheads is usually done as a rough percentage of one of the
other factors such as “staff costs”.

Intangible costs
It has become fashionable to account for “intangible” assets on the
balance sheets of companies and possibly also projects. The
argument goes like this: some contributions to a project are
extremely valuable but cannot necessarily have a tangible value
associated with them. Should you then account for them in the
budget or costing? The “prudence” principle says yes but
practicality says “no”. If you are delving this murky area of
accountancy you should seek professional help and advice.

Typical things you might place in the budget under intangibles are
“goodwill” and “intellectual property”. Personnel-related figures are
a frequent source of intangible assets and so you might find things
like “management team”, “relationships” and “contacts” on an
intangibles balance sheet.

3.3.2 Budgeting:

Once you have costed your project you can then prepare an
appropriate budget to secure the requisite funds and plan your cash
 41

flow over the life of the project. An accurate cost model will of
course entail a fairly detailed design or at the very least
requirement specification so that you can determine your scope of
work. This is normally completed well into the design phase of the
project.

You must be extremely careful with initial estimates and

always follow the “promise low / deliver high” commandment.

Costing and budgeting follow the iterative life cycle as do

other tasks within the project. As you refine your design, so you will
need to refine the costing which is based upon it.

As in scheduling, you need to build in adequate contingency

(reserves) to account for unexpected expenditure. For example, if
due to a failure in the critical path a task is delayed and a milestone
(like software purchase) falls due in the month after it was
scheduled. This can wreck your carefully planned cash flow. But if
you have carefully budgeted your project then variations should be
relatively easy to spot and cope with as they arise.

Just as in scheduling you should have regular budget

reviews which examine the state of your finances and your
expenditure to date and adjust the planned budget accordingly.

Regardless of circumstance, a number of basic philosophies

can help your budgeting immensely by protecting it from subjective
review. By understanding concepts, and making sure that everyone
involved understands them, you’ll be on the right track to an
accurate projection:
 Project costs and project budgets are two different things.
Always start by identifying project costs.
 Project costs are not defined solely in monetary amounts.
Include actual amounts, with shipping and taxes, for
software or hardware purchases that must be made. If you’re
pro-rating the costs of using pre-existing hardware and
software tools, include it in number of hours. Likewise,
developer effort costs are recorded in hours, not dollars.
 Once you’ve laid out your costs, identify your risks and
assign a percentage reflecting how much each risk factor
may affect the project as a whole, or a portion of the project.
Each development team should have a risk value assigned
to it, to cover reasonable costs such as hiring the occasional
contractor to get a timeline under control, unforeseen
overtime, and so on.
 Your budget, then, is the total of the costs, as transcribed
into a monetary figure, plus the total risk percentage of that
 42

cost. Define conversion values that you use to represent

equipment pro-rating and development times.
 Your budget is not an invoice. Once you’ve determined the
hard figures involved, leave it up to your company’s business
representatives to make adjustments for profits. Make sure
they understand your figures reflect actual costs.
 A budget should always be labeled as an estimate, until it is
finalized and approved. This helps to manage expectations
and prevent miscommunications from being written in stone.
 A single person does not create a budget. At the very least,
all of the following should be consulted: lead developer,
project manager, and a business-side driver.

3.4 MONITORING AND CONTROLLING THE PROJECT

To appreciate how project control works you must first

understand that, despite all the effort devoted to developing and
gaining commitment to a plan, there is little chance that the
resulting project will run precisely according to that plan.

This doesn’t mean that you will fail to achieve the objectives
of the plan – on the contrary, you must have a very high level of
confidence that you can achieve those objectives and deliver the
full scope, fit for purpose, on time and to budget.

The plan describes what you would like to do but it models

just one of the infinite number of routes from where you are now to
where you want to be. In practice your project will follow a different
route to the one shown in your plan, you don’t know which one, but
you will need control to make sure it is a route that takes you to
where you need to be, when you need to be there, and at a cost
you can afford.

The power of the plan is that it gives you a baseline against

which you can compare actual achievement, cost and time and
determine the amount of deviation from plan and hence take
corrective action if required.

The essential requirement for control is to have a plan

against which progress can be monitored to provide the basis for
stimulating management action if the plan is not being followed.
Control then becomes a regular, frequent iteration
of: Creating the right environment for control.
 43

Monitoring Taking Corrective

Planning & action &
evaulation Reporting

Figure 3.4 : Project Control

The basic requirements for control are:

a plan that is:
- realistic
- credible
- detailed enough to be executed
- acceptable to those who must execute it (Project Manager
and Project Teams)
- approved by those who are accountable for its
achievement (the SRO/ Project Board);
 a process for monitoring and managing progress and
resource usage;
 a project management organisation of appropriately skilled
people with sufficient authority and time to plan, monitor,
report, take decisions and deal with exceptions;
 a process to make minor corrections and adjustments to
deal with minor deviations and omissions from the plan;
 the commitment of those who will provide the resources
indicated in the plan ( SRO, Project Board, Stakeholders and
resource ‘owners’ in the parent organisation and its related
agencies);
 explicit authority to proceed granted by those who are
accountable for the project.

In all but the smallest or shortest projects you should think

about how to break your project into manageable ‘chunks’ called
stages. Every project will have a minimum of two stages – the first
being Project Initiation. A large project may have a number of
stages, each of which has its own stage plan. When designing your
project’s stage structure look for points where the Project manager
should:

 review achievements to date and assess project viability

 take key decisions outside the level of authority of the
Project Manager
 44

 approve a more detailed plan for the next phase of work

commit resources in accordance with the project or stage
plan
 assess the impact of some significant external event that will
influence the project (eg: legislation, decision point in other
project, review of business operation).

The Project Manager will also be able to identify stage

boundaries by thinking about how far ahead is it sensible to plan in
the fine detail needed for day to day control. In practice, the
detailed plan for a stage will be produced towards the end of the
preceding stage, when the information needed for planning is
available.

3.4.1 Checkpoints:

Checkpoint reports are produced by team managers /

leaders for the Project Manager who needs to have early warning
of deviations from plan and other problems affecting the project
team. Checkpoints provide regular, frequent comparison of actual
progress, resource usage and forecasts against plans. They
provide information for the Project Manager to apply control, eg by
correcting small deviations from the plan. The basic purpose of a
checkpoint is to answer the questions:
 ‘What is going according to plan?’
 ‘What is not going to plan?’
 ‘What is likely not to go to plan?’

Checkpoints are essential controls – missed checkpoints are

usually an early sign of a failing project. The information gathered
at checkpoints should be documented in Checkpoint Reports and
used in the preparation of Highlight Reports.

3.4.1.1 Checkpoint design:

There are many different ways of conducting Checkpoints -

they might be, but do not have to be, achieved through written
reports and meetings. Each project must use an approach that
balances the need for communication and control against too much
management interference in work in progress. Checkpoint design
will cover:
 Frequency of reporting
 Timing (eg: time and day of week)
 Information required from team members (oral reports,
timesheets, written reports)
 Method of conducting checkpoint (eg informal chats, formal
meetings, phone, fax, email)
 45

 Participation (Project Manager? Project Assurance? Team

Members? Suppliers?)
 Content of a report to be used to communicate the findings
of the Checkpoint.

The Project Manager should set Checkpoint frequency

depending on the intensity of activity. Checkpoint frequencies
ranging from fortnightly (eg during procurement phases) down to
daily (eg during implementation and training) are possible within the
same project.

3.4.2 Handling significant deviations from plan:

Project Board members are usually senior managers with

limited time to devote management of the project. In order to
achieve ‘management by exception’ the Project Manager should be
given authority to deal with the inevitable small deviations from
plan. For larger deviations, such as those resulting from requests
for change, poor estimation, delays in deliveries by external
agencies. The Project Manager will require an agreed exception
handling process. This will involve:

 Setting delegated limits (eg. cost and time ‘Tolerances’): The

Project Board should set limits to the allowable deviations
from planned cost and schedule so that the Project Manager
knows how much delegated authority is available to manage
deviations from plan;

 Exception reporting: The Project Manager may use an

exceptional Highlight Reports to notify any forecast (or
actual) deviations from plan beyond delegated limits.
Positive sorts of exception should also be reported in this
way eg: finishing work early or using less resource than
planned.

 Exception planning and decision making: The management

may wish the Project Manager to create a new plan to
replace the current one if it is no longer viable. This plan
would b e submitted for a decision to proceed.

3.4.3 Monitoring System Performance:

A potential problem when software systems are involved is
the potential of the systems not being able to handle increased
volumes of data in the future. To take care of this, performance
monitoring should be a part of all softwares that are likely to grow in
size, identifying potential future bottlenecks in the system, including
lack of disk space, lack or processing power, approaching
transaction limits, long before they become a problem, so corrective
action can be taken.
 46

This process is very complex because softwares will grow in

size due to systems being installed incrementally (e.g., they may be
installed at a pilot location first) and due to future increases in
number of customers over time. It is also complex because new
technology may become available that handles greater capacity but
that will incur additional costs to the organization to implement. It is
proposed that information required for this planning be kept in a
Performance and Adaptability Plan document that identifies future
projections of increases in number of customers handled by the
software, bottlenecks identified so far, and contingency plans for
resolving anticipated future performance problems. The
Performance and Adaptability Plan document would be used by
business planners who would project increases in numbers of
customers, performance monitors who identify bottlenecks in
systems, and capacity planners who would identify requirements for
changes to hardware and or system software.

3.5. THE PROJECT COMMUNICATION PLAN

Good communications among all stakeholders is key for the

success of a project. It’s important to ensure your project team
develops a communication plan so that lack of communication does
not derail your goals.

Even though you may have identified and analyzed your

stakeholders and determined the most effective communications
vehicles – without a well developed and implemented
communication plan, you may have a recipe for disaster. So how
do you develop a communication plan to ensure your project’s
success?

Following are the two types of communication plans to

support and enhance communications throughout your project. As
discussed in previous installments, the first step in building your
plan is to identify your project stakeholders and determine the best
communications vehicle. Next, you build your plan.

3.5.1 Two Types of Communications Plans for Your Project:

For all sized projects, a well-structured communications plan

is a must from the beginning. Projects offer multiple opportunities
for communications to your key stakeholders, and we recommend
exploring two types of communication plans for your project to
exploit these opportunities.

1. Regular or Ongoing Communication Plan

2. One-time or Event-driven Communication Plan
 47

3.5.2 Building Your Plan:

Regular or Ongoing Communications:

Regular, or ongoing, communications include those
opportunities you have to communicate to your project team
members, sponsors, steering committee members, and other key
stakeholders on a regular basis. These types of communication
could include your regular status reports, scheduled project team
meetings, monthly updates with the steering committee, or regularly
scheduled campus updates on a project. Use your stakeholder
analysis to develop these routine and ongoing communications for
the project.

Review this plan at regular intervals (quarterly) to ensure

that you are adequately communicating to those stakeholders who
are closest to the project. The chart on the next page provides an
example of the types of communications to consider for your
regular and ongoing communications. Don’t forget to include your
regular meetings and even one-on-ones that you may have with
your sponsor.

Communicati Purpose Audience Author Communicati Frequency

ons on vehicle
location

Monthly To keep Steering Project - E-mails Monthly

status reports senior committee Manager - Website
to leadership Executive postings
management informed committee
about the
projects
progress
Weekly Monitor the Project Project -E-mails Weekly
schedule progress management Manager - postings on
and report. team website
- meetings
Project Team Keep Project Project Postings in As and
calendar project participants coordinator the when
participants Steering respective needed.
aware of committee members
the key folder
project
deadlines
to help
them
manage
their
schedule

Figure 3.5 : Sample communication plan

 48

One-time or Event-driven Communications:

During the life of any project, opportunities arise for one-time
or event-driven communications. Work with your project team to
identify those opportunities, like the example timeline. This plan
could also include critical issues sessions, vendor meetings,
training schedules, and roll-out schedules.

To gain the most advantage from the communications

opportunities for your project, review this portion of your
communication plan every month with your project team. Review
the past month, and then look forward at least six months to ensure
that as your project plan changes, you are able to capitalize on
every communication opportunity.

When developing your communications plan keep in mind that the

key is to always have the receiver as the focal point—not the
sender. Make your communications deliberate and focused. By
making sure that your plan is clear and thoroughly outlined, you can
help reduce the number of problems and surprises that pop-up and
have a project as successful as a perfect soufflé.

3.6 PROJECT METRICS

Metrics are a set of quantifiable parameters which are used

to measure the effectiveness of a project or undertaking. Values
are obtained for the parameters for multiple instances of the same
entity and they are compared and interpreted as to the change in
the effectiveness. For example, if there are multiple versions of a
product, one metric could be the user satisfaction level (say 1 to 5,
1 being least happy and 5 being very happy)with the user interface
for each of the versions. The effectiveness of the changes in the
user interface can be measured by the satisfaction level of the
users with each of the versions.

Project metrics are in-process or project execution measures

that are collected, analysed and used to drive project process
improvement.

6.1.1 3.6.1 Reasons for Project Metrics:

Project metrics require time and effort and so that work is done for
usually one of these reasons:

 To provide clear and tangible project status information

about project schedule and cost
 To identify areas for project process improvement
 To demonstrate the results of process improvement efforts
 49

 To collect a database of project metrics to analyse trend

information or provide historic comparators and perhaps
used for parametric estimates

To collect project metrics without a clear plan of future action

to use those metrics is simply wasting time and effort. In short, only
collect project metrics that will be used to drive project process
improvements.

6.1.2 3.6.2 Key Project Metrics:

Senior management will often wish to see regular reports of

project progress against time and cost measures. Some project
management methodologies go into some detail with these metrics
including planned versus forecast, cost variance, schedule variance
and earned value. However, more generally, key project
management metrics include:

 Schedule - delivery date and slippage in days from original

delivery date
 Cost - actual budget versus original budget
 Resource - effort, how much time people have used on the
project
 Scope - changes to project as measured through number
and type of controlled changes made
 Quality - quality defects and documentation
 Software - a specialised subject with many potential
measures such as lines of code, code complexity and
function point
 Defects - number and type of problems or issues recorded
for the technology project during its test stage and warranty
period or a defined time period

Other metrics associated with normal operation such as

availability, performance or support call resolution properly belong
with service metrics rather than project metrics.

Project metrics selected should reflect the voice of the

customer (customer needs), as well as ensure that the internal
metrics selected by the organization are achieved. Metrics selected
should be simple and straightforward and meaningful. Metrics
selected should create a common language among diverse team
members.

When drafting metrics for a particular project one should

consider how the metrics are connected and related to key
 50

business metrics. Typically there is no one metric that fits all the
requirements for a particular situation.

3.6.3 Developing Project Metrics:

The most common approach used by teams is to understand

the problem statement, brainstorm metrics, and finally decide what
metrics can help them achieve better performance. The team then
reviews these metrics with executive management to ensure that
they are in synergy with the overall strategy of the business, and an
iterative approach may be utilized.

Care should be exercised in determining what is measured.

Metrics should be based on what, in fact, needs to be measured to
improve the process, rather than what fits the current measurement
system. Metrics need to be scrutinized from the value they add in
understanding a process.

3.7 REPORTING PERFORMANCE & PROGRESS

Performance reporting involves collecting, processing and

communicating information to key stakeholders, regarding the
performance of the project. Performance reporting can be
conducted using various tools and techniques, most of which have
been already described in the previous paragraphs. The most
widely used techniques for performance reporting are:

Performance review meetings that take place to assess the

project’s progress or/and status

Variance analysis which is about comparing actual project results

(in terms of schedule, resources, cost, scope, quality and risk)
against planned or expected ones.

Earned Value Analysis (EVA) used to assess project performance

in terms of time (schedule) and cost (or resources).

Financial and Output Performance Indicators used to measure

financial and physical progress of the project

Information of project’s performance is usually communicated via

Progress Reports and Project Status Reports which are
described in the paragraphs below.

The Progress Report is a document prepared by the Project

Team members (in case of in-house production) or by the
Management Team of the Contractor (in case that the
implementation of the project is totally outsourced) to provide
 51

regular feedback to the Project Manager regarding the progress of

the project. Progress reports should be submitted on a regular
basis to enable the Project Manager to update the Activities
Schedule, identify any schedule problems or potential problems
and act proactively for their resolution. Progress Reports are
usually asked to be submitted every two weeks or every month,
when the project is implemented with own resources. However, in
case that the project is implemented by a Contractor, the progress
reports are usually asked every three or six months. Generally, a
Progress Report should include the following information:

- Reporting period to which it refers

- Project Title
- Project Manager’s name
- Authors of the report
- Date of submission
- Project synopsis (i.e. project goals and objectives, expected
results, project activities, duration, etc.)

Project progress in the reporting period (i.e. activities/ tasks

executed, actual work accomplished, deliverables submitted,
deviations for baseline schedule, estimation of the effort required to
complete activities/ tasks)

Work programme for the following reporting period (i.e.

activities/ tasks to be executed, deliverables to be submitted,
schedule estimates for key milestones, etc.)

Updated/ revised Activities Schedule showing the

percentage of work completed so far and the estimated start or
finish dates for activities/ tasks.

It should be noted that in case of small projects with only few

team members, the Progress Report can be substituted by
personal judgment and observations of the Project Manager or by
day-to-day discussions with the team members on the progress of
the deliverables. On the contrary, in case of large and complex
projects, where progress reporting is an important aspect of
communication management, the Progress Reports should be
formally submitted to the Project Manager by the Team Manager(s)
(or by the Contractor), who have to prepare them by collecting the
relative progress information from individual team members.

3.7.1 Project Status Report:

The Project Status Report is a document prepared by the

Project Manager - using the information provided by the Progress
Reports - to present the status of the project to key stakeholders,
including the Project Steering Committee, the Project Owner and
 52

the Funding Agency. Depending on the duration and size of the

project, as well as on specific communication requirements of the
Project Owner or/and the Funding Agency, the Status Report can
be prepared monthly, quarterly or biannually. Usually, Status
Reports are prepared with the same or less frequency than
Progress Reports since they require input from them.

The aim of the Project Status Report is to:

-Provide an overview of project’s progress up to date

- Ensure that the key stakeholders are regularly informed on the

progress of the project

- Inform the key stakeholders about issues that require immediate

action or resolution

Normally the Status Report becomes the point of discussion

for the Status Meeting, which is a regularly scheduled event, where
the Project Manager presents the status of the project to the
Steering Committee (and maybe to the Project Owner or /and the
Funding Agency). In these meetings the Project Manager can invite
members of the Project Team who have expertise in a certain area
of the discussion. It is, however recommended that the Project
Manager invites periodically the Project Team to review the status
of the project, discuss their accomplishments and communicate any
issues or concerns in an open, honest and constructive forum. On
large projects where gathering the entire team is not always
possible, the Project Team members can be represented in the
meeting by the respective Team Manager(s), who can
communicate the status of their team work since they have a better
insight into the day-to-day activities of their team members.









 53

4
PROJECT RISK MANAGEMENT
Unit Structure:
4.0 Objectives
4.1 Introduction
4.2 The Importance of Project Risk Management
4.2.1 Processes and outputs
4.3 Risk Management Planning
4.4 Common Sources of Risk in Information Technology projects
4.4.1 Categories of Risk
4.4.2 Risk Breakdown Structure
4.5 Risk Identification
4.5.1 Suggestions For Identifying Risks
4.5.2The Risk Register
4.6 Qualitative Risk Analysis
4.6.1 Using Probability/Impact Matrix To Calculate Risk
Factors
4.6.2 Top Ten Risk Item Tracking
4.6.3 Expert Judgment
4.7 Quantitative Risk Analysis
4.7.1 Decision Trees and Expected monetary Value
4.7.2 Simulation
4.7.3 Sensitivity Analysis
4.8 Risk Response Planning
4.9 Risk Monitoring and Control
4.10. Using Software to Assist in Project Risk Management
4.11 Summary

4.0 OBJECTIVES

After reading this chapter you will be able to:

1. Understand what risk is and the importance of good project
risk management
 54

2. Discuss the elements involved in risk management planning

and contents of a risk management plan.
3. List common sources of risks on information technology
projects
4. describe the risk identification process, tools and techniques
to help identify project risks and the main output of risk
identification-risk register
5. Discuss the qualitative risk analysis process and explain how
to calculate risk factors, create probability impact matrixes,
apply the top ten risk item tracking techniques, and use
expert judgment to rank risks
6. Explain quantitative risk analysis process and how to apply
decision trees, simulation, and sensitivity analysis to quantify
risks
7. Provide examples of using different risk response planning
strategies to address both negative and positive risks
8. Discuss the components of risk monitoring and control
9. Describe how software can assist in project risk
management

4.1 INTRODUCTION

Managing risk is an integral part of good management and is

something many managers do already in one form or another.

Project risk is an uncertain event or condition that, if it

occurs, has a positive or a negative effect on at least one project
objective. A risk may have one or more causes and, if it occurs, one
or more impacts. Risk management is the systematic process of
planning for, identifying, analyzing, responding to, and monitoring
project risks. It involves processes, tools, and techniques that will
help the project manager maximize the probability and results of
positive events and minimize the probability and consequences of
adverse events as indicated and appropriate within the context of
risk to the overall project objectives of cost, time, scope and quality.
Project risk management is most effective when first performed
early in the life of the project and is a continuing responsibility
throughout the project’s life cycle.

4.2 THE IMPORTANCE OF PROJECT RISK

MANAGEMENT

The project risk management process helps project

sponsors and project teams make informed decisions regarding
 55

alternative approaches to achieving their objectives and the relative

risk involved in each, in order to increase the likelihood of success
in meeting or exceeding the most important objectives (e.g. time)
sometimes at the expense of other objectives (e.g. cost).

Risk Management provides a structured way of identifying

and analyzing potential risks, and devising and implementing
responses appropriate to their impact. These responses generally
draw on strategies of risk prevention, risk transfer, impact mitigation
or risk acceptance. Within a single project or proposal each of
these strategies may have application for different individual risks.
Risk management encourages the project team to take appropriate
measures to:

1. Minimize adverse impacts to project scope, cost, and schedule

(and quality, as a result).
2. Maximize opportunities to improve the project’s objectives with
lower cost, shorter schedules, enhanced scope and higher
quality.
3. Minimize management by crisis.

Project risk management is the art and science of identifying,

analyzing and responding to risk throughout the life of a project and
in the best interest of meeting the project objectives. A frequently
overlooked aspect of project management, risk management can
often result in significant improvements in the ultimate success of
projects .Risk management can have a positive impact on selecting
projects, determining scope of projects and developing realistic
schedules and cost estimates. It helps project stakeholders
understand the nature of the project, involves team members in
defining the strengths and weakness , and helps to integrate the
other project management knowledge areas.

Before you can improve project risk management, you must

understand what risk is .A basic dictionary definition says that risk
is “the possibility of loss or injury”. This definition highlights the
negativity often associated with risk and suggests that uncertainty
is involved. Project risk management involves understanding
potential problems that might occur on the project and how they
might impede project success. The PMBOK Guide 2004 refers to
this type of risk as a negative risk. However, there are also positive
risks, which can result in good things happening on a project. A
general definition of a project risk , therefore , is an uncertainty that
can have a negative or positive effect on meeting project
objectives.
 56

Some organizations or people have a neutral tolerance for

risk, some have an aversion to risk, and others are risk seeking.
These three preferences for risk are part of the utility theory of risk.

Risk utility or risk tolerance is the amount of satisfaction or

pleasure received from a potential payoff. The following figure
shows the basic difference between risk averse, risk neutral, and
risk seeking preferences. The y-axis represents utility, or the
amount of pleasure received from taking a risk. The x-axis shows
the amount of potential payoff, opportunity, or dollar value of the
opportunity at stake.

Utility rises at a decreasing rate for a risk averse person.

That is when more payoff or money is at stake ,a person or
organization that is risk averse gains less satisfaction from risk, or
has lower tolerance for the risk. Those who are risk seeking have a
higher tolerance for the risk, and their satisfaction increases when
more payoff is at stake. A risk seeking person prefers outcomes
that are more uncertain and is often willing to pay penalty to take
risk. A risk neutral person achieves balance between risk and
payoff..

Risk –Averse Risk-Neutral Risk-Seeking

Risk utility function and risk preference

The goal of project risk management can be viewed as
minimizing potential negative risks while maximizing potential
positive risks. The term known risks is some times used to describe
risks that the project team has identified and analyzed .

4.2.1 Processes and outputs:

This matrix shows the six main processes and all of the
deliverables associated with project risk management

Process Output(deliverables)

Risk management Risk management plan(RMP)

planning
 57

Risk identification Risk Register (Register)

Qualitative risk analysis Risk Register (updates)
Prioritized list of risks classified as
high, moderate, or low
Quantitative risk analysis Quantitative Risk Analysis Reports
Numerical analysis of the project’s
likelihood of achieving its overall
objectives
(Risk Register updates)
Risk response planning 1- Risk Register (updates)
2- Project Management Plan
(updates)
3- Project Risk Management Plan
(updates)
4- Risk-related contractual
agreements
The outcome may result in one or
more of the following: residual risks,
secondary risks, change control,
contingency reserve (amounts of
time or budget needed).
Risk monitoring and Risk Register (updates)
control The outcome may result in
workaround plans, corrective
actions, programming change
request (PCR), and updates to risk
identification checklists for future
projects

4.3 RISK MANAGEMENT PLANNING

Risk management planning is the process of deciding how to

approach and plan for risk management activities for a project, and
the main output of this process is a risk management plan A risk
management plan documents the procedure for managing risk
throughout the project.

The project team should hold several planning meeting early

in the project’s life cycle to help develop the risk management plan.
The project team should review the project documents as well as
corporate risk management policies, risk categories, lessons
learned reports from past projects and templates for creating risk
management plan.

Careful and explicit planning enhances the possibility of

success of the other risk management processes. Risk
Management Planning is the process of deciding how to approach
 58

and conduct the risk management activities for a project. Planning

of risk management processes is important to ensure that the level,
type, and visibility of risk management are commensurate with both
the risk and importance of the project to the organization, to provide
sufficient resources and time for risk management activities, and to
establish an agreed-upon basis for evaluating risks. The Risk
Management Planning process should be completed early during
project planning, since it is crucial to successfully performing the
other processes described in this handbook.

The result of Risk Management Planning is a Risk

Management Plan. The risk management plan identifies and
establishes the activities of risk management for the project in the
project plan (RMP)

A risk management plan summarizes how risk management

will be performed on a particular project. Like other specific
knowledge area plans it becomes a subset of project management
plan The following table lists the general topics that a risk
management plan should address It is important to clarify roles and
responsibilities, prepare budget and schedule estimates for risk-
related work, and .identify risk categories for consideration. It is
also important to describe how risk management will be done,
including assessment of risk probabilities and impacts as well as
creation of risk related documentation.

Methodology: How will risk management will be performed on this

project?. What tools and data sources are available and
applicable?

Roles and responsibilities: who are the individuals responsible for

implementing specific tasks and providing deliverables related to
risk management

Budget and schedule: What are the estimated costs and

schedules for performing risk related activities?

Risk Categories: What are the main categories of risk that should
be addressed on this project?. Is there a risk breakdown structure
for the project

Risk Probability and Impact: How will the probabilities and

impacts of risk items be assessed?. What scoring and interpretation
methods will be used for the qualitative and quantitative analysis of
risks?

Risk Documentation: What reporting formats and processes will

used for risk management activities?
 59

In addition to risk management plan many projects also

include contingency plans, fallback plans, and contingency
reserves. Contingency plans are predefined actions that the project
team will take if an identified risk event occurs. For example ,if the
project team knows that a new release of a software package may
not be available in time for them to use it for their project, they
might have a contingency plan to use the older version of the
software.

Fallback plans are developed for risks that have a high

impact on meeting project objectives and are put in to effect if
attempts to reduce risks are not effective. For example , a new
college graduate might have a main plan and several contingency
plans on where to live after graduation, but if none of the plans
work out a fallback plan might be to live at home for a while.
Sometimes contingency plans and fallback plans are used
interchangeably.

Contingency reserves or contingency allowances are

provisions held by the project sponsor or organization to reduce the
risk of cost or schedule overruns to an acceptable level. For
example if a project appears to be off course because the the staff
is inexperienced with some new technology and the team had not
identified it as a risk ,the project sponsor may provide additional
funds from contingency reserves to hire an outside consultant to
train and advise the project staff in using the new technology.

4.4 COMMON SOURCES OF RISK IN INFORMATION

TECHNOLOGY PROJECTS

Several studies show that IT projects share some common

sources of risk. The Standish Group developed an IT success
potential scoring sheet based on potential risks. Other broad
categories of risk help identify potential risks.

Information Technology Success Potential Scoring Sheet

Success Criterion Relative Importance

User Involvement 19
Executive Management support 16
Clear Statement of 15
Requirements
Proper Planning 11
Realistic Expectations 10
Smaller Project Milestones 9
Competent Staff 8
 60

Ownership 6
Clear Visions and Objectives 3
Hard-Working, Focused Staff 3
Total 100
The Standish Group provides specific questions for each
success criterion to help decide the number of points to assign to a
project. For example the five questions related to user involvement
include the following
Do I have the right user(s)?
Did I involve the users early and often?
Do I have a quality relationship with user(s)?
Do I make involvement easy
Did I find out what the user(s) need(s)?

The number of questions corresponding to each success

criterion determines the number of points each positive response is
assigned. For example in the case of user involvement there are
five questions . For each positive reply , you would get(19/5) 3.8
points . !9 represents the weight of the criterion and five represents
the number of questions. Therefore ,you would assign a value to
the user involvement criterion by adding 3.8 points to the score for
each question you can answer positively.

4.4.1 Categories of Risk:

A broad categories of risks are described on the

questionnaires developed by many organizations. Some of them
are given below.

� Market risk: If the information technology project is to produce a

new product or service will it be useful to the organization or
marketable to others?. Will user accept the product or service?. Will
someone else make a better product or service faster, making the
project a waste of time and money.

� Financial risk: Can the organization afford to undertake the

project?. How confident are the stakeholders in the financial
projections?. Will the project meet NPV,ROI, and payback
estimates?. If not van the organization afford to proceed the
project?. Is this project the best way to use the organization’s
financial resources?

� Technology risk: Is the project technically feasible?. Will it use

mature, leading edge or bleeding edge technologies? When will
decisions be made on which technology to use? Will H/w, S/w and
network function properly?. You can also breakdown the
technology risk into h/w, s/w, and network technology if required.
 61

� People risk: Does the organization have or can they find people
with appropriate skills to complete the project successfully?. Do
they have enough experience?. Does senior management support
the project?. Is the organization familiar sponsor/customer for the
project?. How good is the relationship with the sponsor/customer?
� Structure/process risk: What is the degree of change the new
project will introduce into user areas and business procedures?
How many distinct user groups does the project need to satisfy?
With how many other systems does the project need to interact?
Does the organization have processes in place to complete the
project successfully?

4.4.2 Risk Breakdown Structure:

� A risk breakdown structure is a hierarchy of potential risk

categories for a project. Similar to a work breakdown structure but
used to identify and categorize risks. A sample shown below.

A risk break down structure is a useful tool that can help

project managers consider potential risks in different categories.
The highest level categories are business, technical, and
organizational and project management. Competitors suppliers,
and cash flow are categories that fall under business risks. Under
technical risk are the categories h/w, s/w, and network.
 62

A risk break down structure provides a simple, one page

chart to help ensure a project team is considering important risk
categories related to all information technology projects.

The following table shows the potential negative risk

conditions that can exist within each knowledge area.

Potential Risk Conditions Associated With Each Knowledge Area

4.5 RISK IDENTIFICATION

Risk identification involves identifying potential project risks.

Risk Identification produces a deliverable — the project Risk
Register – where risks are identified that may affect the project’s
ability to achieve its objectives. Risk Identification documents which
risks might affect the project and documents their characteristics.
The Risk Register is subsequently amended with the results from
qualitative risk analysis and risk response planning, and is reviewed
and updated throughout the project.

Participants in risk identification activities can include the

following, where appropriate: project manager, project team
members, risk management team (if assigned), subject matter
experts both from the project and from outside the project team,
customers, end users, other project managers, stakeholders, and
risk management experts. While these personnel are often key
 63

participants for risk identification, all project personnel should be

encouraged to identify risks.

4.5.1 Suggestions For Identifying Risks:

The assigned team members identify the potential risks

(threats and opportunities), using
� The risk breakdown structure, suitably tailored to the project.
� The sample risk list
� Their own knowledge of the project or similar projects.
� Consultation with others who have significant knowledge of the
project or its environment.
� Consultation with others who have significant knowledge of
similar projects.

There are several other tools and techniques also for

identifying risks Five common information gathering techniques for
risk identification include brainstorming ,Delphi technique
,interviewing ,root cause analysis, and SWOT analysis.

1. Brain Storming:
It is a technique by which a team attempt to generate ideas
or find solutions for a specific by amassing ideas spontaneously
and with out judgment . This approach can help the group create a
comprehensive list of risks to address later in the qualitative and
quantitative risk analysis process. An experienced facilitator should
run the brainstorming session and introduce new categories of
potential risks to keep the ideas flowing . After the ideas are
collected ,the facilitator can group and categorize the ideas to make
them more manageable

2. Delphi Technique:
The Delphi Technique is used to derive a consensus among
a panel of experts who make predictions about future
developments. It Provides independent and anonymous input
regarding future events. Uses repeated rounds of questioning and
written responses and avoids the biasing effects possible in oral
methods, such as brainstorming.

3. Interviewing:
Interviewing is a fact-finding technique for collecting
information in face-to-face, phone, e-mail, or instant messaging
discussions. Interviewing people with similar project experience is
an important tool for identifying potential risks.

4. SWOT Analysis:
 SWOT analysis (strengths, weaknesses, opportunities,and
threats) can also be used during risk identification.
 64

 Helps identify the broad negative risks that apply to a

project.

Applying SWOT to specific potential projects can help

identify the broad risks and opportunities that apply in that scenario
Some other techniques for risk identification are

5. Use of checklists :
The list of risks that have been encountered in previous
projects provide meaningful template for understanding risks in
current projects.

It is important to analyze project assumptions to make sure

that they are valid. Incomplete, inaccurate or inconsistent
assumptions might lead to identifying more risks.

6. Diagramming Technique:
This method include using cause and effect diagrams or
fishbone diagrams ,flow charts and influence diagrams .Fishbone
diagrams help you trace problems back to their root cause. Process
flow charts are diagrams that show how different parts of the
system interrelate.

4.5.2 The Risk Register:

The main output of the risk identification process is a list of

identified risks and other information needed to begin creating a
risk register.

A risk register is:

� A document that contains the results of various risk management
processes and that is often displayed in a table or spreadsheet
format.
� A tool for documenting potential risk events and related
information.
Risk Register Contents
� An identification number for each risk event.
� A rank for each risk event.
� The name of each risk event.
� A description of each risk event.
� The category under which each risk event falls.
� The root cause of each risk.
 65

� Triggers for each risk; triggers are indicators or symptoms of

actual risk events.
� Potential responses to each risk.
� The risk owner or person who will own or take responsibility for
each risk.
� The probability and impact of each risk occurring.
� The status of each risk.
Sample Risk Register

4.6 QUALITATIVE RISK ANALYSIS

� Assess the likelihood and impact of identified risks to determine

their magnitude and priority.
� Risk quantification tools and techniques include:
� Probability/impact matrixes
� The Top Ten Risk Item Tracking
� Expert judgment

4.6.1 Using Probability/Impact Matrix To Calculate Risk

Factors:

 A probability/impact matrix or chart lists the relative

probability of a risk occurring on one side of a matrix or axis
on a chart and the relative impact of the risk occurring on the
other.

 List the risks and then label each one as high, medium, or
low in terms of its probability of occurrence and its impact if it
did occur.
 66

It may be useful to create separate Probability/Impact Matrix

or chart for negative risks and positive risks to make sure both
types of risks are adequately addressed. Qualitative analysis is
normally done quickly so that the project team has to decide what
type of approach makes the most sense for their project. To
quantify risk probability and consequence, the Defense Systems
Management College developed a technique for calculating risk
factors – the numbers that represent the overall risk of specific
events ,based on their probability of occurring and consequences to
the project if they do occur. The technique makes use of
Probability/Impact Matrix that shows the probability of risks
occurring and the impact or consequences of the risks.

Probability of a risk occurring can be estimated based on

several factors as determined by the unique nature of each project .
For example factors evaluated for potential H/W or S/W technology
risks could include the technology not being mature, the technology
being too complex, and an inadequate support base for developing
the technology. The impact of a risk occurring could include factors
such as availability of fallback solutions or the consequences of not
meeting performance , cost and schedule estimates

Sample Probability/Impact Matrix

The following figure gives an example of how the risk factors

were used to graph the probability of failure and consequence of
failure for proposed technologies. The figure classifies potential
 67

technologies (dots on the charts) as high, medium, or low risk

based on the probability of failure and consequence of failure. The
researchers for this study highly recommended that the US Air
Force invest in the low to medium risk technologies and suggested
that it not pursue the high risk technologies. It can be seen that the
rigor behind using Probability/Impact Matrix and risk factors
provides a much stronger argument than simply stating the risk
probabilities or consequences are high, medium, or low

Chart Showing High-, Medium-, and Low-

Risk Technologies

4.6.2 Top Ten Risk Item Tracking:

Top Ten Risk Item Tracking is a qualitative risk analysis tool

that helps to identify risks and maintain an awareness of risks
throughout the life of a project. Establish a periodic review of the
top ten project risk items.

The review begins with a summary of the status of top ten

sources of risk on the project. The summary includes each item’s
current ranking previous ranking, number of times it appears on the
list over a period of time, and a summary of progress made in
resolving the risk item since the previous review.

List the current ranking, previous ranking, number of times

the risk appears on the list over a period of time, and a summary of
progress made in resolving the risk item.
 68

The following figure provides an example of Top Ten Risk

Item Tracking chart that could be used at a management review
meeting for a project. This includes only the top five negative risk
events. Each risk event is ranked based on the current month,
previous month, and how many months it has been in the top ten.
The last column briefly describes the progress for resolving each
particular risk item

Example of Top Ten Risk Item Tracking

4.6.3 Expert Judgment:

Many organizations rely on the intuitive feelings and past

experience of experts to help identify potential project risks.
Experts can categorize risks as high, medium, or low with or
without more sophisticated techniques.

The main output of qualitative risk analysis is updating the

risk register .The ranking column of the risk register should be filled
in along with numeric value or high, medium, low for the probability
and impact of the risk event. Additional information is often added
for risk events, such as identification of risks that need more
attention in the near term or those that can be placed on a watch
list. A watch list is a list of risks that are low priority , but are still
 69

identified as potential risks. Qualitative analysis can also identify

risks that should be evaluated on a quantitative basis.

4.7 QUANTITATIVE RISK ANALYSIS

Often follows qualitative risk analysis, but both can be done

together.

Large, complex projects involving leading edge technologies

often require extensive quantitative risk analysis.
Main techniques include:
 Decision tree analysis
 Simulation
 Sensitivity analysis
Quantitative risk analysis is a way of numerically estimating
the probability that a project will meet its cost and time objectives.
Quantitative analysis is based on a simultaneous evaluation of the
impact of all identified and quantified risks. The result is a
probability distribution of the project’s cost and completion date
based on the identified risks in the project.
Quantitative risk analysis involves statistical techniques,
primarily Monte Carlo simulation that is most widely and easily used
with specialized software.
Quantitative risk analysis starts with the model of the project,
either its project schedule or its cost estimate depending on the
objective. The degree of uncertainty in each schedule activity and
each line-item cost element is represented by a probability
distribution. The probability distribution is usually specified by
determining the optimistic, the most likely and the pessimistic
values for the activity or cost element – this is typically called the
“3-point estimate.” The three points are estimated during an
interview with subject matter experts who usually focus on the
schedule or cost elements one at a time. The risks that lead to the
three points are recorded for the quantitative risk analysis report
and for risk response planning. For each activity or cost element a
probability distribution type is chosen that best represents the risks
discussed in the interview. Typical distributions usually include the
triangular, beta, normal and uniform.

4.7.1 Decision Trees and Expected monetary Value:

A decision tree is a diagramming analysis technique used to
help select the best course of action in situations in which future
outcomes are uncertain.
� Estimated monetary value (EMV) is the product of a risk event
probability and the risk event’s monetary value.
 70

� You can draw a decision tree to help find the EMV.

To create a decision tree and to calculate expected

monetary value specifically, you must estimate the probabilities, of
certain events occurring. For example in the following figure there is
a 20 percent probability(P=.20) that Cliff’s firm will win the contract
project1, which is estimated to be $300,000 in profits- the outcome
of the top branch in the figure. There is an 80 percent probability
that it will not win the contract for the project, and the outcome is
estimated to be -$40,000 meaning that the firm has to invest
$40,000 into project1with no reimbursement if it is not awarded the
contract.
To calculate EMV for each project, multiply the probability by
the outcome value for each potential outcome for each project .
The EMV for project 1 is 0.2($300,000)+0.8(-40,000)=$60,000-
$32000=28,000

4.7.2 Simulation:
A specialized Monte Carlo simulation software program runs
(iterates) the project schedule or cost estimate many times, drawing
duration or cost values for each iteration at random from the
probability distribution derived from the 3-point estimates and
probability distribution types selected for each element. The Monte
Carlo software develops from the results of the simulation a
probability distribution of possible completion dates and project
costs. From this distribution it is possible to answer such questions
as:
• How likely is the current plan to come in on schedule or on
budget?
• How much contingency reserve of time or money is needed to
provide the agency with a sufficient degree of certainty?
 71

• Using sensitivity analysis, which activities or line-item cost

elements contribute the most to the possibility of overrunning
schedule or cost targets?

4.7.3 Sensitivity Analysis:

 Sensitivity analysis is a technique used to show the effects
of changing one or more variables on an outcome.
 For example, many people use it to determine what the
monthly payments for a loan will be given different interest
rates or periods of the loan, or for determining break-even
points based on different assumptions.
 Spreadsheet software, such as Excel, is a common tool for
performing sensitivity analysis.
The following figure shows an example Excel file created to
quickly show the break-even point for a product based on various
inputs-the sales price per unit, manufacturing cost per unit, and
fixed monthly expenses. The current inputs result I a break-even
point of 6,250 units sold. Users of this spreadsheet can change
inputs and see the effects on the break-even point in chart format.
Project teams often create similar models to determine the
sensitivity of various project variables.
 72

The main outputs of quantitative risk analysis are updates to

the risk register, such as revised risk rankings or detailed
information behind those rankings. The quantitative analysis also
provides high level information in terms of the probabilities of
achieving certain projects objectives. This information might cause
the project manager to suggest changes in contingency reserves .

4.8 RISK RESPONSE PLANNING

 73

Risk Response Planning is the process of developing

options, and determining actions to enhance opportunities and
reduce threats to the project’s objectives. It focuses on the high-risk
items evaluated in the qualitative and/or quantitative risk analysis.
In Risk Response Planning parties are identified and assigned to
take responsibility for each risk response. This process ensures
that each risk requiring a response has an owner monitoring the
responses, although a different party may be responsible for
implementing the risk handling action itself.

The project manager and the PDT identify which strategy is

best for each risk, and then design specific action(s) to implement
that strategy.

Strategies for Negative Risks or Threats include:

� Avoid: Risk avoidance involves changing the project plan to

eliminate the risk or to protect the project objectives (time, cost,
scope, quality) from its impact. The team might achieve this by
changing scope, adding time, or adding resources (thus relaxing
the so-called “triple constraint”).

These changes may require a Programming Change

Request (PCR). Some negative risks (threats) that arise early in the
project can be avoided by clarifying requirements, obtaining
information, improving communication, or acquiring expertise.

� Transfer: Risk transference requires shifting the negative impact

of a threat, along with ownership of the response, to a third party.
An example would be the team transfers the financial impact of risk
by contracting out some aspect of the work.

Transference reduces the risk only if the contractor is more

capable of taking steps to reduce the risk and does so. Risk
transference nearly always involves payment of a risk premium to
the party taking on the risk.

Transference tools can be quite diverse and include, but are

not limited to the use of: insurance, performance bonds, warranties,
guarantees, incentive/disincentive clauses, A+B Contracts, etc.

� Mitigate. Risk mitigation implies a reduction in the probability

and/or impact of an adverse risk event to an acceptable threshold.
Taking early action to reduce the probability and/or impact of a risk
is often more effective than trying to repair the damage after the
risk has occurred.

Risk mitigation may take resources or time and hence may

represent a tradeoff of one objective for another. However, it may
 74

still be preferable to going forward with an unmitigated risk.

Monitoring the deliverables closely, increasing the number of
parallel activities in the schedule, early involvement of regulatory
agencies in the project, early and continuous outreach to
communities/advocacy groups, implementing value engineering,
performing corridor studies, adopting less complex processes,
conducting more tests, or choosing a more stable supplier are
examples of mitigation actions.

General Risk Mitigation Strategies for Technical, Cost, and

Schedule Risks

Strategies for Positive Risks or Opportunities include:

� Exploit. The organization wishes to ensure that the opportunity

is realized. This strategy seeks to eliminate the uncertainty
associated with a particular upside risk by making the opportunity
definitely happen. Examples include securing talented resources
that may become available for the project.

� Share. Allocating ownership to a third party who is best able to

capture the opportunity for the benefit of the project. Examples
include: forming risk-sharing partnerships, teams, working with
elected officials, special-purpose companies, joint ventures, etc.

� Enhance. This strategy modifies the size of an opportunity by

increasing probability and/or positive impacts, and by identifying
and maximizing key drivers of these positive-impact risks. Seeking
to facilitate or strengthen the cause of the opportunity, and
proactively targeting and reinforcing its trigger conditions, might
increase probability. Impact drivers can also be targeted, seeking to
increase the project’s susceptibility to the opportunity.
 75

� Acceptance. A strategy that is adopted because it is either not

possible to eliminate that risk from a project or the cost in time or
money of the response is not warranted by the importance of the
risk. When the project manager and the project team decide to
accept a certain risk(s), they do not need to change the project plan
to deal with that certain risk, or identify any response strategy other
than agreeing to address the risk if and when it occurs. A
workaround plan may be developed for that eventuality.

There are two types of acceptance strategy:

1. Active acceptance. The most common active acceptance

strategy is to establish a contingency reserve, including amounts of
time, money, or resources to handle the threat or opportunity.

2- Passive acceptance. Requires no action leaving the project

team to deal with the threats or opportunities as they occur.

i. Workaround:
Workaround is distinguished from contingency plan in that a
workaround is a recovery plan that is implemented if the event
occurs, whereas a contingency plan is to be implemented if a
trigger event indicates that the risk is very likely to occur.

As with risk identification process, the team should also

consider residual risks, secondary risks, and risk interaction in the
risk response planning process. See page 10 for details.

4.9 RISK MONITORING AND CONTROL

Risk monitoring and control keeps track of the identified

risks, residual risks, and new risks. It also monitors the execution of
planned strategies on the identified risks and evaluates their
effectiveness.

Risk monitoring and control continues for the life of the

project. The list of project risks changes as the project matures,
new risks develop, or anticipated risks disappear.

Typically during project execution there should be regularly

held risk meetings during which all or a part of the Risk Register is
reviewed for the effectiveness of their handling and new risks are
discussed and assigned owners. Periodic project risk reviews
repeat the process of identification, analysis, and response
planning. The project manager ensures that project risk is an
agenda item at all PDT meetings. Risk ratings and prioritization
commonly change during the project lifecycle.
 76

If an unanticipated risk emerges, or a risk’s impact is greater

than expected, the planned response may not be adequate. The
project manager and the PDT must perform additional response
planning to control the risk.

Risk control involves:

�Choosing alternative response strategies
�Implementing a contingency plan
�Taking corrective actions
�Re-planning the project, as applicable

The individual or a group assigned to each risk (risk owner)

reports periodically to the project manager and the risk team leader
on the status of the risk and the effectiveness of the response plan.
The risk owner also reports on any unanticipated effects, and any
mid-course correction that the PDT must consider in order to
mitigate the risk.

4.10. USING SOFTWARE TO ASSIST IN PROJECT

RISK MANAGEMENT

Most organizations use software to create , update , and

distribute informations in their risk registers.The risk register is often
a word or excel file but it can also be part of a more sophisticated
database. Spreadsheets can aid in tracking and quantifying risk ,
preparing charts and graphs , and performing sensitivity analysis.
Software can be used to create decision trees and estimated
monitary values.

More sophisticated risk management software such as

Monte Carlo Simulation s/w can help you develop models and use
simulations to analyze and respond to various risks. There are
also several s/w packages created specifically for project risk
management . If a risk is not identified.

Software should be used as a tool to help make good

decisions in project risk management, not as a scapegoat for when
things go wrong.

4.11 SUMMARY
CLUSIONS
Risk Management is always forgotten when managing
projects but the irony is that all projects have risk. People in general
think that risk management is just a blaming session to uncover
flaws in a particular project. This perception has to be abolished.
 77

Management and Project managers have to understand that

Risk Management is the one of the few practical way to manage
uncertainties and doubts towards a particular project.

Risk can never be abolished, but can only be reduced to an

acceptable level. Risk Management is a must for any projects and it
has to be done from the initiation phase throughout the project
lifecycle. Risk Management is not free, and it isn’t cheap. There
may need to have third party audits which incur cost. There must
always be continual management support and commitment to
ensure the success of projects.

This chapter we discussed the importance of risk

management in the projects and also were able to understand the
different processes in the risk management, which consists of the
following actions

� Project risk management is the art and science of identifying,

analyzing, and responding to risk throughout the life of a project
and in the best interests of meeting project objectives.

Main processes include:

 Risk management planning
 Risk identification
 Qualitative risk analysis
 Quantitative risk analysis
 Risk response planning
 Risk monitoring and control

Sample Questions
1. Discuss the common sources of risk on information technology
projects and suggestions for managing them. (Ans:section 4.4)

2. Explain how to use decision trees and Monte Carlo analysis for
quantifying risk. (Ans Hint: section 4.7.1)

Suggested Readings:
1. Boehm ,Barry W. “ Software Risk management: Principles and
practices”
2. Kathy Schwalbe : Information Technology project management
3. Hillson , David. : The risk breakdown structure as an aid to
effective risk management
4. DeMarco,Tom and Timothy Lister: Managing Risk on software
projects
4. www.risksig.com

 78

5
PROJECT PROCUREMENT
MANAGEMENT

Unit Structure:
5.0 Objectives
5.1 Introduction
5.2 Planning Purchases and Acquisitions (Procurement Planning)
5.2.1 Inputs to Procurement Planning
5.2.2 Tools and Techniques for Procurement Planning
5.2.3 Outputs from Procurement Planning
5.3 Solicitation Planning (Planning Contracting)
5.3.1 Tools and Techniques for Solicitation Planning
5.3.2 Outputs from Solicitation Planning
5.4 Requesting Seller Responses (Solicitation)
5.4.1 Inputs to Solicitation
5.4.2 Tools and Techniques for Solicitation
5.4.3 Outputs from Solicitation
5.5 Source Selection (Selecting Sellers)
5.5.1 Inputs to Source Selection
5.5.2 Tools and Techniques for Source Selection
5.5.3 Outputs from Source Selection
5.6 Contract Administration
5.6.1 Inputs to Contract Administration
5.6.2 Suggestions for Change Control in Contracts
5.6.3 Tools and Techniques for Contract Administration
5.6.4 Outputs from Contract Administration
5.7 Contract Close-Out
5.7.1 Inputs to Contract Close-out
5.7.2 Tools and Techniques for Contract Close-out
5.7.3 Outputs from Contract Close-out
5.8 Using Software to Assist in Project Procurement Management
5.9 Out Sourcing
5.9.1 Benefits of outsourcing
5.10 Summary
 79

5.0 OBJECTIVES

 To understand the importance of project procurement

Management
 To describe project procurement management processes
 Procurement planning
 Solicitation planning
 Solicitation
 Source selection
 Contract administration
 Contract close-out

5.1 INTRODUCTION

Project Procurement Management includes the processes

required to acquire goods and services from outside the performing
organization. For simplicity, goods and services, whether one or
many, will generally be referred to as a “product.” Figure 5.1
provides an overview of the following major processes:

5.2 Procurement Planning—determining what to procure and

when.

5.3 Solicitation Planning—documenting product requirements and

identifying potential sources.

5.4 Solicitation—obtaining quotations, bids, offers, or proposals

as appropriate.

5.5 Source Selection—choosing from among potential sellers.

5.6 Contract Administration—managing the relationship with the

seller.

5.7 Contract Close-out—completion and settlement of the

contract, including resolution of any open items.

These processes interact with each other and with the

processes in the other knowledge areas as well. Each process may
involve effort from one or more individuals or groups of individuals
based on the needs of the project. Although the processes are
presented here as discrete elements with well-defined interfaces, in
practice they may overlap and interact in ways not detailed here.
 80

Project Procurement Management is discussed from the

perspective of the buyer in the buyer-seller relationship. The buyer-
seller relationship can exist at many levels on one project.
Depending on the application area, the seller may be called a
contractor, a vendor, or a supplier.

The seller will typically manage their work as a project. In such

cases:

• The buyer becomes the customer and is thus a key stakeholder

for the seller.

• The seller’s project management team must be concerned with all

the processes of project management, not just with those of this
knowledge area.

• The terms and conditions of the contract become a key input to

many of the seller’s processes. The contract may actually contain
the input (e.g., major deliverables, key milestones, cost
objectives) or it may limit the project team’s options (e.g., buyer
approval of staffing decisions is often required on design
projects).

This chapter assumes that the seller is external to the

performing organization.

Most of the discussion, however, is equally applicable to

formal agreements entered into with other units of the performing
organization. When informal agreements are involved, the
processes described in Project Human Resource Management,,
and Project Communications Management, are more likely
to apply.
 81

Figure 5.1

5.2 PLANNING PURCHASES AND ACQUISITIONS

(PROCUREMENT PLANNING)

Procurement planning is the process of identifying which

project needs can be best met by procuring products or services
outside the project organization. It involves consideration of
whether to procure, how to procure, what to procure, how much to
procure, and when to procure it.

When the project obtains products and services from outside

the performing organization, the processes from solicitation
 82

planning through contract close-out would be performed once for

each product or service item.

The project management team should seek support from

specialists in the disciplines of contracting and procurement when
needed.

When the project does not obtain products and services from
outside the performing organization, the processes from solicitation
planning through contract close-out would not be performed. This
often occurs on research and development projects when the
performing organization is reluctant to share project technology,
and on many smaller, in-house projects when the cost of finding
and managing an external resource may exceed the potential
savings.

Procurement planning should also include consideration of

potential subcontracts, particularly if the buyer wishes to exercise
some degree of influence or control over subcontracting decisions.

Steps in procurement planning

5.2.1 Inputs to Procurement Planning:

1 Scope statement: The scope statement describes the current

project boundaries. It provides important information about project
needs and strategies that must be considered during procurement
planning.

2 Product description: The description of the product of the

project provides important information about any technical issues or
concerns that would need to be considered during procurement
planning.

The product description is generally broader than a

statement of work. A product description describes the ultimate
end-product of the project; a statement of work describes the
portion of that product to be provided by a seller to the project.
However, if the performing organization chooses to procure the
 83

entire product, the distinction between the two terms becomes

moot.

3 Procurement resources: If the performing organization does not

have a formal contracting group, the project team will have to
supply both the resources and the expertise to support project
procurement activities.
4 Market conditions: The procurement planning process must
consider what products and services are available in the
marketplace, from whom, and under what terms and conditions.
5 Other planning outputs: To the extent that other planning
outputs are available, they must be considered during procurement
planning. Other planning outputs which must often be considered
include preliminary cost and schedule estimates, quality
management plans, cash flow projections, the work breakdown
structure, identified risks, and planned staffing.
6 Constraints: Constraints are factors that limit the buyer’s
options. One of the most common constraints for many projects is
funds availability.
7 Assumptions: Assumptions are factors that, for planning
purposes, will be considered
to be true, real, or certain.

5.2.2 Tools and Techniques for Procurement Planning:

1. Make-or-buy analysis: This is a general management technique

which can be used to determine whether a particular product can
be produced cost-effectively by the performing organization. Both
sides of the analysis include indirect as well as direct costs. For
example, the “buy” side of the analysis should include both the
actual out of- pocket cost to purchase the product as well as the
indirect costs of managing the purchasing process.

A make-or-buy analysis must also reflect the perspective of

the performing organization as well as the immediate needs of the
project. For example, purchasing a capital item (anything from a
construction crane to a personal computer) rather than renting it is
seldom cost effective. However, if the performing organization has
an ongoing need for the item, the portion of the purchase cost
allocated to the project may be less than the cost of the rental.

Make-or-Buy Example:

� Assume you can lease an item you need for a project for
$150/day. To purchase the item, the cost is $1,000 plus a daily
operational cost of $50/day.
 84

� How long will it take for the purchase cost to be the same as the
lease cost?
� If you need the item for 12 days, should you lease it or purchase
it?

Make-or Buy Solution:

 Set up an equation so the “make” is equal to the “buy”
 In this example, use the following equation. Let d be the
number of days to use the item.
$150d = $1,000 + $50d
 Solve for d as follows:
 Subtract $50d from the right side of the equation to get
$100d = $1,000
 Divide both sides of the equation by $100
d = 10 days
 The lease cost is the same as the purchase cost at 10 days
 If you need the item for 12 days, it would be more
economical to
purchase it

2 Expert judgment: Expert judgment will often be required to

assess the inputs to this process. Such expertise may be provided
by any group or individual with specialized knowledge or training
and is available from many sources including:
 Other units within the performing organization.
 Consultants.
 Professional and technical associations.
 Industry groups.

3 Contract type selection: Different types of contracts are more or

less appropriate for different types of purchases. Contracts
generally fall into one of three broad categories:

 Fixed price or lump sum contracts—this category of contract

involves a fixed total price for a well-defined product. To the
extent that the product is not well-defined, both the buyer
and seller are at risk—the buyer may not receive the desired
product or the seller may need to incur additional costs in
order to provide it. Fixed price contracts may also include
incentives for meeting or exceeding selected project
objectives such as schedule targets.
 85

 Cost reimbursable contracts—this category of contract

involves payment (reimbursement) to the seller for its actual
costs. Costs are usually classified as direct costs or indirect
costs. Direct costs are costs incurred for the exclusive
benefit of the project (e.g., salaries of full-time project staff).
Indirect costs, also called overhead costs, are costs
allocated to the project by the performing organization as a
cost of doing business (e.g., salaries of corporate
executives). Indirect costs are usually calculated as a
percentage of direct costs. Cost reimbursable contracts
often include incentives for meeting or exceeding selected
project objectives such as schedule targets or total cost.

Three types of cost reimbursable contracts in order of lowest

to highest risk to the buyer include cost plus incentive fee, cost
plus fixed fee, and cost plus percentage of costs With a cost plus
incentive fee (CPIF) contract the buyer pays the supplier for
allowable performance cost along with a predetermined fee and an
incentive bonus.if the final Cost is less than the expected cost,
both the buyer and the supplier benefit from the cost saving.
With a cost plus fixed fee (CPFF) contract the buyer pays
the supplier for the allowable performance cost plus a fixed fee
payment usually based on a percentage of estimated costs.
With a cost plus percentage of costs(CPPC) contract the
buyer pays the supplier for allowable performance costs along with
a predetermined percentage based on the total costs.
 Unit price contracts—the seller is paid a preset amount per
unit of service (e.g., $70 per hour for professional services
or $1.08 per cubic yard of earth removed), and the total
value of the contract is a function of the quantities needed to
complete the work.
Contract Types Versus Risk
 86

5.2.3 Outputs from Procurement Planning:

1. Procurement management plan. The procurement

management plan should describe how the remaining procurement
processes (from solicitation planning through contract close-out)
will be managed. For example:
• What types of contracts will be used?
• If independent estimates will be needed as evaluation criteria,
who will prepare them and when?
• If the performing organization has a procurement department,
what actions can the project management team take on its own?
• If standardized procurement documents are needed, where can
they be found?
• How will multiple providers be managed?
• How will procurement be coordinated with other project aspects
such as scheduling and performance reporting?

A procurement management plan may be formal or informal,

highly detailed or broadly framed, based on the needs of the
project. It is a subsidiary element of the overall project plan.

2 Statement(s) of work: The statement of work (SOW) describes

the procurement item in sufficient detail to allow prospective sellers
to determine if they are capable of providing the item. “Sufficient
detail” may vary based on the nature of the item, the needs of the
buyer, or the expected contract form.

Some application areas recognize different types of SOW.

For example, in some government jurisdictions, the term SOW is
reserved for a procurement item that is a clearly specified product
or service, and the term Statement of Requirements (SOR) is used
for a procurement item that is presented as a problem to be solved.
The statement of work may be revised and refined as it moves
through the procurement process. For example, a prospective
seller may suggest a more efficient approach or a less costly
product than that originally specified. Each individual procurement
item requires a separate statement of work. However, multiple
products or services may be grouped as one procurement item with
a single SOW.

The statement of work should be as clear, as complete, and

as concise as possible.

It should include a description of any collateral services

required, such as performance reporting or post-project operational
support for the procured item. In some application areas, there are
 87

specific content and format requirements for a SOW. The following

figure shows a template of statement of work.

Statement of Work (SOW) Template

5.3 SOLICITATION PLANNING (PLANNING

CONTRACTING)

Solicitation planning involves preparing the documents needed to

support solicitation
.

Steps in solicitation planning

5.3.1 Tools and Techniques for Solicitation Planning:

1. Standard forms: Standard forms may include standard

contracts, standard descriptions of procurement items, or
 88

standardized versions of all or part of the needed bid documents.

Organizations that do substantial amounts of procurement should
have many of these documents standardized.

2. Expert judgment: Expert judgment is described in

Section 5.2.2.

5.3.2 Outputs from Solicitation Planning:

1. Procurement documents: Procurement documents are used to

solicit proposals from prospective sellers. The terms “bid” and
“quotation” are generally used when the source selection decision
will be price-driven (as when buying commercial items), while the
term “proposal” is generally used when non-financial considerations
such as technical skills or approach are paramount (as when
buying professional services).
However, the terms are often used interchangeably and care
should be taken not to make unwarranted assumptions about the
implications of the term used.

Common names for different types of procurement

documents include: Invitation for bid (IFB), Request for Proposal
(RFP), Request for Quotation (RFQ), Invitation for Negotiation, and
Contractor Initial Response.
Procurement documents should be structured to facilitate
accurate and complete responses from prospective sellers. They
should always include the relevant statement of work, a description
of the desired form of the response, and any required contractual
provisions (e.g., a copy of a model contract, non-disclosure
provisions).
Some or all of the content and structure of procurement
documents, particularly for those prepared by a government
agency, may be defined by regulation.
Procurement documents should be rigorous enough to
ensure consistent, comparable responses, but flexible enough to
allow consideration of seller suggestions for better ways to satisfy
the requirements. The following figure shows a template for RFP

Request For proposal Template

I. Purpose of RFP
II. Organization’s Background
III. Basic Requirements
IV. Hardware and Software Environment
V. Description of RFP Process
VI. Statement of Work and Schedule Information
VII. Possible Appendices
 89

A. Current System Overview

B. System Requirements
C. Volume and Size Data
D. Required Contents of Vendor’s Response to RFP
E. Sample Contract

2. Evaluation criteria. Evaluation criteria are used to rate or score

proposals. They may be objective (e.g., “the proposed project
manager must be a certified Project Management Professional”) or
subjective (e.g., “the proposed project manager must have
documented, previous experience with similar projects”). Evaluation
criteria are often included as part of the procurement documents.

Evaluation criteria may be limited to purchase price if the

procurement item is known to be readily available from a number of
acceptable sources (“purchase price” in this context includes both
the cost of the item and ancillary expenses such as delivery). When
this is not the case, other criteria must be identified and
documented to support an integrated assessment. For example:

• Understanding of need—as demonstrated by the seller’s proposal.

• Overall or life cycle cost—will the selected seller produce the
lowest total cost (purchase cost plus operating cost)?
• Technical capability—does the seller have, or can the seller be
reasonably expected to acquire, the technical skills and
knowledge needed?

3. Statement of work updates. The statement of work is described

in Section 12.1.3.2.

Modifications to one or more statements of work may be identified

during solicitation planning.

5.4 REQUESTING SELLER RESPONSES

(SOLICITATION)

Solicitation involves obtaining information (bids and

proposals) from prospective sellers on how project needs can be
met. Most of the actual effort in this process is expended by the
prospective sellers, normally at no cost to the project.
 90

Steps in solicitation

5.4.1 Inputs to Solicitation:

1. Procurement documents: Procurement documents are

described in previous section.

2. Qualified seller lists: Some organizations maintain lists or files

with information on prospective sellers. These lists will generally
have information on relevant experience and other characteristics
of the prospective sellers.

If such lists are not readily available, the project team will
have to develop its own sources. General information is widely
available through library directories, relevant local associations,
trade catalogs, and similar sources. Detailed information on specific
sources may require more extensive effort, such as site visits or
contact with previous customers.

Procurement documents may be sent to some or all of the

prospective sellers.

5.4.2 Tools and Techniques for Solicitation:

1. Bidder conferences: Bidder conferences (also called

contractor conferences, vendor conferences, and pre-bid
conferences) are meetings with prospective sellers prior to
preparation of a proposal. They are used to ensure that all
prospective sellers have a clear, common understanding of the
procurement (technical requirements, contract requirements, etc.).
Responses to questions may be incorporated into the procurement
documents as amendments.

2. Advertising: Existing lists of potential sellers can often be

expanded by placing advertisements in general circulation
publications such as newspapers or in specialty publications such
as professional journals. Some government jurisdictions require
public advertising of certain types of procurement items; most
 91

government jurisdictions require public advertising of subcontracts

on a government contract.

5.4.3 Outputs from Solicitation:

1. Proposals: Proposals are seller-prepared documents that

describe the seller’s ability and willingness to provide the requested
product. They are prepared in accordance with the requirements of
the relevant procurement documents.

5.5 SOURCE SELECTION (SELECTING

SELLERS)
Source selection involves:
 Evaluating proposals or bids from sellers.
 Choosing the best one.
 Negotiating the contract.
 Awarding the contract.
 Organizations often do an initial evaluation of all proposals
and bids and then develop a short list of potential sellers
for further evaluation.

Source selection involves the receipt of bids or proposals

and the application of the evaluation criteria to select a provider.
This process is seldom straightforward:

• Price may be the primary determinant for an off-the-shelf item, but

the lowest proposed price may not be the lowest cost if the seller
proves unable to deliver the product in a timely manner.
• Proposals are often separated into technical (approach) and
commercial (price) sections with each evaluated separately.
• Multiple sources may be required for critical products.

The tools and techniques described below may be used

singly or in combination.

For example, a weighting system may be used to:

• Select a single source who will be asked to sign a standard
contract.
• Rank order all proposals to establish a negotiating sequence.

On major procurement items, this process may be iterated. A

short list of qualified sellers will be selected based on a preliminary
 92

proposal, and then a more detailed evaluation will be conducted

based on a more detailed and comprehensive proposal.

Steps in source selection

5.5.1 Inputs to Source Selection:

1. Proposals. Proposals are described in Section 5.2.2.

2. Evaluation criteria. Evaluation criteria are described in Section

5.2.2(2)

3. Organizational policies. Any and all of the organizations

involved in the project may have formal or informal policies that can
affect the evaluation of proposals.

5.5.2 Tools and Techniques for Source Selection:

1. Contract negotiation: Contract negotiation involves clarification

and mutual agreement on the structure and requirements of the
contract prior to the signing of the contract. To the extent possible,
final contract language should reflect all agreements reached.
Subjects covered generally include, but are not limited to,
responsibilities and authorities, applicable terms and law, technical
and business management approaches, contract financing, and
price.

For complex procurement items, contract negotiation may be

an independent process with inputs (e.g., an issues or open items
list) and outputs (e.g., memorandum of understanding) of its own.
Contract negotiation is a special case of the general management
skill called “negotiation.”

Negotiation tools, techniques, and styles are widely

discussed in the general management literature and are generally
applicable to contract negotiation.
 93

2. Weighting system: A weighting system is a method for

quantifying qualitative data in order to minimize the effect of
personal prejudice on source selection. Most such systems involve
(1) assigning a numerical weight to each of the evaluation criteria,
(2) rating the prospective sellers on each criterion, (3) multiplying
the weight by the rating, and (4) totaling the resultant products to
compute an overall score.

3. Screening system: A screening system involves establishing

minimum requirements of performance for one or more of the
evaluation criteria. For example, a prospective seller might be
required to propose a project manager who is a Project
Management Professional (PMP) before the remainder of their
proposal would be considered.

4 Independent estimates: For many procurement items, the

procuring organization may prepare its own estimates as a check
on proposed pricing. Significant differences from these estimates
may be an indication that the SOW was not adequate or that the
prospective seller either misunderstood or failed to respond fully to
the SOW. Independent estimates are often referred to as “should
cost” estimates.

5.5.3 Outputs from Source Selection:

1.Contract: A contract is a mutually binding agreement which

obligates the seller to provide the specified product and obligates
the buyer to pay for it. A contract is a legal relationship subject to
remedy in the courts. The agreement may be simple or complex,
usually (but not always) reflecting the simplicity or complexity of the
product. It may be called, among other names, a contract, an
agreement, a subcontract, a purchase order, or a memorandum of
understanding

5.6 CONTRACT ADMINISTRATION

Contract administration is the process of ensuring that the

seller’s performance meets contractual requirements. On larger
projects with multiple product and service providers, a key aspect of
contract administration is managing the interfaces among the
various providers. The legal nature of the contractual relationship
makes it imperative that the project team be acutely aware of the
legal implications of actions taken when administering the contract.

Contract administration includes application of the

appropriate project management processes to the contractual
relationship(s) and integration of the outputs from these processes
into the overall management of the project. This integration and
 94

coordination will often occur at multiple levels when there are

multiple sellers and multiple products involved. The project
management processes which must be applied include:
• Project plan execution, authorize the contractor’s work at the
appropriate time.
• Performance reporting, is, to monitor contractor cost, schedule,
and technical performance.
• Quality control, is to inspect and verify the adequacy of the
contractor’s product.
• Change control, is , to ensure that changes are properly approved
and that all those with a need to know are aware of such
changes.

5.6.1 Inputs to Contract Administration:

1. Contract. Contracts are described in previous Section

2. Work results. The seller’s work results—which deliverables

have been completed and which have not, to what extent are
quality standards being met, what costs have been incurred or
committed, etc.—are collected as part of project plan execution

3. Change requests. Change requests may include modifications

to the terms of the contract or to the description of the product or
service to be provided. If the seller’s work is unsatisfactory, a
decision to terminate the contract would also be handled as a
change request. Contested changes, those where the seller and
the project management team cannot agree on compensation for
the change, are variously called claims, disputes, or appeals.

4. Seller invoices. The seller must submit invoices from time to

time to request payment for work performed. Invoicing
requirements, including necessary supporting documentation, are
usually defined in the contract.

5.6.2 Suggestions for Change Control in Contracts:

 Changes to any part of the project need to be reviewed,
approved, and documented by the same people in the same
way that the original part of the plan was approved.
 Evaluation of any change should include an impact analysis.
How will the change affect the scope, time, cost, and quality
of the goods or services being provided?
 Changes must be documented in writing. Project team
members should also document all important meetings and
telephone phone calls.
 95

Project managers and teams should stay closely involved to

make sure the new system will meet business needs and
work in an operational environment.
 Have backup plans.
 Use tools and techniques, such as a contract change
control system, buyer conducted performance reviews,
inspections and audits, and so on.

Contract administration also has a financial management

component. Payment terms should be defined within the contract
and should involve a specific linkage between progress made and
compensation paid.

5.6.3 Tools and Techniques for Contract Administration”

1. Contract change control system: A contract change control

system defines the process by which the contract may be modified.
It includes the paperwork, tracking systems, dispute resolution
procedures, and approval levels necessary for authorizing changes.
The contract change control system should be integrated with the
overall change control system .

2. Performance reporting: Performance reporting provides

management with information about how effectively the seller is
achieving the contractual objectives. Contract performance
reporting should be integrated with the overall project performance
reporting.

3. Payment system: Payments to the seller are usually handled by

the accounts payable system of the performing organization. On
larger projects with many or complex procurement requirements,
the project may develop its own system. In either case, the system
must include appropriate reviews and approvals by the project
management team.

5.6.4 Outputs from Contract Administration:

1. Correspondence: Contract terms and conditions often require

written documentation of certain aspects of buyer/seller
communications, such as warnings of unsatisfactory performance
and contract changes or clarifications.

2. Contract changes: Changes (approved and unapproved) are

fed back through the appropriate project planning and project
procurement processes, and the project plan or other relevant
documentation is updated as appropriate.
 96

3. Payment requests: This assumes that the project is using an

external payment system. If the project has its own internal system,
the output here would simply be “payments.”

5.7 CONTRACT CLOSE-OUT

Contract close-out is similar to administrative closure in that

it involves both product verification (Was all work completed
correctly and satisfactorily?) and administrative close-out (updating
of records to reflect final results and archiving of such information
for future use). The contract terms and conditions may prescribe
specific procedures for contract close-out. Early termination of a
contract is a special case of contract close-out.

5.7.1 Inputs to Contract Close-out:

Contract documentation: Contract documentation includes, but is

not limited to, the contract itself along with all supporting schedules,
requested and approved contract changes, any seller-developed
technical documentation, seller performance reports, financial
documents such as invoices and payment records, and the results
of any contract-related inspections.

5.7.2 Tools and Techniques for Contract Close-out:

Procurement audits: A procurement audit is a structured review of

the procurement process from procurement planning through
contract administration. The objective of a procurement audit is to
identify successes and failures that warrant transfer to other
procurement items on this project or to other projects within the
performing organization.

5.7.3 Outputs from Contract Close-out:

1 Contract file: A complete set of indexed records should be

prepared for inclusion with the final project records.

2 Formal acceptance and closure: The person or organization

responsible for contract administration should provide the seller
with formal written notice that the contract has been completed.
Requirements for formal acceptance and closure are usually
defined in the contract.

5.8 USING SOFTWARE TO ASSIST IN PROJECT

PROCUREMENT MANAGEMENT

Word processing software helps write proposals and

contracts, spreadsheets help evaluate suppliers, databases help
 97

track suppliers, and presentation software helps present

procurement-related information. E-procurement software does
many procurement functions electronically. Organizations also use
other Internet tools to find information on suppliers or auction goods
and services.
Established companies such as Oracle ,SAS, and Baan
have developed new software products to assist in procurement
management .As with information or software tool, organization
must focus on using the information and tools to meet the project
and organizational needs. Organizations should often develop
partnerships and strategic alliances with other organizations to take
advantage of potential cost savings.

5.9 OUT SOURCING

Outsourcing software development and other information

technology, or I.T. services continues to grow in popularity. There
are several important reasons for this. Many companies that have
not traditionally considered outsourcing may be surprised to learn
of the benefits that it could bring them. Even organizations with
large software teams may be candidates for outsourcing some of
their projects.

5.9.1 Benefits of outsourcing

 To allow the client organization to focus on its core business
 To access skills and technologies
 To reduce both fixed and recurrent costs
 To provide flexibility
 To increase accountability

Information technology is rapidly becoming more complex

and is constantly changing. At the same time, many companies are
finding that they increasingly need to focus their attention on the
areas of their strength due to rapidly increasing market competition.
For many of these companies, outsourcing I.T., at least projects
that are outside their area of expertise, can greatly strengthen their
competitive advantage. It also brings new energy to the
organization to have projects that were causing ongoing frustration,
cost, and risk to now be in the hands of another organization with
the specialized skills and experience needed.

Organizations that only have budget to hire a few individuals

often find that by outsourcing their projects, they are still able to
obtain access to a wide range of high level skills. Outsourced
development companies can apply the best skill for each phase of
a project. This flexibility and the availability of a larger talent pool
provides optimum results at the lowest cost.
 98

Selecting the right outsourcing partner is key to realizing

these benefits. Selecting an organization of an appropriate size is
important. An organization that is too large for your project brings
unnecessary costs and overhead. Selecting an organization with
the appropriate level of skills is also important. For projects that
provide significant business value and which you expect to be used
long term, it is important to select an organization whose people
have true enterprise level experience. The organization's vision,
high-level design skills, and ability to understand and support your
business goals are also very important. This is often the greatest
challenge with outsourcing overseas. It takes more than technical
skills for project success. The ideal outsource organization will
provide local individuals with these skills as well as overseas teams
that they have established relationships with.

This can provide small outsourced projects with the

advantage of international cost savings combined with the ease of
management and all the other potential advantages that
outsourcing has to offer.

Outsourcing can provide tremendous benefit to

organizations. It can reduce complexity and cost while increasing
project success. Selecting an organization with the necessary level
of skills and experience locally and who have their own established
international team provides an ideal formula for success. Together,
this provides your organization with the maximum efficiency and
effectiveness.

5.10 SUMMARY

Project procurement management involves acquiring goods

and services for a project from outside the performing organization.
Procurement, purchasing or outsourcing is acquiring goods or
services from outside source. Organizations outsource to reduce
costs, focus on their core business access skills and technologies,
provide flexibility and increase accountability. In this chapter we
could discuss the various steps involved in the procurement
management process needed for a project.

Processes include:
 Planning purchases and acquisitions
 Planning contracting
 Requesting seller responses
 Selecting sellers
 Administering contracts
 Closing contracts
 99

Sample questions
1. What is involved in the process of requesting seller
responses?. How do organizations decide whom to send
RFPs or RFQs?.(ANS: See section 5.3)

2. Explain the make or buy decision process and describe how

to perform the financial calculations involved in the lease or
buy example.(ANS: See section 5.1.2)

Suggested Readings.

1. Flemming, Quentin: Project procurement management ,

contracting, subcontracting ,teaming.
2. Kathy Schwalbe : Information Technology project management
3. Jack T.Marchewka: Information Technology project management
4. www. Informationweek.com
5. www.cio.com



















 100

6
CHANGE MANAGEMENT
Unit Structure:

6.0 Objectives
6.1 Introduction
6.2 The Nature of Change
6.2.1 The ADKAR Model
6.2.2 Change is a process
6.2.3 Change can be emotional
6.3 Change Management Plan
6.3.1 Develop a Strategy for Change
6.3.2Implement Change Management Plan and Track
progress
6.4 Dealing with resistance and Conflict
6.4.1 Polarity Management
6.5 Summary

6.0 OBJECTIVES

After reading this chapter, you will be able to

 Describe the ADKAR model for change management

allowing change management teams to focus their activities
on specific business results.
 Describe creating change within an organization takes hard
work and structure around what must actually take place to
make the change happen.
 Implement control change, through change approvals and
reviews
 Define the standardized methods and procedures are used
for efficient and prompt handling of all changes to controlled
IT infrastructure.
 To develop a change management plan. The plan focus on
assessing organization’s willingness and ability to change,
 101

developing a change strategy and evaluating whether the

change was successful or not.
 Discuss the nature of resistance and conflict and apply
techniques for dealing with resistance and conflict.

6.1 INTRODUCTION

``TO IMPROVE is to change, to be perfect is to change often"-

Winston Churchill

Nothing can better emphasize the need for change. Every

organization needs to change with time; failing which, it stands the
risk of being pushed into oblivion and being labeled as obsolete by
the more enterprising competitors in the market.

Change management enables planning, controlling and

coordinating all changes to an IT environment using standardized
methods and procedures. Maximize process efficiency. Minimize
change risk. Information Technology projects are planned
organizational change. An IT project has an impact on the
organization and organization has an impact on the IT projects.

The change you must, at the needed intervals. Change

could be effected in the overall policy and procedure, in the
infrastructure, in the structuring of staff, etc To implement
successful change, as a manager, you need an overall leadership
force that is greater than the combined force of resistance. By
understanding the most common ways that people respond to
change and learning how to convince the ones who are resistant to
change, you can overcome these types of problems in the
organization. (ASPM O’reilly)

According to Leslie Jaye Goff, the change management is

about helping people deal with their emotions. IT professionals
should be willing to put themselves in their user’s shoes in order to
understand how change will affect them.

The central theme of this chapter has been the concept of

measurable organization value. The project’s MOV provides a
means for determining which project should be funded and drives
many of the decisions.

6.2 THE NATURE OF CHANGE

This section focus on the ADKAR result-oriented model of

change management, impact of change that allows change
management teams to focus their activities on specific business
 102

results. To understand impact of change, change is a process and

the emotional behavior of change.
6.2.1 The ADKAR model – a model for change management:

The ADKAR change model was first published by Prosci in

1998, an independent research company specializing in the areas
of change management, business process reengineering, they
developed the ADKAR model. The model was initially used as a
tool for determining if change management activities like
communications and training were having the desired results during
organizational change.

Change management, a critical component of business, can

be achieved successfully using the ADKAR procedure. Change
often brings high levels of stress and agitation to people. It is used
as a resistance management tool, an assessment device and to
help change management teams organize their work. This model, if
applied completely, should result in a successful transition from
former procedures to new procedures without fail or regardless of
the complexity of the change.

The five key goals as shown in figure 7.1 form the basis of
the ADKAR model.

Awareness - making employees at every level understand why

change is necessary. They must understand that change does not
come from the desire to do things differently but in order to improve
on business activities and stay ahead of your competition, and/or
increase the bottom line, is not only wise, but also necessary for
success.
E.g., Customer input, Market changes etc.,

Desire: After making employees aware about the change, the next
step will be making them have the desire to support and actively
participate in the forthcoming changes.
E.g., fear of job loss, incentive or compensation, career
advancement.

Knowledge: Management must provide the training and education

to its staff of the methods of changing to the new procedures, or
organization. High levels of awareness and desire will prove
useless if they lack the necessary knowledge of how to change to
accomplish the goals.
E.g., training and education, examples and role models.

Ability: Along with the knowledge of how to affect successful

change, everyone involved needs to be given the specific training
and information to achieve success in implementing the details of
the changes to be made.
 103

E.g., Practice applying new skills, mentoring and so on.

Reinforcement: to retain the change once it has been made,

reinforcing the new “habits” of the staff typically improve the
success of the changes made.
E.g., Personal recognition, celebrations.

An organization's culture, history, values and capacity for

change are potential obstacles for change management teams.
Consultants and change management teams often address these
potential barriers with assessments. This relatively simple, logical
method of implementing change management has proven to work
well. It is not surprising or mysterious. This model, if applied
completely, should result in a successful transition from former
procedures to new procedures without fail or regardless of the
complexity of the change.

Figure 6.1

6.2.2 Change is a process:

Kurt Lewin emigrated from Germany to America during the

1930's. Lewin is recognized as the "founder of social psychology"
which immediately points to his interest in the human aspect of
change. Lewin's change management model is linked to force field
analysis. Force field analysis is used extensively for purposes of
organizational and human resource development, to help indicate
when driving and restraining forces are not in balance, so that
change can occur.
 104

Lewin proposed a three stage basic theory of change

includes Unfreeze, Change, Freeze (or Refreeze) as shown in
diagram. The present state represents equilibrium, to change from
the current state; there must be driving forces both to initiate and to
motivate the change.

Figure 6.2 depicts a transition from present state to the

desired state, it is also referred as neutral zone. Problems arise
when managers do not understand, expect the neutral zone.

Stage 1 – becoming motivated to change (unfreezing)

This phase of change is built on the theory that human

behavior is established by past observational learning and cultural
influences that human behavior is established by past observational
learning and cultural influences. Change requires adding new
forces for change or removal of some of the existing factors that are
at play in perpetuating the behavior.

Stage 2 – change what needs to be changed (unfrozen and moving

to a new state)

Once there is sufficient dissatisfaction with the current

conditions and a real desire to make some change exists, it is
necessary to identify exactly what needs to be changed. A concise
view of the new state is required to clearly identify the gap between
the present state and that being proposed. Activities that aid in
making the change include imitation of role models and looking for
personalized solutions through trial-and-error learning.

Stage 3 – making the change permanent (refreezing)

Refreezing is the final stage where new behavior becomes

habitual, which includes developing a new self-concept & identity
and establishing new interpersonal relationships.

Figure 6.2
 105

6.2.3 Change can be Emotional:

Change can also bring out emotional responses. An

individual may have an emotional response to a change when the
change is perceived as a loss a well-established equilibrium. In the
book On Death and Dying author Elizabeth Kubler-Ross provides
depicts the emotions.

The model has five stages, if people are not allowed to suffer
and go through the first four stages, then going to fifth stage is
extremely difficult. The human being we have a mechanism we do
use grief counselors to varying extent in our day to day life. If we as
change agents know this we can make sure that people we do
experience some of these stage have information readily available
to enable to progress. The Kubler-Ross model is a useful for
understanding people's emotional reaction to personal trauma and
change, irrespective of cause. The six stages include:

 Immobilization: The initial reaction to the announcement of the

change is shock. The change is so alien to the participant’s
frame of reference that he or she is often unable to relate what
is happening, resulting in temporary confusion or complete
disorientation.
 Denial – It is a conscious or unconscious refusal to accept
facts, information, reality, etc., relating to the situation
concerned. For e.g., when a person is informed that she is
being fired by organization, the initial response may be, Are you
serious?
 Anger – The anger is a more active emotional response.
People dealing with emotional upset can be angry with
themselves, and/or with others, especially those close to them.
There is a difference between feeling anger and acting out in
anger.
Bargaining – In this stage the person may be cooperative and
may try to make deals to avoid change. People facing less
serious trauma can bargain or seek to negotiate a compromise.
For e.g., the person who is fired from the organization may
promise the management that she will take a cut in pay to avoid
being let go.
 Depression – It is also referred to as preparatory grieving. This
stage occurs when there is an overwhelming sense of the loss
of the status escape. It's a sort of acceptance with emotional
attachment and also it shows that the person has at least begun
to accept the reality.
 106

Acceptance – This stage varies according to the person's

situation, in this stage a person comes to grips with the change.
Acceptance is an important part of ending the status escape
and getting on with a new state.

6.3 THE CHANGE MANAGEMENT PLAN

Change Management doesn't need to be "just another thing

on your project management checklist." Instead, use the change
management methodology to guide how you deal with change in
your projects. Often, just having a set of rules by which you and all
involved team members and stakeholders can follow makes it
easier for you to deal with the change that will inevitably crop up in
your projects. This way, you can focus more energy on planning
and monitoring and less energy on fighting fires.

Once the change management plan has been developed it

should be integrated with the project plan and can be included at
any point after start up. Figure 7.3 provides a framework for
developing a change management plan.

Figure 6.3
 107

Ready, Willing, and Able to Change:

This is the first step for developing a change management

plan that is to assess the organization’s readiness, willingness and
ability to change. This assessment defines several roles involved in
a change management – the sponsor, change agents, change
advocate and targets.

Sponsor A sponsor is the individual (or group) with the

power to determine that change will occur. This person or group of
project sponsor, an initiating sponsor has the authority to make
resources available and support the project, then this person may
handoff the project to a sustaining sponsor. A major portion of the
organization’s ability and willingness to support the change rests
with the sponsor’s commitment to the project. If the project fails
because the organization cannot adapt to the change, the project’s
envisioned value to the organization is lost and the sponsor’s
credibility is reduced.

Change Agents An agent is the individual (or group)

responsible for seeing that a previously determined change occurs
to achieve project’s goals. They design and implement or help to
implement the change. Change agents report to the sponsor and
must diagnose problems, plan to deal with these issues. The ability
to sustain the change with the IT projects rests with the change
agents.

Change Advocate An advocate is the individual (or group)

who want to achieve a change but lacks the power to sanction it
and require support from the appropriate sponsor who can approve
the change. Any individual within an organization who has a good
idea and the ability to communicate it can be a change advocate.

Targets A target is the individual or group that must change.

They may be the users of the new system or those will be directly
involved with final product of the project. The dynamics associated
with the targets of change become most critical for supporting and
carrying out the change effort.

Leavitt suggests that the effectiveness of any change

program can only be achieved through a balance of four
organizational subsystems: technology, structure, tasks and
people. The model shown in Figure 7.4 illustrates how all four of
these items are interrelated.
 108

Task

Technology People

Structure

Leavitt's Model of Change: Task,

Technology, Structure, and People

Figure 7.4

Structure - levels of hierarchy, spans of authority, centralization.

Technology - complexity, degree of employee usage, operator
control & responsibility.
People - values, beliefs, attitudes, motives, drives, competencies.
Task - job design, repetitiveness, physical & cognitive demands,
autonomy & discretion.

Change at any one point will impact some or all of the

others. Thus, a changed task will necessarily affect the people
involved in it, the structure in which they work, and the technology
that they use. Failure to manage these interdependencies at critical
times of change can create problems.

As a result of the planned change, people will go through a

variety of emotions. So it is important that a boundary be defined in
a way that allows the change to happen as planned, but also allows
individual “to take something with them” by giving something
familiar to hold on to so as to ease the transition. This allows the
past to be remembered with reverence and can also mark the end
and the new beginning.
 109

People become confused and disoriented when the rules for

success change are no longer clearly defined. Lets say that you
have been working at a company for several years. Over that time,
you have become part of that culture and you know that, in our
company promotions is based on seniority and the layoff’s will
begin with the employees with the least seniority. What if the
company you work for has been acquired by some other
organization? The acquiring company has decided to make a few
changes and start downsizing the workforce in your company and
only top performance will be invited to stay. The rules for success
have changed.

6.3.1 Develop a Strategy for Change:

The developing a strategy for change is the step after the

change is assessed. Davidson provides four approaches to change
management.

Rational-Empirical Approach

The Rational-Empirical strategy suggests that most people

are rational, so they will accept change that will benefit the overall
organization. People are rational beings and will follow their self-
interest once it is revealed to them.

It is important that the individuals affected by the change be

provided with consistent and timely information. Mixed messages
can lead to confusion and suspicion. When people are not given
enough information, they tend to seek information from other
sources; these messages might be rely on suggestions,
misinformation and opinions. Successful change is based on the
communication of information and the proffering of incentives.

The change management plan based on this strategy should

provide each individual with the purpose, a picture and a part to
play. Often individuals within organization have a narrow view of
their job and its relationship to the rest of the organization. It may
be useful to provide people with a chance to experience the
problem or opportunity first-hand. A picture provides a vision in the
individual’s mind as to how the organization will look or operate in
the future. If done effectively, this procedure can help the individual
buy into the proposed change. A part can be effective in helping the
individual become involved in the proposed change. It is important
for the individual to understand and visualize the part she will play
once the change is instituted.

Normative-Reeducation Approach:
 110

The normative-Reeducation strategy suggests that people

are social beings and will adhere to cultural norms and values.
Successful change is based on redefining and reinterpreting
existing norms and values, and developing commitments to new
ones.

Change strategy here focuses squarely on culture – what

people believe about their world, their work and themselves and the
ways in which people behave so as to be consistent with these
beliefs. Ordinarily, culture doesn’t change quickly and certainly not
overnight. This, then, is not the strategy of choice in a turnaround
situation on short deadlines. Moreover, an organization’s culture is
as much in the grip of the informal organization as it is the formal
organization. For this reason, this strategy works only when the
relationships between the formal and informal organizations are at
least cordial and hopefully harmonious.

This approach can be very difficult and time-consuming

because the change agents and sponsor must study the existing
values and beliefs of a group. It requires unfreezing the current
norms so that change can take place so that a new set of norms
can be refrozen to solidify the acceptance of the new way of doing
things by the group. Some key principles include:

Capacity for change is directly related to a person’s

participation in a group.
 Effective change requires changing something not only about
the individual’s values and belief’s, but also the values and
beliefs that make up the existing group’s culture.
Bias and prejudice towards guarding one’s closely held belief
and values diminishes one’s ability to think rationally.

Power-Coercive Approach:

The Power-Coercive strategy attempts to gain compliance

from the change targets through the exercise of power, authority,
rewards or threat for non-conformance.

Two major factors influencing the choice of this strategy are

time and the seriousness of the threat faced. If the organization sits
astride the fabled “burning platform,” the threat is grave and the
time for action is limited. The metaphor of a burning platform is
useful but only if all concerned can in fact see that the platform is
on fire. This is rarely the case in an organization. Few companies
are filled with people who understand the way the business works
and fewer people still appreciate the threats it faces or the
opportunities it encounters.
 111

As Davidson observes, People’s dependency on an

organization dictates how effective the power-coercive approach
and use of sanctions can be. If the people are highly dependent on
the organization; live paycheck to paycheck; have few job
alternatives; are not financially, mentally prepared to walk, you are
on relatively safe ground using power-coercive approach judiciously
(90-91)

The objective is to change the behavior of the targets so that

their new behavior supports the change effort. Davidson points out
that sanctions should be imposed on an individual level and should
focus on what an individual values and what they dread losing – a
bonus, a paycheck or a position within the organization. A change
agent or sponsor can lose credibility, if they issue a warning or
sanction that they do not fully intend to carry out.

Environmental-Adaptive Approach:

People oppose loss and disruption but they adapt readily to

new circumstances. Change is based on building a new
organization and gradually transferring people from the old one to
the new one.

Following this approach, the change agent attempts to make

the change permanently by abolishing the old ways and instituting
the new structure as soon as possible. A much less drastic
example would be upgrading everyone’s word processing software
over the weekend so that when everyone returned to work on
Monday, they would have no choice but using the new software
package.

Time frames are not a factor. This strategy can work under
short time frames or longer ones. However, under short time
frames, a key issue will be that of managing what could be
explosive growth in the new organization and, if it is not adequately
seeded with new folks, the rapid influx of people from the old
culture can infuse the new organization with the old culture.

Although this approach may be effective in certain situations,

it is important that the targets of change assimilate the change as
quickly as possible in order to adapt to the change as soon as
possible. Some ways may include helping the targets of change
see the benefits and showing them how the new way is similar to
their old one.

A single strategy however, may not be effective in every

situation. A more useful approach may be combining the different
strategies, depending on the impact of the change and the
organization.
 112

6.3.2 Implement the Change Management Plan and Track

Progress:

Once the strategies for the change management plan have

been defined, the next step entails implementing the plan and
tracking its progress. Although tracking progress should be
integrated into the overall project plan using the tools, such as
Gantt chart, PERT chart and so on.

The effective line of communication is the critical issue for

ensuring that the change takes place as planned. The project team
and project sponsor create and open channels of communication. It
is important especially when delivering certain type of news. For
example a richer media, such as face-to-face communication, is
generally preferable when delivering important news.

The open channels of communication should be both ways.

The project team and sponsor must communicate effectively with
the various groups within the organization affected by the change,
and in turn these groups must be able to communicate effectively
with the project team and sponsor. Web sites, e-mails, memos and
newsletters can be mediums for effective communication.

Evaluate Experience and Develop Lessons Learned:

As the project team carries out the change management

plan, they will learn from their experiences. These experiences
should be documented and made available to other team members
and other projects. At the end of the project, the overall success of
the change management plan is evaluated.

6.4 DEALING WITH RESISTANCE AND CONFLICT

Resistance and conflict are a natural part of change. In this

section, we will look at the nature of resistance and conflict and
several approaches for dealing with these.

Resistance:

With change, comes resistance. Regardless of how clear

and concise your change management plan is, you will find varying
levels of resistance and people questioning the motive for change.

Resistance to change comes for many valid reasons. For

example, someone may resist for genuine interest – someone may
 113

resist an IS because the response time is too slow or because it

does not provide the feature that were specified as part of the
requirements. Resistance like this is healthy and should be
encouraged early in the change initiative. On the other hand,
resistance due to cultural or behavioral reasons is harder to
rationalize.

Kotter and Schlesinger set out the following six change

approaches to deal with resistance to change:

 Education and Communication - Where there is a lack of

information or inaccurate information and analysis. One of
the best ways to overcome resistance to change is to
educate people about the change effort beforehand.
 Participation and Involvement - Where the initiators do not
have all the information they need to design the change and
where others have considerable power to resist. When
employees are involved in the change effort they are more
likely to buy into change rather than resist it.
 Facilitation and Support - Where people are resisting change
due to adjustment problems. Managers can head-off
potential resistance by being supportive of employees during
difficult times.
 Negotiation and Agreement - Where someone or some
group may lose out in a change and where that individual
or group has considerable power to resist. Managers can
combat resistance by offering incentives to employees not to
resist change. This can be done by allowing change
resistors can be offered incentives to leave the company
through early buyouts or retirements in order to avoid having
to experience the change effort.
 Manipulation and Co-option - Where other tactics will not
work or are too expensive. Kotter and Schlesinger suggest
that an effective manipulation technique is to co-opt with
resisters.
 Explicit and Implicit Coercion - Where speed is essential and
to be used only as last resort. Managers can explicitly or
implicitly force employees into accepting change by making
clear that resisting to change can lead to losing jobs, firing,
transferring or not promoting employees.

Conflict:

Closely associated with resistance is the concept of conflict.

Conflict arise when people perceive that their interests and values
are challenged or not being met. It is important to identify potential
conflicts as early as possible so that the conflict can be addressed.
 114

There are 3 different views of conflict, these are

(i) Traditional view – According to this conflict leads to poor

performance, aggression and devastation if left escalate.
Therefore, it is important to manage conflict by
suppressing it before it occurs as soon as possible.
(ii) Contemporary view – This view suggests that conflict is
inevitable and natural. Depending on how conflict is
handled, conflict can be either positive or negative. The
positive conflict should be encouraged and negative
conflict in check.
(iii) Interactionist View – Interactionist view holds suggests
that conflict is an important and necessary ingredient for
performance. The project manager should occasionally
stir the pot in order to encourage conflict to an
appropriate level so that people engage in positive
conflict.

For the project manager and project team, the seeds of

resistance can easily lead to negative conflicts. Blake and Mouton
(1964) and Verma (1998) describe five approaches for dealing with
conflict.

 Avoidance – Avoiding conflict focuses on retreating,

withdrawing conflict. It may be appropriate when you
can’t win, the stakes are low, or gaining time is
important. Avoidance may not be useful when the
immediate, successful resolution of an issue is
required.
 Accommodation – This approach is useful when trying
to reach an overall goal, when the goal is important
than the personal interests of the parties involved.
 Forcing – This approach is useful when a person uses
his or her dominant authority to resolve the conflict.
Forcing results in a win-lose situation in which one
gains at the other’s expense.
 Compromise – It includes both forcing and
accommodation approaches, compromising is
bargaining. In this case, no party actually wins and
none actually loses.
 Collaboration – This approach requires confronting
and attempting to solve the problem by incorporating
different ideas, viewpoints and perspectives.
 115

Collaboration is the best approach when the risks and

benefits are high.

Each conflict situation is unique and the choice of an approach to

resolve conflict depends on:

• Type of conflict and its relative importance to the project.

• Time pressure to resolve the conflict.
• Position of power or authority of the parties involved.
• Whether the emphasis is on maintaining the goals or
objectives of the project or maintaining relationships.

6.4.1 Polarity Management:

The project manager or project team is faced with a conflict

situation that appears to have no solution. When two sides (i.e.
advocates of change and those resisting change) end up in a
polarity where each side can only see the upsides or advantages of
their pole and the downsides or disadvantages of the other. For
many, this is difficult dilemma that can create even more resistance
and conflict.

According to Barry Johnson, the problem is that we often

frame a problem as something that can be solved by choosing one
side over another. Crusading is the activity people engage in when
they want to make things better by moving away from the downside
of one pole to the upside of the opposite pole. Tradition-Bearing is
the activity people engage in to defend the upside of the status quo
and to point out the necessity of avoiding the downside of the
opposite point of view. Crusaders are those who want to change
the status quo and are supporters of change. They contribute by
identifying the downsides of the current pole and provide the
energy to move away from the current pole. Tradition Bearers - are
at the opposite end of the pole and wish to preserve the best of the
past and present and help identify things that should be preserved.
Using a tool Polarity mapping, we can see the upsides and
downsides that each side is advocating. Figure 6.5 provides an
example of a polarity map for implementing a new word processing
application.

In this figure the upper left quadrant is the Traditional

Brearers’ view of the upsides for keeping the current word
processing software package are listed, while the Crusaders’ view
of the upsides for upgrading to a new word processing package are
listed in the upper right quadrant.
 116

Figure 6.5

The conflicts occur in the lower two quadrants, for example

people who advocates upgrading to a new word processing
package may focus on the upsides of the upper right quadrant (C+).
Similarly those in favor of maintaining the status quo will focus on
the quadrants TB+ and TB-. Often the upside of one quadrant (i.e.,
familiarity) becomes a downside in the opposite quadrant (i.e., will
take time to learn). Subsequently resistance and conflict escalate
unless both sides see the entire picture.

Johnson suggests that before using polarity management, both

sides should:
 Clarify what you value and what you do not want to lose.
 Let the other side know that you are aware of the downsides
of the pole.
 Assure the other side that you want to maintain the upsides
of their pole.

Polarity mapping helps people “get away” from seeing their

current initiative as being the only “solution to the problem” and not
a case of choosing one idea over another.

The key to polarity management is recognizing that both

polarities must be managed simultaneously. In the previous
example of word processing, if upgrading to a new word processing
package both groups may try to come up with training plan flexible
enough so that both groups get what they want.
 117

6.5 SUMMARY

In this chapter, we saw the critical component of business,

can be achieved successfully using the ADKAR procedure. We
looked at change as a process. Kurt Lewin introduced the concept
of Force Field Analysis, in which we try to understand the driving
and resisting forces that push and repel the change. Lewis model of
change helps us to understand that we must unfreeze the current
state until the desired new state is reached.

In this chapter we understood how to develop effects change

management plan. The change management should focus on
adopting a strategy to support the change. The plan should center
on implementing the plan and tracking its progress. The polarity
management was introduced as a tool that provides a collaborative
approach for dealing with conflict and resistance.

Sample Questions:

1. Define change management. Describe the stages of Lewin’s

model for change.
For solution Refer 7.2.2

2. Describe any two approaches to develop a strategy for change.

For Solution Refer 7.3.1

3. In your own words, describe polarity management.

Refer 7.4.1

References:
Information Technology Project Management – Providing
measurable organizational value by Jack T. Marchewka.
http://home.att.net/~OPSINC/four_strategies.pdf
http://www.valuebasedmanagement.net/methods_kotter_change_a
pproaches.html
http://www.pcrest.com/centers/hinds/FI_reading.htm
http://www.businessballs.com/elisabeth_kubler_ross_five_stages_o
f_grief.htm
http://www.pcrest.com/centers/hinds/FI_reading.htm
Schein, E. H. (1995). Kurt Lewin’s change theory in the field and in
the classroom: Notes toward a model of managed learning [WWW
document] (74 paragraphs). URL http://www.sol-
ne.org/res/wp/10006.html [2002, March 20].
http://www.a2zpsychology.com/articles/kurt_lewin's_change_theory
.htm [2004, September 9].

 118

7
PROJECT IMPLEMENTATION
Unit Structure:
7.0 Objectives
7.1 Introduction
7.2 Project Implementation
7.2.1 Direct Cutover
7.2.2 Parallel
7.2.3 Pilot
7.2.4 Phased
7.3 Administrative Closure
7.3.1 Project Sponsor Acceptance
7.3.2 The Final Project Report
7.3.3 The Final Meeting and Presentation
7.3.4 Closing the Project
7.4 Project Evaluation
7.5 Chapter Summary

7.0 OBJECTIVES

After reading this chapter, you will be able to:

 Describe the approaches to information system

implementation and installation. (i) direct cutover (ii) parallel
(iii) pilot (iv) phased
 Describe the process associated with project closure to
ensure that the project is closed in an orderly manner.
 Identify the different types of project evaluations.

7.1 INTRODUCTION

In this last chapter we will focus on implementation of a

project, closure and the project review or evaluation. The Project
implementation focuses on installing or delivering the project’s
major deliverables in the organization. Implementation is the stage
where all the planned activities are put into action. Examples for
 119

information system project implementation would be the installation

of new databases and application programs, and the adoption of
new manual procedures etc.,

In general, implementing the product of an IT project can

follow one of the four approaches. These approaches are direct
cutover, parallel, phased or pilot. Each approach has unique
advantages and disadvantages that make a particular approach
appropriate for a given situation.

As you know a project has a definite beginning and a definite

end. Once the project is implemented, the project manager and his
team must prepare for closing the project. A project is properly
closed for two reasons. Firstly, there is a tendency for projects to
drift on and become, or develop into, other projects. Secondly, it is
important to ensure that the work of the project team is
acknowledged and that the lessons to be learned from the project
are formally investigated and recorded for use on the next project.

Once the project is closed, the project manager should

evaluate each project team member individually in order to provide
feedback to the individual about his performance on the project. In
addition, the project should be reviewed by an impartial outside
party. An audit or outside review can provide valuable insight on
how well the project was managed and on how well the project
members functioned as a team.

The project’s overall goal was defined as the MOV, or

Measurable Organizational Value. It is clearly defined and agreed
upon in the early stages of the project that whether the project is
successful, as defined by its MOV.

7.2 PROJECT IMPLEMENTATION

After developing the project, the IS is transferred

successfully from the development and test environment to the
operational environment of the customer. Choosing an
inappropriate implementation approach can negatively impact the
project’s remaining schedule and budget. In general, the project
team can take one of three approaches for implementing the IS.
These approaches are (i) direct cutover (ii) parallel (iii) pilot and (iv)
phased

7.2.1 Direct Cutover:

The direct cutover approach, as illustrated in figure 7.1

produces the changeover from old system to the new system
instantly.This approach can be effective when quick delivery of the
 120

new system is critical and this approach may also be appropriate

when the system’s failure will not have a major impact on the
organization i.e., the system is not mission critical.

Figure 7.1

Companies often choose the direct cutover approach for

implementing commercial software package. Although there are
some advantages to using the approach, there are also a number
of risks involved that generally make this the least favored
approach. Using this approach you may think as walking a tightrope
without a safety net. You may get from one end of the tightrope to
other quickly, but not without a great deal of risk. Subsequently,
there is no going back to the old system to the new system. As a
result, the organization could experience major delays, lost
revenues and missed deadlines. The pressure of assuring that
everything is right can create a great deal of stress for the project
team.

7.2.2 Parallel:

Parallel approach as shown in figure 7.2 is the method in

which both the new system and the old system will operate at the
same time, for a specified period of time, in order to check the new
system for complexities.
 121

Figure 7.2

Data is input in both system and the results are verified. This
approach is impractical if the systems are dissimilar or does not
support each other. The cost using this approach is relatively high,
because both systems are operating requiring more man power in
terms of management. Using this approach provides confidence
that the new system is functioning and performing properly before
relying on it entirely. It is also impractical to use this approach as
the new system and old system technically incompatible.

7.2.3 Pilot:

It is the combination of both direct cutover and parallel

approach. The pilot method involves implementing the new system
at a selected location like a branch office, one department in a
company, etc. – called pilot site, and the old system continues to
operate for the entire organization.

Risk and cost, associated in this method are relatively less,

because only one location runs the system and the new system is
only installed and implemented at pilot sites; reducing the risk of
failure. After the new system proves that the system is successfully
at the pilot site, it is implementing in the rest of the organization,
usually using the direct cutover method.

7.2.4 Phased:

The Phased approach allows implementing the new system

in phases or modules or stages in different parts of the organization
incrementally as shown in the figure 7.3. E.g., an organization may
 122

implement an accounting information system package by first

implementing the general ledger component, then accounts
payable etc.

Figure 7.3

This method is one of the least risky because

implementation only takes effect in part, incase an error goes
wrong with the new system, only that particular affected part is at
risk. A phased approach may also allow the project team to learn
form its experiences during the initial implementation so that the
later implementations run smoothly.

Although the phased approach may take more time than the
direct cutover approach, it may be less risky and much
manageable. After all the modules have been tested independently
it is possible to implement the new system in the organization,
which would be error free. Also, overly optimistic target dates or
problems experienced during the early phases of implementation
may create a chain reaction that pushes back the scheduled dates
of the remaining planned implantations.

7.3 ADMINISTRATIVE CLOSURE

Although all projects come to an end, a project can be

terminated for any number of reasons. Gray and Larson (2000)
define five circumstances for ending a project: normal, premature,
perpetual, failed and changed priorities.

 Normal – A project that completed as planned. The project

scope is achieved within cost, quality and schedule
objectives with some modification and variation along the
way. The project is transferred to the project sponsor and the
 123

end of the project is marked with a celebration, awards for a

good job.

 Premature – A project team may be pushed to complete a

project early even though the system may not include all of
the envisioned features or functionality.

 Perpetual – These projects never seem to end. These

projects may result from delays or a scope or MOV that was
never clearly defined. Then the project sponsor may attempt
to add on various features to the system, which results in
added time and resources that increase the project schedule
and drain the project budget. Attention to defining and
agreeing to the project’s MOV, the project scope processes,
and timely project reviews can reduce the risk of perpetual
projects.

 Failed – Sometimes projects are just unsuccessful. In

general an IT project fails if insufficient attention is paid to
the people, processes or technology.

 Changed Priority – In some cases, a project may be

terminated as a result of a change in priorities. Financial or
economic reasons may dictate that resources are no longer
available to the project. This change happens when the
original importance of the project was misrepresented.

Ideally a project is closed under normal circumstances.

Unfortunately, closing a project does not often happen. As J.
Davidson Frame (1998) points out, the project manager and team
should be prepared to deal with the following realities:

 Team members are concerned about future jobs. Often

the team members of the project team are borrowed from
different departments. Once the project is finished, they will
return to their previous jobs. Regardless as the project nears
its end, these project team members may begin to wonder
what they will do next. For some, there will be rewarding life
after the project and for some other looking for the new job.
As a result, the project team members may not focus on
what has to be done to close the project, and wrapping up
the project may be a challenge.

 Bugs still exist. Software quality testing may not find all the
defects, and certain bugs may not become known until after
the system has been implemented. Unless these defects
and bugs are promptly addressed and fixed, the project
sponsor’s satisfaction with the project team and the
information system may become an issue.
 124

 Resources are running out. Resources and the project

schedule are consumed from the project’s earliest inception.
At the end of the project, both resources and time remaining
are usually exhausted. So the project manager may find
adequate resources to deal with problems effectively are not
available.

 Documentation attains paramount importance. The IT

projects require system, training and user documentation.
Many times, however documentation is put off until the end
of the project. As a result, documentation becomes
increasingly important at the end of the project and may
require more time and resources to complete.

 Promised delivery dates may not be met. Most projects

experience schedule slippage due to poor project
management, implementation risks, and overly optimistic
estimates. Any misjudgment concerning what has to be
done, what is needed to complete the job and how long will it
take will result in a variance between the planned and actual
schedule and budget.

 The players may posses a sense of panic. The project

stakeholders may experience panic as schedule begins to
slip and the resources become exhausted. The sponsor may
worry that the IS will not be delivered on time and within the
budget. As the sense of panic increases, the chances for an
orderly closeout grow dim.

A good closeout allows the team to wrap up the project in a

neat, logical manner. From an administrative view, this procedure
allows for all loose ends to be tied up. From a psychological
perspective, it provides all of the project stakeholders with a sense
that the project was under control form the beginning through to its
end (Frame 1998)

7.3.1 Project Sponsor Acceptance:

The most important requirement for closure under normal

circumstances is obtaining the project sponsor’s acceptance of the
project. Since acceptance depends heavily on the fulfillment of the
project’s scope, the project manager becomes responsible for
demonstrating that all project deliverables have been completed
according to the specification.

Rosenau (1998) observes that there are two basic types of

project sponsors. Shortsighted sponsors and knowledgeable
sponsors. Shortsighted sponsors – view the project as a short-term
 125

buyer-seller relationship in which getting the most for their money is

the most important criteria for accepting the project.

Knowledgeable sponsors – they have an important stake in

the outcome of the project. They will be actively involved
throughout the project in a constructive manner.

Regardless of whether the sponsor is shortsighted or

knowledgeable, the project manager and team can improve the
likelihood that the project will be accepted if they
(i) Acceptance criteria clearly defined in the early stages of
project.
(ii) Completion of all project deliverables and milestones
thoroughly documented.

A clearly definition of the project deliverables is an important

concern for project scope management. Defining and verifying that
the project scope and system requirements are accurate and
complete is only one component.

Project milestones ensure that the deliverables are complete.

Documenting each deliverables and milestone throughout the
project provides confidence to the project sponsor that the project
has been completed fully.

7.3.2 The Final Project Report:

The project manager and team should develop a final report

and presentation for the project sponsor and other key stakeholders
to ensure that the project has been completed as outlined in the
business case, project charter and project plan.

The report may be circulated to key stakeholders before the

presentation in order to get feedback and to identify any open items
that need to be scheduled for completion. Once finalized, the final
project report provides a background and history of the project. The
report should include:
(i) Project summary
o Project Description
o Project MOV
o Scope, Schedule, Budget and Quality Objectives
(ii) Comparison of Planned versus Actual
o Original Scope and history of any approved changes
o Original scheduled deadline versus actual completion
date
o Original budget versus actual cost of completing the
project
o Test plans and test results
 126

(iii) Outstanding Issues

o Itemized list and expected completion
o Any ongoing support required and duration
(iv) Project Documentation List
o Systems Documentation
o User Manuals
o Training Materials
o Maintenance Documentation

7.3.3 The Final Meeting and Presentation:

If the project has been diligent in gaining the confidence of the

project sponsor, the final meeting and presentation should be
simple, straightforward. Buttrick (2000) suggests that the final
meeting is useful for:

 Communicating that the project is over. By inviting key

stakeholders to the meeting, the project manager is formally
announcing that the project is over.

 Transferring the information system from the project team to

the organization. Although the system may have been
implemented and is being used by the organization, the final
meeting provides a formal exchange of the project’s product from
the project team to the organization.

 Acknowledging contribution. The meeting provides a forum for

the project manager to acknowledge the hard work and
contributions of the project team and other key stakeholders.

 Getting formal signoff. The meeting can provide a ceremony for

the sponsor or client to formally accept the IS by signing off on the
project.

7.3.4 Closing the Project:

After the project is accepted by the client, a number of

administrative closure processes remain. Administrative closure is
a necessity because once the project manager and team are
officially released from the current project, getting them to wrap up
the last of the details will be difficult. The requirements for
administrative closure include:
 Verifying that all deliverables and open items are complete.
 Verifying the project sponsor or customer’s formal acceptance
of the project.
 Organizing and archiving all project deliverables and
documentation.
 127

 Planning for the release of all project resources

 Planning for the evaluation and reviews of the project team
members and the project itself
 Closing of all project accounts
 Planning a celebration to mark the end of a project.

7.4 Project Evaluation:

There are many views concerning to a project success. For

the team members, it may be gaining valuable experience and for
the project manager, it may be leading a project that will be
profitable to the firm or a promotion. On the other hand the client
may view project success in terms of organizational value received
after the project is implemented.

There are four types of project evaluations to be conducted.

(i) an individual review of each team member’s performance
(ii) a postmortem review by the project manager and project team
(iii) an audit of the project by an objective and respected outside
party and
(iv) an evaluation sometime after the project is implemented to
determine whether the project achieved its envisioned MOV.

Individual Performance Review

The project manager should conduct an individual

performance review with each project team member. The project
manager should focus on the following points:

 Begin with the individual evaluation his/her

performance. Evaluating someone’s performance can be
emotional experience. Instead of beginning an evaluation
with a critique of the individual’s performance, it is usually
effective to begin by asking how that person would evaluate
her performance. This system creates a useful dialog that
provides the individual with more useful feedback.
 Avoid “why can’t you be more like//?” People are
different and should be evaluated as individuals; comparison
can have a counter effect. First, the person you praise may
not be the shining star. Second, others may become jealous
and look for ways to discredit the individual.
 Focus on specific behaviors, not the individual. When
discussing opportunities for improvement with a person, it is
important to focus on specific behavior.
 128

 Be consistent and fair. The person conducting the

evaluation should be aware of how decisions concerning one
person may affect the entire group and be aware of people
talk to one another and often compare notes.
 Reviews should provide a consensus on improving
performance. The purpose of conducting review with each
team member is to provide constructive feedback for them.
The individual and the evaluator should agree on what areas
the individual needs to improve upon and how the
organization can support this endeavor.
The meeting can serve to help prepare the individual to
move on and accept the psychological fact that the project will end
(Gray and Larson 2000).

Postmortem Review:
The postmortem review should be done before the project
team is released from the current project. Phillips says. For most
projects, the post-mortem review should be done at final
acceptance of the project, as soon as possible to the final sign-off.
The reasons for this are simple: members of the team are going to
move on to other projects; and the experience of working on the
project will be fresh in everyone's mind soon after it's done. Exactly
what goes into a post-mortem varies greatly from organization to
organization.

The value of conducting Postmortem review is to - (i) Learn

what went wrong, so you can avoid it in the future and (ii) Learn
what worked so that it can transferred to other projects. The focus
of this review should include the following:
 Review the initial project’s MOV. Was the project’s MOV
clearly defined and agreed upon? Did it change over the
course of the project? What is the probability that it will be
achieved?
 Review the project scope, schedule, budget and quality
objectives. How well was the scope defined? How close
were the project schedule and cost estimates to the actual
deadline and budget of the project? Was the quality
objective met?
 Review each of the project deliverables. How effective were
the business case, the project charter, the project plan? How
could these deliverables be improved?
 Review the various project plans and Project Management
Body of Knowledge areas. The team should review its
effectiveness in all the nine Project management body of
knowledge areas.
 129

After the investigation is completed, a report should be

drafted and that the project manager and the project team can
share this with others in the organization. The best practices should
be identified and become part of the organization’s IT project
methodology.

Project Audit:

The individual view and postmortem review provide an

important view of the internal working of the project. To provide a
more objective view of the project, an audit by an outside party may
be good for uncovering problems, issues or opportunities for
improvement. An audit means scrutiny, coordination and time is
required when the project manager’s is often already full. There are
concerns about the outcome and its effects on the team and current
work as well as careers and advancement. To overcome this
apprehension is proper planning and preparation.

As Gray and Larson (2000) suggest, the depth of the audit

depends on the organization’s size, the importance and size of the
project, the risks involved and the problems encountered. The audit
may involve the project manager and the project team, as well as
the project sponsor and other key project stakeholders. In addition,
the third party auditor should:
 Have no direct involvement or interest in project.
 Be respected and viewed as impartial and fair.
 Be willing to listen.
 Present no fear of recrimination from special interests.
 Act in the organization’s best interest.

The findings of the project audit should be documented, as

well as any lessons learned and best practices.

Evaluating Project Success – The MOV

The MOV – measurable organization value provided the

basis for taking on the project and supported many of the decision
points throughout the project life cycle. Although the different
project stakeholders and players may have different views as to
whether the project was a success, it is important to assess the
value that the project provides the organization. This review may be
conducted by several people from both the project sponsor and the
organization or area responsible for carrying out the project. This
review should focus on answering the following questions:
 Did the project achieve its MOV?
 Was the sponsor/customer satisfied?
 Was the project managed well?
 130

 Did the project manager and team act in a professional and

ethical manner?
 What was done right?
 What can be done better next time?
The evaluation of the project’s MOV may be intimidating – it
can be the moment of truth as to whether the project was really a
success. However, a successful IT project that brings measurable
value to an organization provides a foundation for organizational
success.

7.5 SUMMARY

In this chapter, you looked four approaches to

implementation. Choosing and implementing the correct
implementation approach can have a significant impact on the
project schedule and budget.

Once the IS has been implemented, the project manager

and team must plan for an orderly end to the project. Projects must
be properly closed, regardless of whether the project ends
successfully or not. Delivery or installation of the IS does not mean
that the project’s sponsor or customer will accept the project.
Therefore closure must focus on providing both proof and
confidence that the project team has delivered everything according
to the business case, project charter and project plan.

Several processes for closing a project were discussed in

this chapter. Before a project is completely terminated, several
reviews are conducted. Lessons learned should be documented
and best practices identified. The performance reviews and
postmortem review should provide preparation for the project audit.
The auditor should focus on the specific challenges the project
manager and his tem faced and review all the project deliverables.

Sample questions:

1. Describe some of the steps for administrative closure.

For solution refer 7.3

2. What is implementation? Describe the approaches to

implementing an information system.
For solution refer 7.2

3. What is the difference between a shortsighted and a

knowledgeable project sponsor? How can making this
distinction help the project manager during project closure?
For solution refer 7.3.1
 131

References:

http://www.projectauditors.com/Papers/Your_Project_Has_Been_S
elected_for_an__Audit.pdf
Information Technology Project Management – Providing
measurable organizational value by Jack T. Marchewka.
http://www.spottydog.u-net.com/guides/close/frameset.html
http://ivythesis.typepad.com/term_paper_topics/2009/10/exam-
question.html
http://facweb.cs.depaul.edu/yele/Course/IT215/Chapter%2009.ppt#
570,41,System Changeover
http://gauravgupta28.wordpress.com/
http://www.cioupdate.com/reports/article.php/2202921/Post-
Mortems-Key-to-Successful-Future-Projects.htm
http://www.cis.gsu.edu/~mkeil/cis8150/post-project%20audits.pdf



