Syllabus

Summer Semester 2023

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

a. The nature of change

 2

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 ProjectManagement by
Richard Thayer, Edward Yourdon WILEY INDIA.




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
 3

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 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:

 4

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 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
 5

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.

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.
 6

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 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)"
 7

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 preemptive 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:

• 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.
 8

• 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.

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 timemanagement tools and
techniques include Gantt charts, project network diagrams, and critical
 9

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

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
 10

Procurement Make-or-buy analyses, contracts, requests

management 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.

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:

 11

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 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.
 12

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.

• 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 charterincluding costs, tasks, deliverables, and
schedule.
 13

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.

- 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
 14

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 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 aproject
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.
 15

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?



 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 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.
 16

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 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
 17

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

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?
 18

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 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

 19

TopManagement

ProjectBoard&
otherfunctionaries

Projectmanager

Projectteam

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 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
 20

• 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

• 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
 21

• 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.

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.
 22

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.

• 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
 23

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 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.
 24

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 welldocumented
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.
 25

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.
 26

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-DoReview-
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
 27

functions, designing them, and evaluating their implementation and

testing. The users should also participate in creating, verifying, and
updating the requirements specification 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.




 28

 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

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.
 29

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 timebased 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 assesshow 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.

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).
 30

• 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.

• 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
 31

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 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.
 32

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.
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
 33

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.

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

Microsoft Projects :

Figure3.3GanttChart drawnusingMicrosoftProject.

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 must then
 34

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.

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
 35

best possible financial position. It’s the old maxim: promise lowdeliver
/ 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)
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.
 36

• 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
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
 37

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 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.
 38

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.

Monitoring TakingCorre ctive

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;
 39

• 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

• 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:

 40

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)

• 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:

 41

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.

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.
 42

1. Regular or Ongoing Communication Plan

2. One-time or Event-driven Communication Plan

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

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.
 43

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
• 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:

 44

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 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.
 45

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 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)
 46

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 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
 47

work since they have a better insight into the day-to-day activities of
their team members.










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
 48

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

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 can assist in project risk
software 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.
 49

4.2 THE IMPORTANCE OF PROJECT RISK

MANAGEMENT

The project risk management process helps project sponsors

and project teams make informed decisions regarding 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.
 50

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
Risk identification Risk Register (Register)

Qualitative risk analysis Risk Register (updates)

Prioritized list of risks classified as
high, moderate, or low
 51

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 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.
 52

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 riskrelated 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?
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.
 53

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
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.
 54

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.

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.
 55

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.

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

 56

4.5 RISKIDENTIFICATION

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
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.
 57

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.

• 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:
 58

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.

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.
 59

SampleRiskRegister

4.6 QUALITATIVERISKANALYSIS

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.

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.
 60

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
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
 61

Chart Showing High-, Medium-, and LowRisk

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.

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

 62

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 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.
 63

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.

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
 64

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
toprovide the agency with a sufficient degree of certainty?

• 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.
 65

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

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
 66

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 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
 67

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.

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.
 68

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.

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.
 69

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.

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
 70

• 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



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
 71

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

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.
 72

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.

Project Procurement Management is discussed from the

perspective of the buyer in the buyer-seller relationship. The
buyerseller 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 tomany
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.
 73

Figure5.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 planning through contract close-out would be performed
once for each product or service item.
 74

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 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.
 75

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.

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
 76

• 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.

• 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.
 77

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

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 canthey
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.
 78

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
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
.
 79

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
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.
 80

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

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.
 81

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.

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.
 82

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 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 standardcontract.
• 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
proposal, and then a more detailed evaluation will be conducted based
on a more detailed and comprehensive proposal.
 83

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.

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
 84

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 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:

 85

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.

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.
 86

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.

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:

 87

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 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 OUTSOURCING

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
 88

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.

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.
 89

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

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: Projectprocurement 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
















 90





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 Plan and Track
Management
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,
developing a change strategy and evaluating whether the
change was successful or not.
 91

• 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
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
 92

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.

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
 93

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.

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.
 94

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

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.
 95

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.

• 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.
 96

Figure 6.3

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
 97

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.

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.
 98

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.

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
selfinterest 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:
 99

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.

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)
 100

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.

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
 101

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
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
 102

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.

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
 103

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.

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
 104

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.

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.
 105

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.

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’smodel 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 ProjectManagement – 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.solne.org/res/wp/10006.html [2002, March 20].
http://www.a2zpsychology.com/articles/kurt_lewin's_change_theory
.htm [2004, September 9].

 106

 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 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.
 107

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
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.
 108

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.
 109

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
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
 110

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 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
 111

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.

• 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
 112

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 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:
 113

(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

(iii) Outstanding Issues o Itemized list and expected

completion o Any ongoing support required and
duration
(iv) Project Documentation Listo 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.
 114

• Verifying the project sponsor or customer’s formal acceptance

of the project.
• Organizing and archiving all project deliverables
and documentation.

• 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.
 115

• 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.

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:
 116

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?

 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
 117

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

References:

http://www.projectauditors.com/Papers/Your_Project_Has_Been_S
elected_for_an__Audit.pdf
Information Technology ProjectManagement – 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/examquesti
on.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/PostMortems-
Key-to-Successful-Future-Projects.htm
http://www.cis.gsu.edu/~mkeil/cis8150/post-project%20audits.pdf
 118



