Notes on Project Management

& Software Testing

 Section - 1
Syllabus

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. Project Scheduling
a. Developing the project schedule
b. Project management software tools
c. Developing the project budget
d. Finalizing the project schedule and budget
e. Monitoring and controlling the project
f. The project communications plan
g. Project metrics
h. Reporting performance and progress
i. Information distribution

4. The importance of project risk management

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

5. The importance of project procurement management

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

a. The nature of change

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

7. Project Implementation
a. Project implementation
b. Administrative closure
c. Project evaluation

Section – 2
1 INTRODUCTION
1.1 What is Software Testing?
1.2 Role of Testing
1.3 Verification and Validation Testing
1.4 V – Model
1.5 Test planning and Design
1.6 Monitoring & Measuring Test Execution
1.7 Test Tools & Automation
1.8 Test Team Oragnization & Management

2 Testing Technique & System Test Categories

2.1 Difference Between Structural and Functional Testing
2.2 Difference Between Static testing and Dynamic Testing
2.3 Black Box Testing
2.4 White Box Testing
2.5 Unit Testing
2.6 Integration Testing
2.7 System Testing
2.8 Data Flow Testing
2.9 Control Flow Testing
2.10 System Test Categories

3 System Test Planning and Automation

3.1 Structure of a System Test Plan
3.2 System Test Automation
3.3 Automated Software Testing
3.4 What are the skills needed for an automation tester?
3.5 What are the Common Challenges in Automated Testing?
3.6 Budgeting and scheduling
3.7 What are the benefits of Automated Software Testing?
3.8 How does Automated Testing work?
3.9 Requirement for test tools
3.10 Automation testing tool

4 System Test Execution

4.1 What Is Software Testing Metrics?
4.2 What Is Software Test Measurement?
4.3 Types of Test Metrics
4.4 Most used Metrics
4.5 Test Metrics Life Cycle
 3
4.6 Beta Testing
4.7 System Test Report
4.8 Product Sustaining
4.9 Measuring Test Effectiveness
4.10 Test reporting

5 Acceptance Testing
5.1 Acceptance Testing
5.2 Acceptance testing criteria
5.3 Types of Acceptance Testing
5.4 Importance of Acceptance Testing
5.5 Use of Acceptance Testing:
5.6 Selection of Acceptance Criteria
5.7 Acceptance Test Execution
5.8 Software acceptance plan

6 TEST MANAGEMENT
6.1 People and organizational issues in testing
6.2 Organization Structures for Testing Teams
6.3 Test Planning
6.4 Test Plan Components
6.5 Test Plan Attachments
6.6 Test Management
6.7 Testing process
6.8 Introducing the Test Specialist
6.9 Skills needed by a Test Specialist
6.10 Building a Testing Group
 4

1
INTRODUCTION

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

Project management has been practiced since early

civilization. Until the beginning of twentieth century civil engineering
projects were actually treated as projects and were generally
managed by creative architects and engineers. Project management
as a discipline was not accepted. It was in the 1950s that
organizations started to systematically apply project management
tools and techniques to complex projects. As a discipline, Project
Management developed from several fields ofapplication 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
 5

knowledge associated with project and program management. The

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

1.1 WHAT IS A PROJECT?

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

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

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

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

1.1.1 Project Definition:

A project can be defined in many ways :

A project is “a temporary endeavor undertaken to create a

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

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

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

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

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

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 firmsto
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 intotheir new
homes.
- A project is developed using progressive elaboration or in an
iterative fashion.
Projects are often defined broadly when they begin, and as
time passes, the specific details of the project become clearer.
For example, there are many decisions that must be made in
planning and building a new house. It works best to draft
preliminary plans for owners to approve before more detailed
plans are developed.
- A project requires resources, often from various areas.
Resources include people, hardware, software, or other
assets. Many different types of people, skill sets, and
resources are needed to build a home.
- A project should have a primary customer or sponsor. Most
projects have many interested parties or stakeholders, but
someone must take the primary role of sponsorship. The
project sponsor usually provides the direction and funding
for the project.
- A project involves uncertainty. Because every project is
unique, it is sometimes difficult to define the project’s
objectives clearly, estimate exactly how long it will take to
complete, or determine how much it will cost. External factors
also cause uncertainty, such as a supplier going out of
business or a project team member needing unplanned time
off. This uncertainty is one of the main reasons project
management is so challenging.
 7

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 arealso
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 towhat 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 timeconstraint 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 peopleat the
problem, which in turn will raise the cost of the project, unless by doing
this task quicker we will reduce costs elsewhere in the project by an
equal amount.

1.3.1 Time:

For analytical purposes, the time required to produce a product

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

The tasks are also prioritized, dependencies between tasks are

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

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

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 criticalin
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 tofacilitate 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 projectionsat each stage of the
project. Monitoring and feedback also enables the project manager to
anticipate problems and therefore take pre- emptive and corrective
measures for the benefit of the project.
Projects normally involve the introduction of a new system of
some kind and, in almost all cases, new methods and ways ofdoing
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, butwith the rest of the organization
and outside world as well.

1.4.1 Features of projects:

 10

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

1.4.2 Project Classification:

In recent years more and more activities have been tackled

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

a) Engineering and construction

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

b) Introduction of new systems

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

c) Responding to deadlines and change

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

1.4.3 Project Management Tools and techniques:

Project planning is at the heart of project management. One

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

Knowledge Area Tools & Techniques

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

Quality management Quality metrics, checklists, quality control

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

Table 1.1 : Project Management Tools and Techniques

1.4.4 Project Success Factors:

The successful design, development, and implementation of

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

1.5 THE ROLE OF PROJECT MANAGER

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

A project manager is often a client representative and has to

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

In whatever field, a successful project manager must be able

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

When they are appointed, project managers should be given

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

1.5.1 Responsibilities of a Project Manager:

The objective of every project manager is to deliver the product

on time, within budget and with the required quality. Although the
precise responsibilities of a project manager will vary from company
to company and from project to project, they should always include
planning and forecasting. Three additional areas of management
responsibility are:
• ·interpersonal responsibilities, which include:
- leading the project team;
- liaising with initiators, senior management and suppliers;
- being the 'figurehead', i.e. setting the example to the project
team and representing the project on formaloccasions.
• 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
 14

company management for resources, and with project

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

The Project Life Cycle refers to a logical sequence of

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

Diverse project management tools and methodologies prevail

in the different project cycle phases. Let’s take a closer lookat 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 thatthe
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.
 15

• Conceptual design of the operation of the final product.

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

Figure 1.5 : Project Life Cycle

1.6.2 Planning & Design:

After the initiation stage, the system is designed.Occasionally,

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

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

project budget), end user, and business requirements.

- Functions as it was intended.

 16

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

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

Project Maintenance is an ongoing process, and it includes:

• Continuing support of end users

• Correction of errors
• Updates of the software over time

In this stage, auditors should pay attention to how effectively

and quickly user problems are resolved.

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

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 ofthe

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

1.6.4 Closure:

Closing includes the formal acceptance of the project and the

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

This phase consists of:

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

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

Sample Questions

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

management?

2. What is a project, and what are its main attributes? How is a project
different from what most people do in their day-to-day jobs? What
is the triple constraint?

3. What is project management? Briefly describe the project

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

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

Management and their contribution to enterprise success.

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

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

❖❖❖❖
 18

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
 19

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

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

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

from the customers and users perspectives.

- What is important to the customer?

- How will the user actually be using the system.

- What does the world look like from their perspective?

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

- Engineers tend to focus on features while customers are interested

in benefits; how will this help them solve theirproblems.

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

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

Figure 2.1 : Three Sphere model for systems management

 21

2.1.2 A Case:

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

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

Business issues:

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

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

Technological issues:

1. What operating system, server platform, scripting language

and database should be used?

2. What will be the server and desktop specifications?

3. Does our current network setup allow employees to develop

this project, or do we need an upgrade?

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

project?

Organizational issues:

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

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

print division?

3. How will the website affect our print audience?

The most important issues are from the business and

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

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 unlikelythat an existing
line management structure will be sufficient or appropriate to use as
a project management organisation, except perhaps where a small
task is being run within a single business unit with no external impact.

A typical organisation structure is depicted in the figure below

Top Management

Project Board &

other functionaries

Project manager

Project team

Figure 2.2 Organizational Structure

A well-designed organisation will involve the right people with

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

exception situations outside authority of the project’s Senior

Responsible Owner.

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

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

Designing the structure and getting people to agree to take

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

2.2.1 The key roles:

2.2.1.1 Top management: (in certain circumstances/environments

known as Project Sponsor(PS) or Programme Director).
The management is the project’s owner and champion and is
ultimately accountable for delivery of the project and so must:
• provide leadership and direction to other members of the
Project Board and to the Project Manager
• ensure that all key stakeholders are committed to the project
and adequately represented in the project’s organisation
structure
• ensure that budget holders and resource owners are
committed to the proj ect and that the necessary funds and
other resources are made available when required
• ensure that project governance arrangements of appropriate
rigour are put in place
• brief senior stakeholders on the current and forecast status
of the project
• receive, consider and act on regular frequent reports/briefings
from the Project Manager
• chair meetings of the Project Board
• ensure that all members of the Project Board understandtheir
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
 24

• 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 wishto set up
a Project Board with the PS as Chair.

2.2.1.2 The Project Board:

The Project Board should include:

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

The Project Board must jointly:

• create an environment where the project can succeed in
delivering the changes necessary for the benefits to be realised
• set the direction for the project and to approve keymilestones
• 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.
 25

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 andBusiness
Case to the Project Board for approval
• monitor progress of the project and identify and take actionto
deal with any potential/actual exceptions that might jeopardise
achievement of the project’s objectives,
• maintain a Risk Register/Log and actively manage risks using
resources and approaches within limits of delegated authority
• escalate to the Project Board recommendations for risk
mitigations actions outside the scope of delegated authority
limits
• report progress to, and take advice from, the PS at regular
intervals as agreed between PS and Project Manager during
Project Initiation
• manage stakeholder relationships and communications (in
accordance with an agreed Communications Plan);
• liaise with any nominated Project Assurance staff throughout
the project.

2.3 STAKEHOLDER MANAGEMENT

The importance of stakeholder management is to support an

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

Stakeholder Management, within business or projects,

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

• Stakeholder Identification - Interested parties either

internal or external to organisation/project.
 26

• 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 opportunityto discuss and
agree expectations of communication and, primarily, agree a
set of Values and Principles that all stakeholders will abide by.

• Communicating Information - Expectations areestablished

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

2.3.1 Stakeholder Agreements: A collection of agreed decisions

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

Contemporary or modern business and project practice favours

transparent, honest and open stakeholder management processes.

2.4 THE CONTEXT OF INFORMATION TECHNOLOGY

PROJECTS

2.4.1. Software Projects:

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

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. Indoing 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-termplanning, 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.
 28

Figure 2.3: Certain important issues in Software Project

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

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 tothe
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 closerto
the end by adding increments (e.g., new functions, new design, new
modules, new or improved testing procedures, new orimproved parts
of the user interface, new integration and testing certificates, and so
on) to the product in each iteration.
 30

Figure 2.5 : Spiral Model for Software Development

The spiral model underlies many processes, such as DBWA
(Design By Walking Around), and PADRE (Plan-Approve-Do-
Review-Evaluate). The DBWA process combines the spiral model
with multiple design views, flexible structuring of development teams,
and dynamic changes in modes of working (e.g., working individually,
working in pairs, or working in small teams), in order to improve the
process efficiency and parallelism. The PADREprocess 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 setof agreed, well understood,
and carefully documented requirements
. This implies the need for requirements traceability, i.e. the ability
to describe and follow the life of a requirement, in both a forward
and backward direction, ideally through the whole system's life cycle.

The importance of constantly involving the users in the process

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

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.

❖❖❖❖
 32

3
PROJECT SCHEDULING
Unit Structure:
3.1 Developing the Project Schedule
3.1.1. Schedule Inputs
3.1.2. Scheduling Tools
3.2 Project Management Software Tools
3.2.1. Allocate Resources to the Tasks
3.2.2. Identify Dependencies
3.2.3 Create the Schedule
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
3.6.1 Reasons for Project Metrics
3.6.2 Key Project Metrics
3.6.3 Developing Project Metrics
3.7 Reporting Performance & Progress
 33

3.7.1 Project Status Report

3.1 DEVELOPING THE PROJECT SCHEDULE

Can you imagine starting a long car trip to an unfamiliar

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

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

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

Luckily, drivers have fairly accurate tools they can use.

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

Because of the uncertainty involved, the schedule is reviewed

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

Schedules also help you do the following:

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

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

Project managers have a variety of tools to develop a project

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

3.1.1. Schedule Inputs:

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. Youcan also include
stakeholder expectations, which will often determine project
milestones.

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

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

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

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

A project manager should be aware of deadlines and resource

availability issues that may make the schedule less flexible.

3.1.2. Scheduling Tools:

Here are some tools and techniques for combining theseinputs

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 methodcalculates
the earliest and latest possible start and finishtimes for project
activities, and it estimates the dependencies among them to
create a schedule of critical activities and dates.
 35

• Schedule Compression - This tool helps shorten the total

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

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

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

• Fast-Tracking - This involves rearranging activities to allow

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

3.2 PROJECT MANAGEMENT SOFTWARE TOOLS

There are many project scheduling software products which

can do much of the tedious work of calculating the schedule
automatically, and plenty of books and tutorials dedicated to teaching
people how to use them. However, before a project manager can use
these tools, he should understand the concepts behind the work
breakdown structure (WBS), dependencies, resource allocation,
critical paths, Gantt charts and earned value. These are the real keys
to planning a successful project.
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 fromcontractors, 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. Todo

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

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.
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’sresponsibility 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 bedependent on another.
Figure 3.1: Task Dependency

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

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 andE is a summary task,
which shows that these tasks are two subtasks of the same parent
task. Summary tasks can contain other summary tasks as
subtasks. For example, if the team usedan 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 asits subtasks.
 38

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

Microsoft Projects :

Figure 3.3 Gantt Chart drawn using Microsoft Project.

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

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

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

These numbers are arbitrary; they are simply used to compare

the probability or impact of one risk with another, and do not carry
any specific meaning. The numbers for probability and impact are
assigned to each risk; a priority can then be calculatedby 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 valuefor 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 another1, 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 witha low impact or
low-probability risks with a high impact. This is generally the order in
which a good project manager will want to tryto deal with them: it
allows the most serious risks to rise to the topof 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.
 40

Accounting, costing and budgeting are extensive topics in

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

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

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

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

with one another and are attributed to the same point in the
schedule. For example if the costs of hardware are in your budget at
the point where you pay the invoice, then ALL the costsfor 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)
 41

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

tied directly to employing, training and retaining staff.

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

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

• Supplies and consumables – regular expenditure on supplies is

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

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

related to any of the above categories but occurs on an irregular basis.
Staff training might be an example. While it might be appropriate to
list this under staff costs you might wish to track it independently as
an irregular cost. The choice is yours but theprinciples 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 thebudget 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
 42

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

You must be extremely careful with initial estimates and always

follow the “promise low / deliver high” commandment.

Costing and budgeting follow the iterative life cycle as do other

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

As in scheduling, you need to build in adequate contingency

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

Just as in scheduling you should have regular budget reviews

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

Regardless of circumstance, a number of basic philosophies

can help your budgeting immensely by protecting it from subjective
review. By understanding concepts, and making sure that everyone
involved understands them, you’ll be on the right track to an accurate
projection:
• Project costs and project budgets are two different things.
Always start by identifying project costs.
• Project costs are not defined solely in monetary amounts.
Include actual amounts, with shipping and taxes, for software
or hardware purchases that must be made. If you’re pro-rating
the costs of using pre-existing hardware and software tools,
include it in number of hours. Likewise, developer effort costs
are recorded in hours, not dollars.
• Once you’ve laid out your costs, identify your risks and assign
a percentage reflecting how much each risk factor may affect
the project as a whole, or a portion of the project. Each
development team should have a risk value assignedto 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 transcribedinto
a monetary figure, plus the total risk percentage of that
 43

cost. Define conversion values that you use to represent

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

3.4 MONITORING AND CONTROLLING THE PROJECT

To appreciate how project control works you must first

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

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

The plan describes what you would like to do but it models just
one of the infinite number of routes from where you are now to where
you want to be. In practice your project will follow a different route to
the one shown in your plan, you don’t know which one, but you will
need control to make sure it is a route that takes you to where you
need to be, when you need to be there, and at a costyou 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.
 44

Monitoring Taking Corrective

Planning

Figure 3.4 : Project Control

The basic requirements for control are:

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

In all but the smallest or shortest projects you should think

about how to break your project into manageable ‘chunks’ called
stages. Every project will have a minimum of two stages – the first
being Project Initiation. A large project may have a number of stages,
each of which has its own stage plan. When designing your project’s
stage structure look for points where the Project manager should:
• review achievements to date and assess project viability
• take key decisions outside the level of authority of the Project
Manager
 45

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

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

The Project Manager will also be able to identify stage

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

3.4.1 Checkpoints:

Checkpoint reports are produced by team managers / leaders

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

Checkpoints are essential controls – missed checkpoints are usually

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

3.4.1.1 Checkpoint design:

There are many different ways of conducting Checkpoints -

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

• 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 requestsfor 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 planwould b
e submitted for a decision to proceed.

3.4.3 Monitoring System Performance:

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

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 howdo 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 opportunitiesfor
communications to your key stakeholders, and we recommend
exploring two types of communication plans for your project to exploit
these opportunities.

1. Regular or Ongoing Communication Plan

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

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

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

 49

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 plancould
also include critical issues sessions, vendor meetings, training
schedules, and roll-out schedules.

To gain the most advantage from the communications

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

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

3.6 PROJECT METRICS

Metrics are a set of quantifiable parameters which are used

to measure the effectiveness of a project or undertaking. Values are
obtained for the parameters for multiple instances of the same entity
and they are compared and interpreted as to the change inthe
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 theusers 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.

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
 50

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

3.6.2 Key Project Metrics:

Senior management will often wish to see regular reports of

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

• Schedule - delivery date and slippage in days from original

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

Other metrics associated with normal operation such as

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

Project metrics selected should reflect the voice of the

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

When drafting metrics for a particular project one should

consider how the metrics are connected and related to key
 51

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

3.6.3 Developing Project Metrics:

The most common approach used by teams is to understand

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

Care should be exercised in determining what is measured.

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

3.7 REPORTING PERFORMANCE & PROGRESS

Performance reporting involves collecting, processing and

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

Performance review meetings that take place to assess the

project’s progress or/and status

Variance analysis which is about comparing actual project results (in

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

Earned Value Analysis (EVA) used to assess project performance

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

Financial and Output Performance Indicators used to measure

financial and physical progress of the project

Information of project’s performance is usually communicated via

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

The Progress Report is a document prepared by the Project

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

regular feedback to the Project Manager regarding the progress of the

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

- Reporting period to which it refers

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

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

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

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

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

Updated/ revised Activities Schedule showing the percentage

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

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

team members, the Progress Report can be substituted bypersonal
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
 53

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 themeeting by the
respective Team Manager(s), who can communicate the status of
their team work since they have a better insight into the day-to-day
activities of their team members.

❖❖❖❖
 54

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.2 The Risk Register
4.6 Qualitative Risk Analysis
4.6.1 Using Probability/Impact Matrix To Calculate Risk
Factors
4.6.2 Top Ten Risk Item Tracking
4.6.3 Expert Judgment
4.7 Quantitative Risk Analysis
4.7.1 Decision Trees and Expected monetary Value
4.7.2 Simulation
4.7.3 Sensitivity Analysis
4.8 Risk Response Planning
4.9 Risk Monitoring and Control
4.10. Using Software to Assist in Project Risk Management
4.11 Summary

4.0 OBJECTIVES

After reading this chapter you will be able to:

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

2. Discuss the elements involved in risk management planning

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

4.1 INTRODUCTION

Managing risk is an integral part of good management and is

something many managers do already in one form or another.

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

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

4.2 THE IMPORTANCE OF PROJECT RISK

MANAGEMENT

The project risk management process helps project

sponsors and project teams make informed decisions regarding
 56

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

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, andrisk
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 outcomesthat
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 potentialpositive
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
 58

Risk identification Risk Register (Register)

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

4.3 RISK MANAGEMENT PLANNING

Risk management planning is the process of deciding how to

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

The project team should hold several planning meeting early in

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

Careful and explicit planning enhances the possibility of

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

and conduct the risk management activities for a project. Planning

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

The result of Risk Management Planning is a Risk

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

A risk management plan summarizes how risk management

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

Methodology: How will risk management will be performed on this

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

Roles and responsibilities: who are the individuals responsible for

implementing specific tasks and providing deliverables related to risk
management

Budget and schedule: What are the estimated costs and

schedules for performing risk related activities?

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

Risk Probability and Impact: How will the probabilities and impacts
of risk items be assessed?. What scoring and interpretation methods
will be used for the qualitative and quantitative analysis of risks?

Risk Documentation: What reporting formats and processes will

used for risk management activities?
 60

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 ifattempts 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 planswork out a fallback plan
might be to live at home for a while. Sometimes contingency plans
and fallback plans are used interchangeably.

Contingency reserves or contingency allowances are

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

4.4 COMMON SOURCES OF RISK IN INFORMATION

TECHNOLOGY PROJECTS

Several studies show that IT projects share some common

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

Information Technology Success Potential Scoring Sheet

Success Criterion Relative Importance

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

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 tothe
user involvement criterion by adding 3.8 points to the score for each
question you can answer positively.

4.4.1 Categories of Risk:

A broad categories of risks are described on the questionnaires

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

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

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

□ Financial risk: Can the organization afford to undertake the

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

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

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

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

4.4.2 Risk Breakdown Structure:

□ A risk breakdown structure is a hierarchy of potential risk

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

A risk break down structure is a useful tool that can help project
managers consider potential risks in different categories. The highest
level categories are business, technical, and organizational and
project management. Competitors suppliers, and cash flow are
categories that fall under business risks. Under technical risk are the
categories h/w, s/w, and network.
 63

A risk break down structure provides a simple, one page chart

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

The following table shows the potential negative risk conditions

that can exist within each knowledge area.

Potential Risk Conditions Associated With Each Knowledge Area

4.5 RISK IDENTIFICATION

Risk identification involves identifying potential project risks.

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

Participants in risk identification activities can include the

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

participants for risk identification, all project personnel should be

encouraged to identify risks.

4.5.1 Suggestions For Identifying Risks:

The assigned team members identify the potential risks

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

There are several other tools and techniques also for

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

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

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

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

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

• Helps identify the broad negative risks that apply to a

project.

Applying SWOT to specific potential projects can help

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

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

It is important to analyze project assumptions to make sure that

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

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

4.5.2 The Risk Register:

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

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

A risk register is:

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

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

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

4.6 QUALITATIVE RISK ANALYSIS

□ Assess the likelihood and impact of identified risks to determine

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

4.6.1 Using Probability/Impact Matrix To Calculate Risk

Factors:

• A probability/impact matrix or chart lists the relative probability

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

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

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 specificevents ,based on
their probability of occurring and consequences to the project if they
do occur. The technique makes use ofProbability/Impact Matrix that
shows the probability of risks occurring and the impact or
consequences of the risks.

Probability of a risk occurring can be estimated based on

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

Sample Probability/Impact Matrix

The following figure gives an example of how the risk factors

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

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

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

Chart Showing High-, Medium-, and Low-

Risk Technologies

4.6.2 Top Ten Risk Item Tracking:

Top Ten Risk Item Tracking is a qualitative risk analysis tool

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

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

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

List the current ranking, previous ranking, number of times the

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

The following figure provides an example of Top Ten Risk Item

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

Example of Top Ten Risk Item Tracking

4.6.3 Expert Judgment:

Many organizations rely on the intuitive feelings and past

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

The main output of qualitative risk analysis is updating therisk

register .The ranking column of the risk register should be filledin
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
 70

identified as potential risks. Qualitative analysis can also identify

risks that should be evaluated on a quantitative basis.

4.7 QUANTITATIVE RISK ANALYSIS

Often follows qualitative risk analysis, but both can be done

together.

Large, complex projects involving leading edge technologies

often require extensive quantitative risk analysis.
Main techniques include:
• Decision tree analysis
• Simulation
• Sensitivity analysis
Quantitative risk analysis is a way of numerically estimating the
probability that a project will meet its cost and time objectives.
Quantitative analysis is based on a simultaneous evaluation of the
impact of all identified and quantified risks. The result is a probability
distribution of the project’s cost and completion date based on the
identified risks in the project.
Quantitative risk analysis involves statistical techniques,
primarily Monte Carlo simulation that is most widely and easily used
with specialized software.
Quantitative risk analysis starts with the model of the project,
either its project schedule or its cost estimate depending on the
objective. The degree of uncertainty in each schedule activity and
each line-item cost element is represented by a probabilitydistribution.
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.
 71

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

To create a decision tree and to calculate expected monetary

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

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

• 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, andfixed
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 thesensitivity of various project
variables.
 73

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

 74

Risk Response Planning is the process of developing options,

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

The project manager and the PDT identify which strategy is

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

Strategies for Negative Risks or Threats include:

□ Avoid: Risk avoidance involves changing the project plan to

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

These changes may require a Programming Change Request

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

□ Transfer: Risk transference requires shifting the negative impact of

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

Transference reduces the risk only if the contractor is more

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

Transference tools can be quite diverse and include, but are

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

□ Mitigate. Risk mitigation implies a reduction in the probability

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

Risk mitigation may take resources or time and hence may

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

still be preferable to going forward with an unmitigated risk. Monitoring

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

General Risk Mitigation Strategies for Technical, Cost, and

Schedule Risks

Strategies for Positive Risks or Opportunities include:

□ Exploit. The organization wishes to ensure that the opportunity

is realized. This strategy seeks to eliminate the uncertaintyassociated
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.
 76

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

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

There are two types of acceptance strategy:

1. Active acceptance. The most common active acceptance strategy

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

2- Passive acceptance. Requires no action leaving the project team

to deal with the threats or opportunities as they occur.

i. Workaround:
Workaround is distinguished from contingency plan in that a
workaround is a recovery plan that is implemented if the eventoccurs,
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 prioritizationcommonly change during
the project lifecycle.
 77

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

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

Risk control involves:

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

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

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

4.10. USING SOFTWARE TO ASSIST IN PROJECT

RISK MANAGEMENT

Most organizations use software to create , update , and

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

More sophisticated risk management software such as Monte

Carlo Simulation s/w can help you develop models and use
simulations to analyze and respond to various risks. There arealso
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

Risk Management is always forgotten when managingprojects

but the irony is that all projects have risk. People in general think that
risk management is just a blaming session to uncoverflaws in a
particular project. This perception has to be abolished.
 78

Management and Project managers have to understand that

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

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

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

This chapter we discussed the importance of risk management

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

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

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

Main processes include:

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

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

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

❖❖❖❖
 79

5
PROJECT PROCUREMENT
MANAGEMENT

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

5.0 OBJECTIVES

• To understand the importance of project procurement

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

5.1 INTRODUCTION

Project Procurement Management includes the processes

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

5.2 Procurement Planning—determining what to procure and

when.

5.3 Solicitation Planning—documenting product requirements and

identifying potential sources.

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

as appropriate.

5.5 Source Selection—choosing from among potential sellers.

5.6 Contract Administration—managing the relationship with the

seller.

5.7 Contract Close-out—completion and settlement of the

contract, including resolution of any open items.

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

Project Procurement Management is discussed from the

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

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

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

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

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

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

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

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

Figure 5.1

5.2 PLANNING PURCHASES AND ACQUISITIONS

(PROCUREMENT PLANNING)

Procurement planning is the process of identifying which

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

When the project obtains products and services from outside

the performing organization, the processes from solicitation
 83

planning through contract close-out would be performed once for

each product or service item.

The project management team should seek support from

specialists in the disciplines of contracting and procurement when
needed.

When the project does not obtain products and services from
outside the performing organization, the processes from solicitation
planning through contract close-out would not be performed. This
often occurs on research and development projects when the
performing organization is reluctant to share project technology, and
on many smaller, in-house projects when the cost of findingand
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 procurementplanning.

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
 84

entire product, the distinction between the two terms becomes moot.

3 Procurement resources: If the performing organization does not

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

5.2.2 Tools and Techniques for Procurement Planning:

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

which can be used to determine whether a particular product can be
produced cost-effectively by the performing organization. Both sides
of the analysis include indirect as well as direct costs. For example,
the “buy” side of the analysis should include both theactual 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 costallocated 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.
 85

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

Make-or Buy Solution:

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

2 Expert judgment: Expert judgment will often be required to assess

the inputs to this process. Such expertise may be providedby any
group or individual with specialized knowledge or trainingand 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.
 86

• Cost reimbursable contracts—this category of contract

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

Three types of cost reimbursable contracts in order of lowest

to highest risk to the buyer include cost plus incentive fee, cost
plus fixed fee, and cost plus percentage of costs With a cost plus
incentive fee (CPIF) contract the buyer pays the supplier for allowable
performance cost along with a predetermined fee and an incentive
bonus.if the final Cost is less than the expected cost, both the buyer
and the supplier benefit from the cost saving.
With a cost plus fixed fee (CPFF) contract the buyer pays the
supplier for the allowable performance cost plus a fixed fee payment
usually based on a percentage of estimated costs.
With a cost plus percentage of costs(CPPC) contract thebuyer
pays the supplier for allowable performance costs along witha
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 servicesor
$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
 87

5.2.3 Outputs from Procurement Planning:

1. Procurement management plan. The procurement management

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

A procurement management plan may be formal or informal,

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

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

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

Some application areas recognize different types of SOW.

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

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

as concise as possible.

It should include a description of any collateral services

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

specific content and format requirements for a SOW. The following

figure shows a template of statement of work.

Statement of Work (SOW) Template

5.3 SOLICITATION PLANNING (PLANNING

CONTRACTING)

Solicitation planning involves preparing the documents needed to

support solicitation
.

Steps in solicitation planning

5.3.1 Tools and Techniques for Solicitation Planning:

1. Standard forms: Standard forms may include standard

contracts, standard descriptions of procurement items, or
 89

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 procurementdocuments

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 governmentagency,
may be defined by regulation.
Procurement documents should be rigorous enough to ensure
consistent, comparable responses, but flexible enough to allow
consideration of seller suggestions for better ways to satisfy the
requirements. The following figure shows a template for RFP

Request For proposal Template

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

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 boththe
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 thelowest
total cost (purchase cost plus operating cost)?
• Technical capability—does the seller have, or can the seller be
reasonably expected to acquire, the technical skills and knowledge
needed?

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

in Section 12.1.3.2.

Modifications to one or more statements of work may be identified

during solicitation planning.

5.4 REQUESTING SELLER RESPONSES

(SOLICITATION)

Solicitation involves obtaining information (bids and proposals)

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

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 characteristicsof the
prospective sellers.

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

Procurement documents may be sent to some or all of the

prospective sellers.

5.4.2 Tools and Techniques for Solicitation:

1. Bidder conferences: Bidder conferences (also called

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

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

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

government jurisdictions require public advertising of subcontracts

on a government contract.

5.4.3 Outputs from Solicitation:

1. Proposals: Proposals are seller-prepared documents that describe

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

5.5 SOURCE SELECTION (SELECTING

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

Source selection involves the receipt of bids or proposals and

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

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

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

The tools and techniques described below may be used singly

or in combination.

For example, a weighting system may be used to:

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

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

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

proposal, and then a more detailed evaluation will be conducted

based on a more detailed and comprehensive proposal.

Steps in source selection

5.5.1 Inputs to Source Selection:

1. Proposals. Proposals are described in Section 5.2.2.

2. Evaluation criteria. Evaluation criteria are described in Section

5.2.2(2)

3. Organizational policies. Any and all of the organizations

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

5.5.2 Tools and Techniques for Source Selection:

1. Contract negotiation: Contract negotiation involves clarification

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

For complex procurement items, contract negotiation may be

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

Negotiation tools, techniques, and styles are widely discussed

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

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

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

3. Screening system: A screening system involves establishing

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

4 Independent estimates: For many procurement items, the

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

5.5.3 Outputs from Source Selection:

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

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

5.6 CONTRACT ADMINISTRATION

Contract administration is the process of ensuring that the

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

Contract administration includes application of the appropriate

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

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

5.6.1 Inputs to Contract Administration:

1. Contract. Contracts are described in previous Section

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

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

3. Change requests. Change requests may include modificationsto

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, areusually 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.
 96

Project managers and teams should stay closely involved to

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

Contract administration also has a financial management

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

5.6.3 Tools and Techniques for Contract Administration”

1. Contract change control system: A contract change control

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

2. Performance reporting: Performance reporting provides

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

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

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

5.6.4 Outputs from Contract Administration:

1. Correspondence: Contract terms and conditions often require

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

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

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

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 informationfor future
use). The contract terms and conditions may prescribe specific
procedures for contract close-out. Early termination of a contract is a
special case of contract close-out.

5.7.1 Inputs to Contract Close-out:

Contract documentation: Contract documentation includes, but is

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

5.7.2 Tools and Techniques for Contract Close-out:

Procurement audits: A procurement audit is a structured review of

the procurement process from procurement planning throughcontract
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
 98

track suppliers, and presentation software helps present

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

5.9 OUT SOURCING

Outsourcing software development and other information

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

5.9.1 Benefits of outsourcing

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

Information technology is rapidly becoming more complexand

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 projectsthat 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 ofa project. This
flexibility and the availability of a larger talent pool provides optimum
results at the lowest cost.
 99

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 wecould
discuss the various steps involved in the procurement management
process needed for a project.

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

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)

❖❖❖❖
 101

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.2 Implement Change Management Plan and Track
progress
6.4 Dealing with resistance and Conflict
6.4.1 Polarity Management
6.5 Summary

6.0 OBJECTIVES

After reading this chapter, you will be able to

• Describe the ADKAR model for change management allowing

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

developing a change strategy and evaluating whether the

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

6.1 INTRODUCTION

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

Winston Churchill

Nothing can better emphasize the need for change. Every

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

Change management enables planning, controlling and

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

The change you must, at the needed intervals. Change could

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

According to Leslie Jaye Goff, the change management is

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

The central theme of this chapter has been the concept of

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

6.2 THE NATURE OF CHANGE

This section focus on the ADKAR result-oriented model of

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

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

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

The ADKAR change model was first published by Prosci in

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

Change management, a critical component of business, can

be achieved successfully using the ADKAR procedure. Change often
brings high levels of stress and agitation to people. It is usedas a
resistance management tool, an assessment device and tohelp
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 ofthe
changes to be made.
 104

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

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

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

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

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

Figure 6.1

6.2.2 Change is a process:

Kurt Lewin emigrated from Germany to America during the

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

Lewin proposed a three stage basic theory of change includes

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

Figure 6.2 depicts a transition from present state to the desired

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

Stage 1 – becoming motivated to change (unfreezing)

This phase of change is built on the theory that human

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

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

to a new state)

Once there is sufficient dissatisfaction with the current

conditions and a real desire to make some change exists, it is
necessary to identify exactly what needs to be changed. A concise
view of the new state is required to clearly identify the gap between
the present state and that being proposed. Activities that aid inmaking
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
 106

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 whatis
happening, resulting in temporary confusion or complete
disorientation.
• Denial – It is a conscious or unconscious refusal to accept facts,
information, reality, etc., relating to the situation concerned. For
e.g., when a person is informed that she is being fired by
organization, the initial response may be, Are you serious?
•Anger – The anger is a more active emotional response. People
dealing with emotional upset can be angry withthemselves, 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 lessserious
trauma can bargain or seek to negotiate a compromise. For e.g.,
the person who is fired from the organization maypromise 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.
 107

•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 inyour
projects. Often, just having a set of rules by which you and all involved
team members and stakeholders can follow makes it easier for you
to deal with the change that will inevitably crop up in your projects.
This way, you can focus more energy on planning and monitoring
and less energy on fighting fires.

Once the change management plan has been developed it

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

Figure 6.3
 108

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 makeresources
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 abilityto
sustain the change with the IT projects rests with the change agents.

Change Advocate An advocate is the individual (or group)

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

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

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

Leavitt suggests that the effectiveness of any change program

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

Leavitt's Model of Change: Task,

Technology, Structure, and People

Figure 7.4

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

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

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

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

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

People become confused and disoriented when the rules for

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

6.3.1 Develop a Strategy for Change:

The developing a strategy for change is the step after the

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

Rational-Empirical Approach

The Rational-Empirical strategy suggests that most people

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

It is important that the individuals affected by the change be

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

The change management plan based on this strategy should

provide each individual with the purpose, a picture and a part to
play. Often individuals within organization have a narrow view of their
job and its relationship to the rest of the organization. It maybe
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 inthe 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:
 111

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 normscan 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 ison 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.
 112

As Davidson observes, People’s dependency on an

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

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

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

Environmental-Adaptive Approach:

People oppose loss and disruption but they adapt readily to

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

Following this approach, the change agent attempts to make

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

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

Although this approach may be effective in certain situations,

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

A single strategy however, may not be effective in every

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

6.3.2 Implement the Change Management Plan and Track

Progress:

Once the strategies for the change management plan have

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

The effective line of communication is the critical issue for

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

The open channels of communication should be both ways.

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

Evaluate Experience and Develop Lessons Learned:

As the project team carries out the change management plan,

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

6.4 DEALING WITH RESISTANCE AND CONFLICT

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

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

Resistance:

With change, comes resistance. Regardless of how clear and

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

Resistance to change comes for many valid reasons. For

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

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

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

Kotter and Schlesinger set out the following six change

approaches to deal with resistance to change:

❖ Education and Communication - Where there is a lack of

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

Conflict:

Closely associated with resistance is the concept of conflict.

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

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 occasionallystir
the pot in order to encourage conflict to an appropriate
level so that people engage in positive conflict.

For the project manager and project team, the seeds of

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

❖ Avoidance – Avoiding conflict focuses on retreating,

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

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 changethe status quo and are
supporters of change. They contribute by identifying the downsides of
the current pole and provide the energy to move away from the
current pole. Tradition Bearers - are at the opposite end of the pole
and wish to preserve the best of the past and present and help identify
things that should be preserved. Using a tool Polarity mapping, we
can see the upsides and downsides that each side is advocating.
Figure 6.5 provides anexample 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.
 117

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 nota case
of choosing one idea over another.

The key to polarity management is recognizing that both polarities

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

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 conceptof Force
Field Analysis, in which we try to understand the driving and resisting
forces that push and repel the change. Lewis model of change helps
us to understand that we must unfreeze the current state until the
desired new state is reached.

In this chapter we understood how to develop effects change

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

Sample Questions:

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

model for change.

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

3. In your own words, describe polarity management.

❖❖❖❖
 119

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

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
 120

information system project implementation would be the installation of

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

In general, implementing the product of an IT project can follow

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

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

end. Once the project is implemented, the project manager and his
team must prepare for closing the project. A project is properlyclosed
for two reasons. Firstly, there is a tendency for projects todrift 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 transferredsuccessfully

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

new system is critical and this approach may also be appropriate

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

Figure 7.1

Companies often choose the direct cutover approach for

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

7.2.2 Parallel:

Parallel approach as shown in figure 7.2 is the method in which

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

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 confidencethat
the new system is functioning and performing properly before relying
on it entirely. It is also impractical to use this approach asthe 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 successfullyat 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
 123

implement an accounting information system package by first

implementing the general ledger component, then accounts payable
etc.

Figure 7.3

This method is one of the least risky because implementation

only takes effect in part, incase an error goes wrong with the new
system, only that particular affected part is at risk. A phased approach
may also allow the project team to learn form its experiences during
the initial implementation so that thelater 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 independentlyit 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
 124

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 tothe people,
processes or technology.

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

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

Ideally a project is closed under normal circumstances.

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

• Team members are concerned about future jobs. Often the

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

• Resources are running out. Resources and the project

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

• Documentation attains paramount importance. The IT

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

• Promised delivery dates may not be met. Most projects

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

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

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

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

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

7.3.1 Project Sponsor Acceptance:

The most important requirement for closure under normal

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

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

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

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

the most important criteria for accepting the project.

Knowledgeable sponsors – they have an important stake in the

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

Regardless of whether the sponsor is shortsighted or

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

A clearly definition of the project deliverables is an important

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

Project milestones ensure that the deliverables are complete.

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

7.3.2 The Final Project Report:

The project manager and team should develop a final report

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

The report may be circulated to key stakeholders before the

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

(iii) Outstanding Issues

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

7.3.3 The Final Meeting and Presentation:

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

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

• Communicating that the project is over. By inviting key

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

• Transferring the information system from the project team to

the organization. Although the system may have beenimplemented
and is being used by the organization, the final meeting provides a
formal exchange of the project’s product fromthe 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 isa
necessity because once the project manager and team are officially
released from the current project, getting them to wrap up the last of
the details will be difficult. The requirements for administrative closure
include:
• Verifying that all deliverables and open items are complete.
• Verifying the project sponsor or customer’s formal acceptance
of the project.
• Organizing and archiving all project deliverables and
documentation.
 128

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

• 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 focusof 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 qualityobjective 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.
 130

After the investigation is completed, a report should be drafted

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

Project Audit:

The individual view and postmortem review provide an

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

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

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

The findings of the project audit should be documented, as well

as any lessons learned and best practices.

Evaluating Project Success – The MOV

The MOV – measurable organization value provided the basis

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

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

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

7.5 SUMMARY

In this chapter, you looked four approaches to implementation.

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

Once the IS has been implemented, the project managerand

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 documentedand
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 thisdistinction
help the project manager during project closure?
For solution refer 7.3.1

❖❖❖❖
Section – 2 Software Testing
 1. Introduction
1.1 What is Software Testing?

• Software testing is a process of identifying the correctness of software by

considering its all attributes (Reliability, Scalability, Portability, Re-usability,
Usability) and evaluating the execution of software components to find the
software bugs or errors or defects.

133
 • Software testing provides an independent view and objective of the software and
gives surety of fitness of the software.
• Testing is mandatory because it will be a dangerous situation if the software fails
any of time due to lack of testing. So, without testing software cannot be deployed
to the end user.

1.2 Role of Testing :

• Testing is an infinite process of comparing the invisible to the ambiguous in order to

avoid the unthinkable happening to the anonymous.”
• Testing plays a vital role in software development. In every company, testing is an
important and valuable stage in the Software Development Life Cycle.
• Software testing is not an easy task. Each and every day there will be challenges in
coding as well as decoding.

1.3 Verification and Validation Testing :

Verification testing :

• Verification testing includes different activities such as business requirements,

system requirements, design review, and code walkthrough while developing a
product.
• It is also known as static testing, where we are ensuring that "we are developing
the right product or not". And it also checks that the developed application
fulfilling all the requirements given by the client.

134
Validation testing :

• Validation testing is testing where tester performed functional and non-functional

testing. Here functional testing includes Unit Testing (UT), Integration Testing (IT)
and System Testing (ST), and non-functional testing includes User acceptance
testing (UAT).
• Validation testing is also known as dynamic testing, where we are ensuring
that "we have developed the product right." And it also checks that the software
meets the business needs of the client.

135
Note: Verification and Validation process are done under the V model of the software
development life cycle.

Difference between verification and validation testing :

Verification Validation

We check whether we are developing the We check whether the developed product is
right product or not. right.

Verification is also known as static testing. Validation is also known as dynamic testing.

Verification includes different methods like Validation includes testing like functional
Inspections, Reviews, and Walkthroughs. testing, system testing, integration, and User
acceptance testing.

136
It is a process of checking the work- It is a process of checking the software during
products (not the final product) of a or at the end of the development cycle to
development cycle to decide whether the decide whether the software follow the
product meets the specified requirements. specified business requirements.

Quality assurance comes under Quality control comes under validation

verification testing. testing.

The execution of code does not happen in In validation testing, the execution of code
the verification testing. happens.

In verification testing, we can find the bugs In the validation testing, we can find those
early in the development phase of the bugs, which are not caught in the verification
product. process.

Verification testing is executed by the Validation testing is executed by the testing

Quality assurance team to make sure that team to test the application.
the product is developed according to
customers' requirements.

Verification is done before the validation After verification testing, validation testing
testing. takes place.

In this type of testing, we can verify that In this type of testing, we can validate that
the inputs follow the outputs or not. the user accepts the product or not.

1.4 V – Model :

137
The V-model of SDLC carries out its execution in a sequential manner. The structure it
follows takes the shape of the letter V. This model is also popularly termed as
a Verification and Validation model. Here, each phase has to be finished before
beginning the next phase. A sequential design progression is followed like that of the
waterfall model.

• The design of V-Model :

In parallel to the software development phase, a corresponding series of test phase also
runs in this model. Each stage comprises a specific type of testing done, and once that
testing is passed, only then the next phase starts.

138
1. Verification: In the concept of verification in the V-Model, static analysis technique
is carried out without executing the code. This evaluation procedure is carried out
at the time of development to check whether specific requirements will meet or
not.

2. Validation: This concept of V-Model comprises of dynamic analysis practice (both

functional as well as non-functional), and testing is done by code execution. The
validation of a product is done once the development is complete for determining if
the software meets up the customer hope needs.

139
So both verification and validation are combined and work in parallel to make the V-
Model fully functional.

Design Phase
1. Requirement Analysis: In this stage of SDLC, a detailed conversation with the
customer is made to understand their requirements as well as anticipation.
Requirement gathering is another name of this phase.
2. System Design or High-level Design: In this phase of SDLC, the system is designed
with the entire hardware & the setup is constructed for product development.
3. Architectural Design: The breakdown of system design to a more detailed version,
i.e., into modules which creates different functionalities. Transferring of data and
connection between internal and external modules (i.e., the outside world) is
evidently identified.
4. Low-level design or Module Design: This particular phase breaks down the entire
product development into tiny modules where each intended module is specified.
So it is also termed as Low-Level Design (LLD).

Testing Phase
1. Unit Testing: During the development of module design, unit testing is carried out.
This plan is executed for eliminating bugs that are found in code at the
development of your software.
2. Integration Testing: Once the unit testing is done, the integration testing is carried
out where the integration of modules in the system is hardened. This testing is
done in the architecture design phase.
3. System Testing: This ultimate test is done when the entire product is completed in
conjunction with the functionality, internal dependency requirement and merging
of different modules into a single unit.

140
 4. User Acceptance Testing: This type of testing is carried out in front of the user or in
a user environment where the product will ultimately set up. The UAT particularly
test whether the product is capable enough to launch in the market or ready to
work in the real world.

1.5 Test planning and Design :

Test Planning :

• The test planning stage represents the need to review long–lead-time test planning
activities. During this phase, the test team identifies test procedure creation
standards and guidelines; hardware, software, and network required to support
test environment; test data requirements; a preliminary test schedule;
performance measure requirements; a procedure to control test configuration and
environment; as well as defect-tracking procedure(s) and associated tracking
tool(s).

• The test plan contains the results of each preliminary phase of the structured test
methodology (ATLM). The test plan will define roles and responsibilities, project
test schedule, test planning and design activities, test environment preparation,
test risks and contingencies, and acceptable level of thoroughness (test acceptance
criteria). Test plan appendices may include test procedures, naming conventions,
test procedure format standards, and a test procedure traceability matrix.

• The test environment setup is part of test planning. It represents the need to plan,
track, and manage test environment setup activities, where material procurements
may have long lead times. The test team needs to schedule and track environment
setup activities; install test environment hardware, software, and network

141
 resources; integrate and install test environment resources; obtain/refine test
databases; and develop environment setup scripts and test bed scripts.

Test Design
• The test design component addresses the need to define the number of tests to be
performed, the ways that testing will be approached (paths, functions), and the test
conditions that need to be exercised. Test design standards need to be defined and
followed.

• An effective test program, incorporating the automation of software testing,

involves a mini-development lifecycle of its own, complete with strategy and goal
planning, test requirement definition, analysis, design, and coding. Similar to
software application development, test requirements must be specified before test
design is constructed. Test requirements need to be clearly defined and
documented, so that all project personnel will understand the basis of the test
effort. Test requirements are defined within requirement statements as an
outcome of test requirement analysis.

• After test requirements have been derived using the described techniques, test
procedure design can begin.

1.6 MONITORING AND MEASURING TEST EXECUTION

Monitoring and measurement are two key principles followed in every scientific and
engineering endeavor. The same principles are also applicable to the testing phases of
software development. It is important to monitor certain metrics which truly represent
the progress of testing and reveal the quality level of the system. Based on those metrics,
the management can trigger corrective and preventive actions. By putting a small but

142
critical set of metrics in place the executive management will be able to know whether
they are on the right track. Test execution metrics can be broadly categorized into two
classes as follows:

1. Metrics for monitoring test execution

2. Metrics for monitoring defects

The first class of metrics concerns the process of executing test cases, whereas the second
class concerns the defects found as a result of test execution. These metrics need to be
tracked and analyzed on a periodic basis, say, daily or weekly. In order to effectively
control a test project, it is important to gather valid and accurate information about the
project.

One such example is to precisely know when to trigger revert criteria for a test cycle and
initiate root cause analysis of the problems before more tests can be performed. By
triggering such a revert criteria, a test manager can effectively utilize the time of test
engineers, and possibly money, by suspending a test cycle on a product with too many
defects to carry out a meaningful system test. A management team must identify and
monitor metrics while testing is in progress so that important decisions can be made

It is important to analyze and understand the test metrics, rather than just collect data
and make decisions based on those raw data. Metrics are meaningful only if they enable
the management to make decisions which result in lower cost of production, reduced
delay in delivery, and improved quality of software systems.

Quantitative evaluation is important in every scientific and engineering field. Quantitative

evaluation is carried out through measurement. Measurement lets one evaluate
parameters of interest in a quantitative manner as follows:

143
 • Evaluate the effectiveness of a technique used in performing a task. One can
evaluate the effectiveness of a test generation technique by counting the number
of defects detected by test cases generated by following the technique and those
detected by test cases generated by other means.

• Evaluate the productivity of the development activities. One can keep track of
productivity by counting the number of test cases designed per day, the number of
test cases executed per day, and so on.

• Evaluate the quality of the product. By monitoring the number of defects detected
per week of testing, one can observe the quality level of the system.

• Evaluate the product testing. For evaluating a product testing process, the following
two measurements are critical:

Test case effectiveness metric:

The objective of this metric is twofold as explained in what follows:

(1) measure the “defect revealing ability” of the test suite and

(2) use the metric to improve the test design process. During the unit, integration, and
system testing phases, faults are revealed by executing the planned test cases. In addition
to these faults, new faults are also found during a testing phase for which no test cases
had been designed. For these new faults, new test cases are added to the test suite.
Those new test cases are called test case escaped (TCE). Test escapes occur because of

144
deficiencies in test design. The need for more testing occurs as test engineers get new
ideas while executing the planned test cases.

Test effort effectiveness metric:

It is important to evaluate the effective-ness of the testing effort in the development of a
product. After a product is deployed at the customer’s site, one is interested to know the
effectiveness of testing that was performed. A common measure of test effectiveness is
the number of defects found by the customers that were not found by the test engineers
prior to the release of the product. These defects had escaped our test effort.

1.7 TEST TOOLS AND AUTOMATION

• In general, software testing is a highly labor intensive task. This is because test
cases are to a great extent manually generated and often manually executed.
Moreover, the results of test executions are manually analyzed. The durations of
those tasks can be shortened by using appropriate tools. A test engineer can use a
variety of tools, such as a static code analyzer , a test data generator , and a
network analyzer , if a network-based application or protocol is under test. Those
tools are useful in increasing the efficiency and effectiveness of testing.

• Test automation is essential for any testing and quality assurance division of an
organization to move forward to become more efficient. The benefits of test
automation are as follows:

➢ Increased productivity of the testers

➢ Better coverage of regression testing

145
 ➢ Reduced durations of the testing phases
➢ Reduced cost of software maintenance
➢ Increased effectiveness of test cases

• Test automation provides an opportunity to improve the skills of the test engineers
by writing programs, and hence their morale. They will be more focused on
developing automated test cases to avoid being a bottleneck in product delivery to
the market. Consequently, software testing becomes less of a tedious job.

• Test automation improves the coverage of regression testing because of

accumulation of automated test cases over time. Automation allows an
organization to create a rich library of reusable test cases and facilitates the
execution of a consistent set of test cases. Here consistency means our ability to
produce repeated results for the same set of tests. It may be very difficult to
reproduce test results in manual testing, because exact conditions at the time and
point of failure may not be precisely known. In automated testing it is easier to set
up the initial conditions of a system, thereby making it easier to reproduce test
results. Test automation simplifies the debugging work by providing a detailed,
unambiguous log of activities and intermediate test steps. This leads to a more
organized, structured, and reproducible testing approach.

• Automated execution of test cases reduces the elapsed time for testing, and, thus,
it leads to a shorter time to market. The same automated test cases can be
executed in an unsupervised manner at night, thereby efficiently utilizing the
different platforms, such as hardware and configuration. In short, automation
increases test execution efficiency. However, at the end of test execution, it is
important to analyze the test results to determine the number of test cases that
passed or failed. And, if a test case failed, one analyzes the reasons for its failure.

146
• In the long run, test automation is cost-effective. It drastically reduces the soft-
ware maintenance cost. In the sustaining phase of a software system, the
regression tests required after each change to the system are too many. As a result,
regression testing becomes too time and labor intensive without automation.

• A repetitive type of testing is very cumbersome and expensive to perform manually,

but it can be automated easily using software tools. A simple repetitive type of
application can reveal memory leaks in a software. However, the application has to
be run for a significantly long duration, say, for weeks, to reveal memory leaks.
Therefore, manual testing may not be justified, whereas with automation it is easy
to reveal memory leaks. For example, stress testing is a prime candidate for
automation. Stress testing requires a worst-case load for an extended period of
time, which is very difficult to realize by manual means. Scalability testing is
another area that can be automated. Instead of creating a large test bed with
hundreds of equipment, one can develop a simulator to verify the scalability of the
system.

• Test automation is very attractive, but it comes with a price tag. Sufficient time and
resources need to be allocated for the development of an automated test suite.
Development of automated test cases need to be managed like a programming
project. That is, it should be done in an organized manner; otherwise it is highly
likely to fail. An automated test suite may take longer to develop because the test
suite needs to be debugged before it can be used for testing. Sufficient time and
resources need to be allocated for maintaining an automated test suite and setting
up a test environment. Moreover, every time the system is modified, the
modification must be reflected in the automated test suite. Therefore, an
automated test suite should be designed as a modular system, coordinated into
reusable libraries, and cross-referenced and traceable back to the feature being
tested.

147
• It is important to remember that test automation cannot replace manual testing.
Human creativity, variability, and observability cannot be mimicked through
automation. Automation cannot detect some problems that can be easily observed
by a human being. Automated testing does not introduce minor variations the way
a human can. Certain categories of tests, such as usability, interoperability, robust-
ness, and compatibility, are often not suited for automation. It is too difficult to
automate all the test cases; usually 50% of all the system-level test cases can be
automated. There will always be a need for some manual testing, even if all the
system-level test cases are automated.

• The objective of test automation is not to reduce the head counts in the testing
department of an organization, but to improve the productivity, quality, and
efficiency of test execution. In fact, test automation requires a larger head count in
the testing department in the first year, because the department needs to
automate the test cases and simultaneously continue the execution of manual
tests. Even after the completion of the development of a test automation
framework and test case libraries, the head count in the testing department does
not drop below its original level. The test organization needs to retain the original
team members in order to improve the quality by adding more test cases to the
automated test case repository.

• Before a test automation project can proceed, the organization must assess and
address a number of considerations. The following list of prerequisites must be
considered for an assessment of whether the organization is ready for test
automation:

o The test cases to be automated are well defined.

o Test tools and an infrastructure are in place.

148
 o The test automation professionals have prior successful experience in
automation.
o Adequate budget should have been allocated for the procurement of soft-
ware tools.

1.8 TEST TEAM ORGANIZATION AND MANAGEMENT

• Testing is a distributed activity conducted at different levels throughout the life

cycle of a software. These different levels are unit testing, integration testing,
system testing, and acceptance testing. It is logical to have different testing groups
in an organization for each level of testing. However, it is more logical — and is the
case in reality — that unit-level tests be developed and executed by the
programmers themselves rather than an independent group of unit test engineers.
The programmer who develops a software unit should take the ownership and
responsibility of producing good-quality software to his or her satisfaction.

• System integration testing is performed by the system integration test engineers.

The integration test engineers involved need to know the software modules very
well. This means that all development engineers who collectively built all the units
being integrated need to be involved in integration testing. Also, the integration
test engineers should thoroughly know the build mechanism, which is key to
integrating large systems.

• A team for performing system-level testing is truly separated from the development
team, and it usually has a separate head count and a separate budget. The mandate
of this group is to ensure that the system requirements have been met and the
system is acceptable. Members of the system test group conduct different
categories of tests, such as functionality, robustness, stress, load, scalability,
reliability, and performance. They also execute business acceptance tests identified
149
 in the user acceptance test plan to ensure that the system will eventually pass user
acceptance testing at the customer site. However, the real user acceptance testing
is executed by the client’s special user group. The user group consists of people
from different backgrounds, such as software quality assurance engineers, business
associates, and customer support engineers.

It is a common practice to create a temporary user acceptance test group consisting of

people with different backgrounds, such as integration test engineers, system test
engineers, customer support engineers, and marketing engineers. Once the user
acceptance is completed, the group is dis-mantled. It is recommended to have at least
two test groups in an organization: integration test group and system test group.

• Hiring and retaining test engineers are challenging tasks. Interview is the primary
mechanism for evaluating applicants. Interviewing is a skill that improves with
practice. It is necessary to have a recruiting process in place in order to be effective
in hiring excellent test engineers.

• In order to retain test engineers, the management must recognize the importance
of testing efforts at par with development efforts. The management should treat
the test engineers as professionals and as a part of the overall team that delivers
quality products.

150
 2. Testing Technique &
System Test Categories
2.1 Difference Between Structural and Functional Testing :

Structural Testing Functional Testing

Structural testing is done in manual mode Functional testing can be performed

eithermanually or automatically

Structural test cases are designed based Functional testing would depend on
onexternal specifications and internal bothexternal specifications and the
code structure is not considered internal workings of the component.

Structural test cases are based on Functional test cases are based on
input/outputconditions actionsthat a component can perform.

Structural testing is done after the coding Functional testing is performed

process is completed by maintenance duringdevelopment and/or
groups. maintenance.

Structural test cases do not depend on Functional test cases may have to use
datavalues. some specific value for a test case to
passor fail (error checking).

151
Structural test cases are based on Functional testing is achieved by
hardwarelevel error checking. softwaretechniques.

Structural testing involves static Functional testing involves the analysis

datastructures and algorithms. ofdynamic data structures and
object-oriented programming.

Structural testing mainly focuses on Functional testing focuses on verifying

logicalerrors or bugs in the code thatthe system meets its requirements.

Structural Test Cases are usually carried Functional test cases are designed
outby a software development group bybusiness analysts and testers.

152
2.2 Difference Between Static testing and Dynamic Testing :

Static testing Dynamic testing

In static testing, we will check the code In dynamic testing, we will the
or the application without executing the checkcode/application by
code. executing the code.
Static testing includes activities likecode Dynamic testing includes activities like
Review, Walkthrough, etc. functional and non-functional testing
such as UT (usability testing), IT
(integration testing), ST (System
testing) & UAT (user acceptance
testing).
Static testing is a Verification Process. Dynamic testing is a Validation Process.

Static testing is used to prevent Dynamic testing is used to find and fix
defects thedefects.
.
Static testing is a more cost-effective It is a less cost-effective
process. process.

This type of testing can be performed Dynamic testing can be done only
before the compilation of code. after theexecutables are prepared.

Under static testing, we can perform Equivalence Partitioning and Boundary

the statement coverage testing and Value Analysis techniques are
structural testing. performed under dynamic testing.

It involves the checklist and process This type of testing required the test
which has been followed by the test case forthe execution of the code.
engineer.

153
2.3 Black Box Testing :

The technique of testing without having any knowledge of the interior workings
of the application is Black Box testing. The tester is oblivious to the system
architecture and does not have access to the source code. Typically, when
performing a black box test, atester will interact with the system’s user interface
by providing inputs and examining outputs without knowing how and where the
inputs are worked upon.

Advantages:
● Well suited and efficient for large code segments.
● Code Access not required.
● Clearly separates the user's perspective from the developer’s perspective
through visibly defined roles.
● Large numbers of moderately skilled testers can test the application
with noknowledge of implementation, programming language or operating
systems.

Disadvantages:
● Limited Coverage since only a selected number of test scenarios are
actuallyperformed.
● Inefficient testing, due to the fact that the tester only has limited
knowledge aboutan application.
● Blind Coverage, since the tester cannot target specific code segments or
errorprone areas.
● The test cases are difficult to design.

2.4 White Box Testing :

154
White box testing is the detailed investigation of internal logic and structure of
the code. White box testing is also called glass testing or open box testing. In
order to performwhite box testing on an application, the tester needs to possess
knowledge of the internal working of the code. The tester needs to have a look
inside the source code and find out which unit/chunk of the code is behaving
inappropriately.

Advantages:
● As the tester has knowledge of the source code, it becomes very easy to
find outwhich type of data can help in testing the application effectively.
● It helps in optimizing the code.
● Extra lines of code can be removed which can bring in hidden defects.
● Due to the tester's knowledge about the code, maximum coverage is
attainedduring test scenario writing.

Disadvantages:
● Due to the fact that a skilled tester is needed to perform white box
testing, thecosts are increased.
● Sometimes it is impossible to look into every nook and corner to find
hiddenerrors that may create problems as many paths will go untested.
● It is difficult to maintain white box testing as the use of specialized tools
like codeanalyzers and debugging tools are required.

2.5 Unit Testing :

This type of testing is performed by the developers before the setup is
handed over to the testing team to formally execute the test cases. Unit
testing is performed by the respective developers on the individual units of

155
 source code assigned areas. The developers use test data that is separate
from the test data of the quality assurance team.

The goal of unit testing is to isolate each part of the program and show
that individual parts are correct in terms of requirements and functionality.

● Limitations of Unit Testing :

Testing cannot catch each and every bug in an application. It is impossible

to evaluate every execution path in every software application. The same
is the case with unit testing. There is a limit to the number of scenarios and
test data that the developer can use to verify the source code. So after he
has exhausted all options there is no choice but to stop unit testing and
merge the code segment with other units.

2.6 Integration Testing:

The testing of combined parts of an application to determine if they

function correctly together is Integration testing. There are two methods
of doing Integration Testing : Bottom-up Integration testing and Top Down
Integration testing.

Bottom-up integration testing begins with unit testing, followed by tests of

progressively higher-level combinations of units called modules or builds.

156
Top-Down integration testing, the highest-level modules are tested
first and progressively lower-level modules are tested after that. In a
comprehensive software development environment, bottom-up
testing is usually done first, followed by top-down testing.

2.7 System Testing:

This is the next level in the testing and tests the system as a whole.
Once all the components are integrated, the application as a whole
is tested rigorously to see that it meets Quality Standards. This type
of testing is performed by a specialized testing team.

Why is System Testing so Important :

● System Testing is the first step in the Software Development
Life Cycle, wherethe application is tested as a whole.
● The application is tested thoroughly to verify that it meets
the functional andtechnical specifications.
● The application is tested in an environment which is very close
to the productionenvironment where the application will be
deployed.
● System Testing enables us to test, verify and validate both
the businessrequirements as well as the Applications
Architecture.

2.8 Data Flow Testing :

157
 Data flow testing is a family of test strategies based on selecting paths
through the program's control flow in order to explore sequences of
events related to the status of variables or data objects. Data flow Testing
focuses on the points at which variables receive values and the points at
which these values are used.

➢ Advantages of Data Flow Testing:

Data Flow testing helps us to pinpoint any of the following issues:
3 A variable that is declared but never used within the program.
4 A variable that is used but never declared.
5 A variable that is defined multiple times before it is used.
6 Deallocating a variable before it is used.

2.9 Control Flow Testing :

Control flow testing is a testing technique that comes under white box
testing. The aim of this technique is to determine the execution order of
statements or instructions of the program through a control structure. The
control structure of a program is used to develop a test case for the
program. In this technique, a particular part of a large program is selected
by the tester to set the testing path. It is mostly used in unit testing. Test
cases represented by the control graph of the program.

2.10 System Test Categories :

• Basic Test :
Provide an evidence that the system can be installed, configured and be
brought to an operational state

158
• Robustness Test :
Determine how well the system recovers from various input errors and
other failure situations

• Interoperability tests :
Determine whether the system can interoperate with other third party products

• Functionality Testing
This testing makes sure that the functionality of a product is working as
per the requirements specification, within the capabilities of the system.

Functional testing is done manually or with automated tools.

• Performance Testing
This testing makes sure the system’s performance under various conditions, in
terms ofperformance characteristics.

This testing is also called compliance testing with respect to

performance.This testing ensures that meets the system
requirements

It checks when multiple users use the same app at a time, then how it responds
back

Performance testing can be categorized into three main categories like

speed,scalability, stability.

• Scalability Testing

159
 This testing makes sure the system’s scaling abilities in various terms like user
scaling,geographic scaling, and resource scaling.

• Reliability Testing
Reliability testing makes sure that the system is bug-free.

This testing makes sure the system can be operated for a longer duration
without developing failures.

• Documentation Testing
This testing makes sure that the system’s user guide and other help
topics documentsare correct and usable.

• Load Testing
This testing determines, how the application behaves when multiple users
access itsimultaneously across multiple locations.

This testing is done to determine if the system performance is

acceptable at apre-determined load level.

Load testing evaluates system performance with the

predefined load levels.It checks the normal and predefined
conditions of the application.

• Stress Testing
This testing generally checks if the system is going to continue to
function whensubjected to a larger volume of data than expected.

Stress testing may contain input transactions, internal tables,

communication channels,disk space, etc.
160
 Stress testing checks that the system should run as it would in a
productionenvironment.

It checks the system under extreme conditions.

Stress Testing is also known as Endurance Testing.

• Regression Testing:
involves testing done to make sure none of the changes made over the
course of the development process have caused new bugs. It also makes
sure no old bugs appear from the addition of new software modules over
time.

• Functional Testing:
It is Also known as functional completeness testing, Functional Testing
involves trying to think of any possible missing functions. Testers might
make a list of additional functionalities that a product could have to
improve during functional testing.

161
3. System Test Planning and Automation

3.1 Structure of a System Test Plan :

The testing process : A description of the major phases of the system testing
process. This may be broken down into the testing of individual sub-systems, the
testing of external system interfaces, etc.

Requirements traceability : Users are most interested in the system meeting its
requirements and testing should be planned so that all requirements are
individually tested.

Tested items :The products of the software process that are to be tested should be
specified.

Testing schedule : An overall testing schedule and resource allocation. This

schedule should be linked to the more general project development schedule.

Test recording procedures : It is not enough simply to run tests; the results of the
tests must be systematically recorded. It must be possible to audit the testing
process to check that it has been carried out correctly.

Hardware and software requirements : This section should set out the software
tools required and estimated hardware utilisation.

162
Constraints : Constraints affecting the testing process such as staff shortages should
be anticipated in this section.

System tests : This section, which may be completely separate from the test plan,
defines the test cases that should be applied to the system. These tests arederived
from the system requirements specification.

3.2 SYSTEM TEST AUTOMATION

It is absolutely necessary for any testing organization to move forward to become

more efficient, in particular in the direction of test automation. It is important to
think about automation as a strategic business activity. A strategic activity requires
senior management support; otherwise it will most likely fail due to lack of funding.
It should be aligned with the business mission and goals and a desire to speed up
delivery of the system to the market without compromising quality. However,
automation is a long-term investment; it is an on-going process. It cannot be
achieved overnight; expectation need to be managed to ensure that it is realistically
achievable within a certain time period.

The organization must assess and address a number of considerations before test
automation can proceed. The following prerequisites need to be considered for an
assessment of whether or not the organization is ready for test automation:

• The system is stable and its functionalities are well defined.

• The test cases to be automated are unambiguous.

163
 • The test tools and infrastructure are in place.
• The test automation professionals have prior successful experience with
automation.
• Adequate budget has been allocated for the procurement of software tools.

The system must be stable enough for automation to be meaningful. If the system is
constantly changing or frequently crashing, the maintenance cost of the automated
test suite will be rather high to keep the test cases up to date with the system. Test
automation will not succeed unless detailed test procedures are in place. It is very
difficult to automate a test case which is not well defined to be manually executed.
If the tests are executed in an ad hoc manner without developing the test
objectives, detailed test procedure, and pass – fail criteria, then they are not ready
for automation.

The test engineers should have significant programming experience. It is not

possible to automate tests without using programming languages, such as Tcl (Tool
command language), C, Perl, Python, Java, and Expect. It takes months to learn a
programming language. The development of an automation process will fail if the
testers do not have the necessary programming skills or are reluctant to develop it.
Adding temporary contractors to the test team in order to automate test cases may
not work. The contractors may assist in developing test libraries but will not be able
to maintain an automated test suite on an on-going basis.

Adequate budget should be available to purchase and maintain new software and
hardware tools to be used in test automation. The organization should keep aside
funds to train the staff with new software and hardware tools. Skilled professionals
with good automation background may need to be added to the test team in order
to carry out the test automation project. Therefore, additional head count should
be budgeted by the senior executive of the organization.
164
3.3 Automated Software Testing

Automated Testing Software is the methodology that helps to validate the

functioning of the software before it is moved to production. In this process,
automated testing tools are used by the QA teams for executing the test scripts.

With the use of automated software testing tools, QA teams can quickly test the
software, prepare the defect reports, and compare the software results with the
expected results. Also, this automated testing process provides several benefits
such as faster delivery, eases regression testing time and also ensures quality
software along with reducing manual testing efforts.

Thus, the QA teams can function faster and help to push the software to production
quickly as per the given timelines as automated testing ensures faster and quality
releases leveraging automated testing tools.

3.4 What are the skills needed for an automation tester?

i. Focus on analytical thinking :
• For an automation tester, an instinct for analytics and logical application of
concepts is important. Once the business team provides the business
requirement document, the automation testing team should focus on
understanding every aspect of the feature very well from an automation
perspective.

165
 • The automation testers should raise queries in the agile refinement
ceremonies to bridge any gap that can be a prerequisite in automating a
certain functionality of an application.

• The automation testing team needs to think and identify areas of the
functionality which can or cannot be automated and define a detailed
automation test strategy. The testing team should plan a walkthrough session
with all the stakeholders specifically to discuss the automation testing
approach for a feature

• Automation testing teams should collect ideas from all the team members
and use the same to formulate the test plan document. In the test plan
document define the scope of testing, automation testing approach,
execution timelines, etc. Analyze how the test cases can be automated as per
the priority.

• The automation testing team can plan internal training sessions to discuss the
automation testing approach. Also, the resources can share knowledge on
certain automation tools that can be best utilized for the current project.

• The testing team can discuss the estimation effort for automating each
module of the software. This includes test designing as well as execution
effort. Critical thinking is important to properly test software, write
automated tests to cover defects in the software.

ii. Understanding of programming languages :

166
 • To be a successful automation tester, the tester should have a good
understanding of programming languages.

• Mostly the automated test tools use programming languages like Java,
Python, Perl, Vb script, etc. The automation tester needs to be proficient in
these programming languages. The thought process of the automation tester
should be to identify and cover all the possible modules that demand
automation.

• The automation tester must have good coding skills in order to design the
test scripts. Self-learning is a good way to get acquainted with these
programming languages that can help in designing the automated test
scripts.

• Though it is not required today that you code your automated scripts
with scriptless test automation, it is good to know the basics.
• The testing team needs to ensure that the code conforms to certain
designated quality standards. Along with maintaining the overall quality of
the software, it is indeed essential to design easy to understand test scripts.
Such that they can be understood by everyone in the team at a high level.

• The team usually has an added advantage if they have an experienced

automation tester in the team. Their previous project experience can be
utilized in designing test cases and test suites.

iii. Good functional testing skills :

• To excel as an automation tester, the tester should have sound knowledge
and experience of functional testing performed manually.

167
 • It will be beneficial if the tester along with the application knowledge
also understands the domain very well. For e.g., if a wholesale banking
application requires payments domain knowledge to design automated test
scripts of any given functionality, then it will be an added advantage if the
tester along with good scripting skills also is well versed with domain-specific
knowledge.

• Automation testers should be well aware of the manual testing process and
the test techniques that are adopted in the testing phase. It can be
challenging and time-consuming for automation testers to design test scripts
without having good functional knowledge of the application. If the
automation test team has good exposure to the functionality they can
achieve good test coverage and better test accuracy.

• As manual testers are well acquainted with the STLC, Automation testers also
need to understand the STLC (Software test life cycle) very well. This is
required to know how the testing is performed at each step. This also makes
automation of the manual test cases easy.

iv. Expertise in creation of test scripts :

• In the market, there is a wide range of automation frameworks, out of which
some will expect the tester to have sufficient programming knowledge when
it comes to writing automated test scripts whereas for some tools the test
scripts are written in plain English language and do not require an
understanding of backend logic and coding.

• Most of the organizations in today’s date are using the Cucumber framework
for test automation. In cucumber, as the test scripts are designed using plain

168
 English language, sufficient knowledge on Selenium WebDriver is enough to
create the test scripts.

• Automation testers should have programming knowledge if the organizations

are dependent on automated tools like UFT (Unified functional tester) or QTP
(Quick Test Professional).

• The automation tester should develop the test cases with the aim of saving
both time and effort during the test creation as well as the test execution
process. An automation tester should have a good grasp of programming
languages like Java, Python, Ruby, Perl, Vb script which are widely used, these
days, in most of the automated test tools.
• For a web-based application, the automation tester should be able to develop
efficient test scripts for functionalities such as submitting a form, to generate
a popup, to upload a file, etc. Estimating the complexity of an application, an
automation tester should be able to create test scripts for a small as well as
large module in the application.

• Much before designing the test scripts the automation tester should question
in the agile refinement sessions if there’s any unclarity on any requirement or
functionality. This is the base step before creating the test scripts. Once the
tester has better insight into the application, it becomes easier to create test
scripts as well.

v. Possess good knowledge on Automated testing tools:

• The automation testers should be well-equipped with ample knowledge
about the automated testing tools present in the market that eventually help
to optimize the overall testing process.

169
 • There is a wide range of automated testing tools available in the market that
provide extremely superior benefits to an enterprise. To excel in the
automation testing field, the tester should have good understanding and
exposure of the automation test tools.

• Another skill that is important here is to know which tool is the right tool for
a project. Choosing a right tool ensures that the ROI on the investments
made in test automation is achieved.

• Depending on the selection of the automated testing tool, the tester should
be able to classify whether certain test cases can be automated or not.
• Once the tester is well-versed with the automated tools, he can utilize his
automation testing skills for designing the test cases that guarantee good test
coverage and speed up the test execution process.

• For any role, including the role of an automation tester, any learning
opportunity that could help you improve your skills should not be ignored.
Sooner or later, you should try to hone new skills and be able to add them to
your resume for a better job perspective. Here is an opportunity for you to
learn about the test automation tool

vi. Clear understanding of business requirements :

• An automation tester needs to have a clear understanding of the business
requirements.

• Let’s understand this with an example which all of us must have come across.
If you are unwell and you visit a doctor, the doctor while examining you, also
wants to know your medical history whether you have suffered from any kind

170
 of disease or ailment in the past. Depending on the overall past and present
medical condition he can then suggest certain medicines for recovery.

• On the same note, a skilled automation tester must know the application
inside out, both at frontend and backend level before the testing phase
begins.

• An automation tester must be familiar with :

➢ The programming language on which the application is developed.
➢ Browser or device requirement where the application is to be accessed by
the end-users.
➢ APIs or any web services connected to the application and their working.
➢ Which databases are used for storing the backend information?
➢ Working of all the modules and features in the application.
➢ Is there a need for manual testing for testing some areas in the
application?
➢ Planned test execution time by the automation tester.
➢ If there are any defects that were deferred in the last release and
expected to be fixed in this release and the overall impact of this fix on the
application.
➢ Test execution completion delivery date.
➢ Project release timelines.

vii. Well versed with agile, DevOps and continuous delivery :

171
• Automation testing demand in the market is increasing with new-age agile and
DevOps methodology replacing waterfall model.

• As agile methodology involves frequent changes, it is essential to have an

automation testing process in place for the same. Automation testers can
automate the test scripts for a module to be able to respond to frequent
customer induced requirement changes.

viii. Maintain good communication and interaction with stakeholders :

• Having good communication skills and collaboration is essential for automation
testers. This is most important before and during the testing phase as
automation testers have to interact with developers, business analysts, feature
engineers (possessing excellent domain-specific knowledge) and all other
stakeholders.

• In the agile refinement sessions, the automation testers can formulate open
questions to be raised in front of all the stakeholders to get better clarity on the
requirements.

• Also, once the automated test scripts are designed, the automation testers need
to give a walkthrough to the developers, business and all other stakeholders.

• During the test execution process, if any defect retest fails, the testers apart
from raising the defect on a specific tool can also communicate the same to the
developers in the daily stand up meeting. Sometimes, environmental issues may
appear that could block the testing process and delay the delivery. Maintaining
good communication about these issues will avoid any end-time surprises
related to the time of delivery/release.

172
• The automation testers can interact with all the stakeholders and discuss the
overall testing progress and status in the agile scrum meetings.

ix. Curious to learn new technologies and trends :

• Being an automation tester you should be willing and curious to learn new
technologies in the area of automation.

• Considering the history of automation tools being widely used in the

organizations, earlier firms preferred using QTP (Quick Test Professional) tool for
automation testing for a web-based application whereas now Selenium
WebDriver is in huge demand.

• In the market, demand for new automated testing tools keeps on changing as
per advanced technology and the benefit it provides to the software industry.
So, be it QTP, Selenium, Testsigma or some other automated testing tool,
automation testers should keep themselves up-to-date about the latest changes
and updates in these tools.

• The automation concepts should be very clear to the automation tester so that
he is well aware of what needs to be automated, how it needs to be automated
and why it needs to be automated.

• If you are good at implementing the logic needed for automation then you can
apply the same logic in any kind of automation tool and design appropriate test
suites suitable for testing a software application.

173
x. Able to assess and mitigate the risk :
• Though test automation seems like a strategic step in the agile world, there is
always a risk associated with the test automation process.

• If there are changes in the interfaces, after the automation test scripts were
prepared, it can cause a problem during the test execution process as irrelevant
test results will be generated due to these interface changes. Similar problems
might occur in case of changes in business logic. This incurs additional cost to
support the changes, also it can involve modification of test data and impact
other test cases as well.

• There’s a risk of issues related to the environment execution. This increases the
total time taken for testing as the application is not stable throughout the
testing process. Overall increased testing time results in a delay in delivery of the
software.

• An automation tester needs to keep a mitigation plan ready for such risks
encountered during the testing phase. The testers need to monitor the test
execution process and immediately report any obnoxious application behaviour
to the developers and the stakeholders.

• Early identification of such problems helps to prevent the occurrence of such

issues and mitigates the risks.

xi. Good problem-solving skills :

• Automation tester needs to have in-depth technical knowledge of the
automated testing tools before they actually start using them.

174
• In the test execution phase, testers come across scenarios where the script is
generating some errors but the functionality of the application is working on
expected lines. On the other hand, the script could be showing success but the
application may have some real-time errors. The automation testers must have
good problem-solving skills that are required to debug these errors. These issues
mostly occur when the automation tester does not have sufficient knowledge
for configuring the test scripts.

• If you want to become a successful automation tester you need to have

proficient knowledge in configuring the tools and steps to resolve them when a
situation like false positives and false negatives arise.

xii. Good reporting skills :

• An automation tester must possess good reporting skills.
Automation testers should regularly communicate the status of the application
under test to all the stakeholders.

• The practice of regular reporting leads to better coordination of the overall test
project and also gives transparency to the project management in terms of the
test execution status, show stopper and critical bugs in the application, defect
closure status, release timelines, etc which eventually help them to make better
decisions where needed.

xiii. Excellent at time management :

• An automation tester must be excellent in time management. This helps in
increasing the overall productivity and thus meeting the delivery deadlines. The
purpose of time management should be to prioritize the tasks with respect to
the creation of automated test scripts and executing the same.
175
• The automation testing team needs to determine the sequence of tasks and plan
how the team will spend the available time. The team can divide the tasks into
smaller blocks of time. If you keep the work defined in smaller pieces it will be
better in understanding the key responsibilities and when can you have them
completed. Managing your time allows you to produce higher quality work as
well as utilize the extra time in improving the automated testing process.

xiv. Passion for automation :

• Being an automation tester, you need to keep on upgrading your skills to be able
to deliver an efficient product to the customer.

• Learning is an ever going process and also an essential factor for career growth.

• An automation tester needs to be passionate about learning new things and

thinking of new ideas to improve the automation process and take efforts and
implement it.

• This promotes automation tester’s adaptability and their ability to switch

between different environments and tools whenever the market demands it.
Automation is the key to success in the agile software development process. So
keep learning to succeed.

xv. Online Automation Testing Courses and Certifications :

• A certification always stands as an added advantage for an automation tester.
It helps to build a strong profile for an automation tester and enhance your
knowledge in terms of automation testing.
Automation testers can be termed as “Full-stack QA engineers” as their role is to
test all aspects of product quality such as functionality, performance, security,
176
 etc in combination with various technologies and test techniques to the
application under test.

• Automation testers must be multiskilled and most importantly possess a

combination of domain knowledge, technical expertise and testing skills that
allow them to quickly deliver quality software. To become a top automation
tester, the testers need to stay current on the top test automation trends. An
automation tester can develop the above-defined qualities and skills to be an
efficient gem in the software industry.

3.5 What are the Common Challenges in Automated Testing?

1. Need to maintain effective communication between teams:

For the success of test automation in agile and DevOps practices, there should be
proper and effective communication between the QA, developers and operations
teams to ensure faster releases and at the same time ensure test automation
success.

2. Critical to Select the right test automation tool:

For any automated testing to be successful, it is essential to select the right
automated testing tool based on the application under test. As there are many
open source and paid automation testing tools available, businesses can select the
tool based on the application separately for web, mobile, and for API’s testing.

3. Adopt a proper and effective testing approach:

Not only should QA choose the right test automation tool, but should also follow
test automation challenges and best practices to ensure its success. The QA team
177
should properly plan and adopt an approach that best suites agile and DevOps
methodologies where the application under test often changes during the
development cycles. Thus, a proper test automation approach if chosen ensures
successful test automation efforts.

4. Analyze tests to be automated:

It is essential for the QA to think and analyse the cases that can be automated.
Automation works the best when testers know which are the cases to automate
and which should not be automated. Moreover, it is also important that the test
cases chosen for automation should effectively represent an important portion of
user activity.

3.6 Budgeting and scheduling

The cost and schedule estimation process helps in determining number of resources
to complete all project activities. It generally involves approximation and
development of costing alternatives to plan, perform or work, deliver, or give
project. A good estimation is very much essential for keeping a project under
budget.
Two perspectives are generally required to derive project plans. These perspectives
are given below :

1. Forward-Looking :
o The Forward-Looking approach is also known as Top-Down approach.
This approach generally starts with describing and explaining various
project tasks that involve starting with project aim or end deliverable
and breaking it all down into smaller planning chunks.

178
 o Top-down budgeting also refers to a method of budgeting where
project managers prepare a high-level budget for organization.
o These project managers or senior management develops and creates a
characterization of overall size, process, environment, people, and
quality that is essential for software project. In this approach, duration
of deliverable’s is estimated.
o It generally takes less time and effort than bottom-up estimate. With
help of software cost estimation model, an estimation of overall effort
and schedule is done. The project manager generally divides estimation
of overall effort into a top-level of WBS (Work Breakdown Structure).
o They also divide schedule into major milestones dates. At this stage,
sub-project managers are simply given responsibility for decomposing
every element of WBS into lower levels with help of various allocations
of top-level, staffing profile, and, major milestones dates as
constraints.
o The main benefit of this approach is use of holistic data from earlier
projects or products, along with unmitigated risks, and scope creeps.
This also helps in reducing risk of overlooked work activities or costs.
2. Backward-Looking :
o Backward-Looking approach is also known as Bottom-up approach.
o In this approach, project team breaks requirements of clients down,
determining lowest level appropriate to develop a range of estimates,
covering overall scope of project based on available definition of task.
o Overall elements of lowest level WBS are generally explained into
detailed tasks, for which WBS element manager is responsible for
estimating budget and schedule.
o All of these estimates are joined and integrated into higher-level WBS
budgets and milestones.

179
3.7 What are the benefits of Automated Software Testing?
The benefits have been broadly classified as Application-Wise benefits and Cost-
wise benefits.

Automated Testing Application-Wise Benefits

Increases test coverage:

This method of automated software testing helps to perform a more number
automated test scripts and increases the test coverage and the scope of tests to
enhance the quality of the application. It also helps in saving time and significantly
reduces manual testing efforts.

Ensures test accuracy:

180
Manual testing involves human intervention and this may have chances for some
un-notified errors in the testing process. Manual test cycles might lead to errors,
but with automated software testing tools, there is an assurance that the testing
practice and validation of the application are performed with good accuracy as
errors are identified at every phase.

Eases regression testing time:

Performing regression testing with manual methods takes a lot of time and human
efforts which may also lead to a lot of unidentified bugs. The repetition of the same
test cases over time and again might cause disinterest amongst the testers and may
even reduce the overall testing efficiency. However, these can be resolved when
automated regression testing is practised with testing tools and manual testers get
time to be used for other quality works.

Facilitates with re-usable test scripts:

With automated software testing in use, it eases the tester’s efforts as the test
scripts can be reused with some minor changes made in the test scripts. Also, these
scripts can be used multiple times as they can be stored, and can be re-used for
repeating the tests.

Helps to Validate Complex Scenarios effectively:

Automated testing as a service is effective to validate numerous complex scenarios
as most of today’s applications are complex apps with smart and IoT connected
devices. Automated testing with various types of test automation tools eases the
testing process as the tools can be used to test irrespective of the time.

Automated Testing Cost-Wise Benefits

181
Saves Cost:
With automated app testing, enterprises can effectively save their budget as the
test cases are run at a faster speed, defects are identified early and fixed before it is
moved to production. Though the initial costs of automation are high, but when
once the automated test framework is developed, it eases the testing tasks and
remarkably saves the overall costs.

Increases ROI:
Every enterprise aims for achieving better returns from its investments. With the
development of an effective test automation framework, returns are huge as
testing is performed faster with the inbuilt features. Moreover, automation testing
delivers faster and quality results, improves the time to market and finally ensures
increased return on investment.

Saves Time:
As tests are run automatically 24×7, automated software testing helps to save time.
Moreover, with automated testing tools, manual scripts are automated and the
regression testing time will be drastically reduced. This eventually leads to saving
the delivery time of the application and largely saves a lot of manual efforts and
saves time.

3.8 How does Automated Testing work?

Any organization that wants to implement automation testing follows a testing

framework approach. The most favoured testing frameworks are keyword-driven

182
framework, data-driven framework, linear scripting framework and modular testing
framework.

To test small applications, a linear scripting framework is used, because it uses test
scripts that don’t require much planning and also do not support reusable scripts.

When it comes to a modular testing framework, a software tester develops test

scripts to perform small, independent tests in order to reduce redundancy.

Data-driven frameworks enable software testers to develop test scripts that are
able to work for multiple data sets. This framework offers wide quality coverage
with fewer tests.

Keyword-driven frameworks are worked out using table formats to define keywords
for each function and execution method. Those software testers who don’t have in-
depth knowledge of programming can use keywords to develop test scripts.

The most popular test automation tools which are open-source are Selenium 4,
Robotium and Cypress. Selenium can automate and run tests across various web
browsers and also works well with popular programming languages such as C#, Java
and Python. Robotium is best used for user acceptance, function and system tests
for android devices. End-to-end testing, integration and unit tests work perfectly
well with the Cypress tool.

3.9 Requirement for test tools

183
Test tools are an essential component of software testing, and they help to
automate the process of software testing. The requirements for test tools may vary
depending on the specific needs of the organization or the project, but some
common requirements include:

1. Functionality: The tool should provide the required functionality to support

the testing process. This may include features such as test case management,
test execution, test reporting, and defect tracking.
2. Compatibility: The tool should be compatible with the software being tested
and the testing environment. It should also be able to integrate with other
tools and technologies used in the testing process.

3. Ease of use: The tool should be easy to learn and use, with a user-friendly
interface and clear documentation.

4. Scalability: The tool should be able to handle large volumes of tests and
support the testing needs of a growing organization.

5. Flexibility: The tool should be flexible enough to support different testing

methodologies, such as agile, waterfall, or hybrid.

6. Support: The tool should come with adequate technical support, including
training, documentation, and assistance with implementation and
customization.

7. Cost: The tool should be cost-effective and provide good value for the
investment.
184
Overall, the test tool should meet the specific needs of the organization or project,
provide reliable and accurate results, and help to increase the efficiency and
effectiveness of the testing process.

3.10 Automation testing tool :

The automation testing is used to change the manual test cases into a test script
withthe help of some automation tools.

We have various types of automation testing tools available in the market. Some
of themost commonly used automation testing tools are as follows:

Selenium
Watir
QTP
Telerik Studio
Testim

185
Applitools

Selenium :
It is an open-source and most commonly used tool in automation testing. This tool
is used to test web-based applications with the help of test scripts, and these scripts
can be written in any programming language such as java, python, C#, Php, and so
on.

186
features of Selenium:
• Selenium supports only web-based applications, which means
that the application can be opened by the browser or the URL like Gmail,
Amazon, etc.
• Selenium does not support a stand-alone application, which means that the
application is not opened in the browser or URL like Notepad, MS-Word,
Calculator, etc.
• Selenium web driver is the latest tool in the selenium community that removes
allthe drawbacks of the previous tool (selenium-IDE).
• Selenium web-driver is powerful because it supports multiple programming
languages, various browsers, and different operating systems and also supports
mobile applications like iPhone, Android.

Watir :

Watir stands for web application testing in ruby which is written in the Ruby
programming language. testing in ruby. It is a web application testing tool, which is
open-source and supports cross-browser testing tool and interacts with a platform
like a human that can validate the text, click on the links and fill out the forms.

187
Features of Watir :
• It supports various browsers on different platforms like Google Chrome, Opera,
Firefox, Internet Explorer, and Safari.
• Watir is a lightweight and powerful tool.
• We can easily download the test file for the UI.
• We can take the screenshots once we are done with the testing, which helps us
to keep track of the intermediate testing.
• This tool has some inbuilt libraries, which helps to check the alerts, browser
windows, page-performance, etc.

QTP:
QTP tool is used to test functional regression test cases of the web-based
application. QTP stands for Quick Test Professional, and now it is known as Micro
Focus UFT [Unified Functional Testing]. This is very helpful for the new test engineer
because they can understand this tool in a few minutes. QTP is designed on the
scripting language like VB script to automate the application.

188
Features of QTP
• This tool support record and playback feature.
• QTP uses the scripting language to deploy the objects, and for analysis
purposes, it provides test reporting.
• Both technical and non-technical tester can use QTP.
• QTP supports multiple software development environments like Oracle, SAP,
JAVA, etc.
• With the help of QTP, we can test both desktop and web-based applications.
• In this tool, we can perform BPT (Business process testing).

Telerik Studio :

It is modern web application which support functional test automation. With the
help of this tool, we can test the load, performance, and functionality of the web
and mobile applications and also identify the cross-browser issues.

189
Features of Telerik test studio :
• Telerik test studio allows us to deliver quality products on time.
• This tool supports all types of applications, such as desktop, web, and mobile.
• This tool supports Asp.Net, AJAX, HTML, JavaScript, WPF, and Silverlightapplication
testing.
• It supports multiple browsers like Firefox, Safari, Google Chrome, and Internet
Explorer for the test execution process.
• With the help of this tool, we can do the sentence based UI validation.

Testim :

It is another automation testing tool, which can execute the test case in very little time
and run them in various web and mobile applications. This tool will help us to enhance
the extensibility and stability of our test suites. It provides the flexibility to cover the
functionalities of the platform with the help of JavaScript and HTML.

Features of Testim :
• The Test stability is very high in testim tool.
• This tool will support parallel execution.
• In this tool, we can capture the screenshots.
• This tool will automatically create the tests.
• With the help of this tool, we can perform requirements-based and parameterized
testing.
190
Applitools :

This tool is used to check the look and feel and user's feedback on the application. It
can easily incorporate with the presented test instead of creating a new analysis.

Applitools is a monitoring software, which provides visual application management and

AI-powered visual UI testing. It is an open-source tool that helps us to deliver a quality
product.

Features of Applitools :
• This tool has active user access management.
• For various devices, it allows cross-browser testing.
• It will deliver the visual test reports to the users.
• It is available on the public and dedicated cloud.

191
 4. System Test Execution
4.1 What Is Software Testing Metrics?

A Metric is a quantitative measure of the degree to which a system, system component,

or process possesses a given attribute.

Metrics can be defined as “STANDARDS OF MEASUREMENT”.

Software Metrics are used to measure the quality of the project. Simply, a Metric is a
unit used for describing an attribute. Metric is a scale for measurement.

Suppose, in general, “Kilogram” is a metric for measuring the attribute “Weight”.

Similarly, in software, “How many issues are found in a thousand lines of code?”, here
No. of issues is one measurement & No. of lines of code is another measurement.
Metric is defined from these two measurements.

4.2 What Is Software Test Measurement?

Measurement is the quantitative indication of extent, amount, dimension, capacity,

or size ofsome attribute of a product or process.

Test Measurement example: Total number of defects.

Please refer below diagram for a clear understanding of the difference between
Measurement &Metrics.

192
4.3 Types of Test Metrics :

There are three types of software testing metrics−

● Process Metrics: Process metrics define the characteristics and execution of a

project. These characteristics are essential to the improvement and
maintenance of the process in the SDLC (Software Development Life Cycle).

● Product Metrics: Product metrics define the size, design, performance,

quality, andcomplexity of a product. By using these characteristics, developers
can enhance their software development quality.

193
 ● Project Metrics: Project Metrics determine the overall quality of a project. It is
used to calculate costs, productivity, defects and estimate the resources and
deliverables of a project.

It is incredibly vital to identify the correct testing metrics for the process. Few factors
toconsider−
● Choose your target audiences wisely before preparing the metrics
● Define the goal behind designing the metrics
● Prepare metrics by considering the specific requirements of the project
● Evaluate the financial gain behind each metrics
● Pair the metrics with the project lifecycle phase that delivers optimum output

4.4 Most used Metrics

Below are the types of metrics, popularly used by developers and testers
● Defect metrics: This metric allows developers to understand the various
quality aspects of software, including functionality, performance, installation
stability, usability, compatibility, etc.

● Defects finding rate: It is used to identify the pattern of defects during a specific
time frame

● Defect severity: It enables the developer to understand how the defect is going
to impact the quality of the software.

● Defect cause: It is used to understand the root cause of the defect.

● Test Coverage: It defines how many test cases are assigned to the program. This
metric ensures the testing is conducted to its full completion. It further aids in
checking the code flow and test functionalities.

● Defect fixing time: It determines the amount of time it takes to resolve a defect

194
 ● Test case efficiency: It tells the efficiency rate of test cases in finding defects

● Schedule adherence: Its primary motive is to figure out the time difference
between theplanned schedule and the actual time of executing a schedule.

4.5 Test Metrics Life Cycle

The life cycle of test metrics consists of four stages−

Analysis: It is responsible for the identification of metrics as well as the definition.

Communicate: It helps in explaining the need and significance of metrics to

stakeholders and testing teams. It educates the testing team about the data points
that need to be captured for processing the metric.

Evaluation: It helps in capturing the needed data. It also verifies the validity of the

195
captured data and calculates the metric value.

Reports: It develops the report with an effective conclusion. It distributes the reports
to the stakeholders, developers and the testing teams.

4.6 Beta Testing

Beta testing is a type of User Acceptance Testing among the most crucial testing, which
performed before the release of the software. Beta Testing is a type of Field Test. This
testing performs at the end of the software testing life cycle. This type of testing can be
considered as external user acceptance testing. It is a type of salient testing. Real users
perform this testing. This testing executed after the alpha testing. In this the new
version, beta testing is released to a limited audience to check the accessibility,
usability, and functionality, and more.

● Beta testing is the last phase of the testing, which is carried out at the
client's orcustomer's site.

➢ Features of beta testing are:

● Beta testing used in a real environment at the user's site. Beta testing helps in

196
 providingthe actual position of the quality.

● Testing performed by the client, stakeholder, and end-user.

● Beta testing always is done after the alpha testing, and before releasing it into the
market.

● Beta testing is black-box testing.

● Beta testing performs in the absence of tester and the presence of real users

● Beta testing is performed after alpha testing and before the release of the final
product.

● Beta testing generally is done for testing software products like utilities,
operatingsystems, and applications, etc.

4.7 System Test Report :

A final summary report is created after completion of all the test cycles. The structure
of the finalreport is outlined in Table 4.1.

The introduction to the test project section of the test report summarizes the purpose
of thereport according to the test plan. This section includes the following information:

Name of the project

Name of the software image

Revision history of this
documentTerminology and
definitions

197
 Testing staff
Scope of the document
References

The summary of test results section summarizes the test results for each test
category identified in the test plan. In each test cycle, the test results are summarized
in the form of the numbers of test cases passed, failed, invalid, blocked, and untested
and the reasons for not executing some test cases. A test case may not be tested
because of several reasons, such as unavailability of equipment and difficulty in
creating the test scenario using the available test bed setup. The latter may only be
possible at a real beta testing site. For each test cycle, the following data are given in
this section:

Start and completion dates

Number of defects filed
Number of defects in different states, such as irreproducible, FAD, closed,
shelved,duplicate, postponed, assigned, and open

TABLE 4.1 Structure of Final System Test Report

Introduction to the test
projectSummary of test
results Performance
characteristics Scaling
limitations
Stability observations
Interoperability of the
system
Hardware/software compatible
matrixCompliance requirement

198
 status

4.8 Product Sustaining :

• Once
the product is shipped to one of the paying customer the software project is
moved tosustaining phase

•The goal of this phase is to maintain the software quality throughout the product’s
market life

•Software maintenance activities occur because software testing cannot uncover all
the defects ina large software system

•The following three software maintenance activities were coined by Swanson:

Corrective: The process that includes isolation and correction of one or more
defects in the software

Adaptive: The process that modifies the software to properly interface with a
changingenvironment such as new version of hardware or third party software

Perfective: The process that improves the software by the addition of new
functionalities,enhancements, and/or modifications to the existing functions

•The first major task is to determine the type of maintenance task to be conducted
when a defect report comes in from a customer

•The sustaining team, which include developers and testers are assigned immediately
to work on the defect

•If the defect reported by the customer is considered as corrective in nature

–The status of the progress is updated to the customer within 24 hours

–The group continues to work until a patch with the fix is released to the customer

•If the defect reported is considered as either adaptive or perfective in nature

199
–it is entered in the requirement database, and it goes though the usual software
development phases

➢ The major tasks of sustaining test engineers are as follows:

•Interact with customer to understand their real environment

•Reproduce the issues observed by the customer in the laboratory environment

•Once the root cause of the problem is known, develop new test cases to verify it

•Develop upgrade/downgrade test cases from the old image to the new patch image

•Participate in the code review process

•Select a subset of regression tests from the existing pool of test cases to ensure that
there is no side effect because of the fix

•Execute the selected test cases

•Review the release notes for correctness

•Conduct experiments to evaluate test effectiveness

4.9 Measuring Test Effectiveness :

Test Effectiveness can be defined as how effectively testing is done or goal is achieved
that meets the customer requirement. In SDLC (Software development Life Cycle), we
have requirements gathering phase where SRS (Software Requirements Specification)
and FRD (Functional Requirements Document) are prepared and based on that
development team starts building the software application, at the same time test
cases are carved out of SRS and FRD documents by the testing team. Test
effectiveness starts right at the beginning of the development and execution of test
cases and after development is completed to count the number of defects. Defects can
be valid or invalid. Valid defects are required to be fixed in the application or product
and invalid ones need to be closed or ignored. Thus, mathematically it is calculated as
a percentage of a number of valid defects fixed in software application divided by the
200
sum of a total number of defects injected and a total number of defects escaped.

Test Effectiveness Formula:

Test Effectiveness = ((Defects removed in a phase) / (Defect injected + Defect escaped))

* 100

4.10 Test reporting :

Test Report is a document which contains a summary of all test activities and final
test results ofa testing project. Test report is an assessment of how well the Testing is
performed. Based on the test report, stakeholders can evaluate the quality of the
tested product and make a decision on the software release.

For example, if the test report informs that there are many defects remaining in the
product, stakeholders can delay the release until all the defects are fixed.

201
 5. Acceptance Testing

5.1 Acceptance Testing :

The main goal behind acceptance testing is to check whether the developed
software productpasses the acceptance norms defined on the basis of user and
business requirements, so as todeclare it acceptable or non-acceptable for its use
by the users. Acceptance testing is one of the last types of software testing
performed over a software or application. It is conducted bya pool of targeted
users to ensure the readiness and quality of the system from user's perspective,
which allows the team to meet their needs and expectations.

5.2 Acceptance testing criteria:

● Correctness and completeness of the functionality.

● Data integrity and data conversion.
● Software usability, performance and scalability.
● Documentation.
● Timeliness.
● Product’s confidentiality and availability.
● Install-ability as well as upgrade-ability.

5.3 Types of Acceptance Testing

Alpha Testing :
● Alpha testing is the form of acceptance testing that takes place at the
developer’ssite.
● It can be carried out by both in-house developers and QAs as well as
potentialend-users as well.
● Alpha testing is not open to the world.

202
 ● These tests can also be white box along with black-box tests.

Beta Testing :

● Beta testing is the form of acceptance testing that takes place at the
customer’s orthe end user’s site.
● It is performed after alpha testing and in the real-world environment
without thepresence or control of developers.
● Beta tests or the beta version of the application are normally open to
the wholeworld (or client).
● These tests are only black-box.

Along with Alpha and beta testing, we can also classify acceptance testing into the
following different types-

➢ User Acceptance Testing – In user acceptance testing, a developed application

is assessed from the end-users’ perspective, whether it is working for the end-
users or not as per the requirements. It is done by employees of the developer
organization only. It is also known as ‘End User Testing’ and follows a black box
testing mode.

➢ Business Acceptance Testing – Business acceptance testing assesses the

developedapplication from the perspective of business goals and processes. It is
to make sure the system is ready for the operational challenges and needs of the
real world. It is a superset of user acceptance testing. BAT is performed by an
independent testing team. Every member of the team should have precise
knowledge of the client’s domain and business.

➢ Contract Acceptance Testing – This type of testing involves checking the

developed system against pre-defined criteria or specifications in the contract.

203
 The contract would have been signed by the client and the development party.

➢ Regulations Acceptance Testing – Regulations Acceptance testing is also

known as Compliance acceptance testing. It checks whether the system complies
with the rules and regulations of the country where the software will be released.
Usually, a product or application that is being released internationally, will
require such testing as different countries have different rules and laws.

➢ Operational Acceptance Testing – It is non-functional testing. It makes sure

that the application is ready operationally. Operational acceptance testing
involves testing the backup or restore facilities, user manuals, maintenance
tasks, and security checks.

5.4 Importance of Acceptance Testing :

Before acceptance testing, the application has been tested by the QA team i.e. Internal
testing team. The QA team will test, and developers will develop the application based
on the requirement documents given to them.

They may have their own understanding of the requirements due to a lack of domain
knowledge. It is possible that their understanding is different from that of business
users. During acceptance testing, business users have a chance to check if everything
matches their expectations.

During acceptance testing, business users (clients) get to see the final product. Users
can check whether the system works according to the given requirements. UAT
also ensures that the requirements have been communicated and implemented
effectively. Business users can gain confidence in showing the application in the
market i.e. to the end-users.

As acceptance testing will be done by users from the business side, they will have more
ideas of what end-users want. Thus, feedback/ suggestions given during acceptance

204
testing can be helpful in the next releases. The development team can avoid the same
mistakes in future releases.

Also, an application may have some major or critical issues, such issues should be
identified during testing not when the system is LIVE. These issues can be resolved
before the code goes to the production environment. This will reduce the efforts and
time of developers.

5.5 Use of Acceptance Testing:

● To find the defects missed during the functional testing phase.

● How well the product is developed.

● A product is what the customers actually need.

● Feedbacks help in improving the product performance and user experience.

● Minimize or eliminate the issues arising from the production.

5.6 Selection of Acceptance Criteria

Acceptance criteria are a set of conditions that a product or service must meet in order
to be considered acceptable or satisfactory to the customer or end user. Here are some
steps to follow in selecting acceptance criteria:
1. Understand the user's needs: To create effective acceptance criteria, it's
important to have a clear understanding of the user's needs and expectations. This
involves conducting user research and gathering feedback from stakeholders to
ensure that the acceptance criteria are aligned with the user's requirements.

2. Prioritize key features: Identify the key features that are critical to the success of
the product or service. This will help you to focus on the most important aspects

205
 of the product or service and ensure that the acceptance criteria reflect these
priorities.

3. Make them measurable: Acceptance criteria should be measurable and specific, so

that progress can be tracked and evaluated objectively. For example, instead of
saying "the product should be user-friendly," you could specify that "the product
should have a maximum of three steps for completing a task."

4. Consider the technical feasibility: It's important to ensure that the acceptance
criteria are technically feasible and can be implemented within the available
resources and timeline. Consult with the development team to ensure that the
criteria are realistic and achievable.

5. Review and refine: Once you have drafted the acceptance criteria, review them
carefully and refine them as needed. Seek feedback from stakeholders and the
development team to ensure that the criteria are comprehensive, realistic, and
achievable.

6. Document and communicate: Once the acceptance criteria have been finalized,
document them clearly and communicate them to all stakeholders, including the
development team, project managers, and customers. This will help to ensure that
everyone is on the same page and working towards a common goal.

5.7 Acceptance Test Execution

• Acceptance Test Execution is a phase of software testing in which a set of

predefined tests are executed on the software system to ensure that it meets the
acceptance criteria and requirements specified by the stakeholders. This phase

206
 typically occurs towards the end of the software development life cycle (SDLC)
when the software is nearing completion.

• During Acceptance Test Execution, a team of testers will conduct tests on the
software to verify that it meets the requirements specified in the user stories,
business requirements documents, or other project documentation. The tests may
be manual or automated, depending on the complexity of the software and the
available resources.

• The goal of Acceptance Test Execution is to validate that the software behaves as
expected and meets the requirements of the stakeholders. The results of these
tests are usually documented and reported to the project team and stakeholders.

• If any defects or issues are found during the Acceptance Test Execution phase,
they are documented and reported to the development team for resolution. Once
the defects are fixed, the software is re-tested to ensure that the issues have been
resolved.

• Overall, the Acceptance Test Execution phase is a critical part of software testing
as it helps ensure that the software meets the requirements and expectations of
the stakeholders and is ready for release.

5.8 Software acceptance plan :

The acceptance test plan or system test plan is based on the requirement
specifications and isrequired for a formal test environment.

Acceptance evaluates the functionality and performance of the entire application and
consists of avariety of tests like.
a) Performance Tests
b) Usability Tests
c) Stress Tests
d) Documentation Tests
207
e) Security Tests
f) Volume Tests
g) Recovery Tests etc.

Acceptance testing is a user-run test which demonstrates the applications ability to

meet theoriginal business objectives and system requirements.

208
 6. TEST MANAGEMENT
6.1 People and organizational issues in testing

Perceptions and Misconceptions about Testing:

1. Testing is not Technically Challenging
2. Testing does not provide me a career path or growth
3. I am put in Testing – What is wrong with me?
4. These folks are my Adversaries
5. Testing is what I can do in the end if I get time
6. There is no sense of Ownership in Testing
7. Testing is only Destructive

Testing is not Technically Challenging:

This argument may have been true about twenty years ago when most of the
testing was manual and products were somewhat simplistic. In the present
scenario it is not the case because of the following
• Requires a holistic understanding of the entire product rather than just a
single module
• Requires thorough understanding of multiple domains
• Specialization in languages
• Use of tools
• Opportunities for conceptualization and out of the box thinking
• Significant investments are made in testing today- sometimes a lot
more than indevelopment
• An internal test tool today could very well be one of those expensive
test automationtools of tomorrow

Testing does not provide me a career path or growth

209
 Testing is not a devil and development is not an angel. Opportunities
abound equally intesting and development

I’m put in testing- what is wrong with me?

If a person is not suitable for development, for the same or similar reason, he
or she maynot be suitable for testing either

These folks are my adversaries

Testing and Development teams should reinforce each other and not be at
loggerheads

Testing is what I can do in the end if I get time

Testing is not what happens in the end of a project – it happens throughout and
continueseven beyond a release

There is no sense of Ownership in Testing:

Testing has deliverables just as development has and hence testers should
have the samesense of ownership

Testing is only Destructive:

Testing is destructive as much it is constructive, like the two sides
of a coin

Comparison between Testing and Development Functions

• Testing is often a crunch time function
• Generally more elasticity is allowed in projects in earlier phases
• Testing functions are arguably the most difficult ones to staff
• Testing functionalities usually carry more external dependencies than
developmentfunctions

6.2 Organization Structures for Testing Teams

An appropriately designed organization structure can provide

accountability to results
210
Dimensions of organization structures
1. Organization type
2. Geographic distribution

Types of Organizations
1. Product organizations
2. Service organizations

Product organizations – produce software products and take responsibility for the
entire product Service organizations – they do not take complete responsibility for
the product. In testing context they are organizations that provide testing services
to other organizations that require them.

Geographic distribution of organization

1. Single site organization
2. Multi-site organization

Single site organization – all members are located in one

single placeMulti-site organization – the team is scattered
across multiple locations

211
 Structures in single product companies:

Structures in single product companies

Testing Team Structures for Single Product Companies:

Typical organization structures in early stages of a product

212
 In a small organization in the early stages of development, there is very little
management hierarchy and people playing the roles of manager, leads and so on
actually are also engineers who are expected to act as individual contributors as
well.

Advantages of the model adopted in small organizations

• Exploits the rear-loading nature of the testing activities
• Enables engineers to gain experience in all aspect of life style
• Is amenable to the fact that the organization mostly only has informal
processes
• Some defects may be etected early

Disadvantages
• Accountability for testing and quality reduces
• Developers do not in general like testing and hence the effectiveness of
testing suffers
• Schedule pressures generally compromise testing
• Developers may not be able to carry out the different types of tests

As the product matures and the processes evolve, a homogenous single

product organization doing both development and testing, splits into two distinct
groups, one fordevelopment and one for testing

Precautions to be take in the model are:

• Project manager should not buckle under pressure and ignore the
findings andrecommendations of the testing team
• Project manager should ensure that the development and testing teams
do not view eachother as adversaries
• The testing team must participate in the project decision making
and schedulingright from the start

213
 Organization Hierarchy
Structures for multi-product companies:

Structures for multi-product companies

The organization of test teams in multi product companies is dictated by the following
facts
1. How tightly coupled the products are in terms of technology
2. Dependence among various products
3. How synchronous are the release cycles of products
4. Customer base for each product and similarity among customer bases for
various productsOptions available for organizing testing teams for a multi-
214
 product company
• A central “test think-tank / brain trust” team, which formulates the test
strategy for theorganization.
• One test team for all the products
• Different test teams for each product
• Different test teams for different types of tests
• A hybrid of all the above methods
In order to assign the same level of importance to testing team as to development
team, the testingteam is asked to report to the CTO as a peer to the design and
development team

Advantages:
• Developing a product architecture that is testable or suitable for testing
• Testing team will have better product and technology skills
• The testing team can get a clear understanding of what design and
architecture are builtfor and plan their tests accordingly
• The technical road map for product development and test suite
development will be inbetter sync.

The testing team reporting to the CTO is made effective by following the guidelines
• The team should be small in number
• It should be a team of equals
• It should have organization wide representation
• It should have decision making and enforcing authority and not just be a
recommendingcommittee
• It should be involved in periodic reviews to ensure that the operations are
in line with thestrategy.

The two types of Organizational Structures for distributing testing teams across
multiple locationsare:
● Round the clock development / testing model
● Testing competency center model– 2 variants

Challenges in global teams:

215
 • Cultural challenges
• Work allocation challenges
• Parity across teams
• Ability to work effectively
• Dependence on communication infrastructure
• Time difference

Challenges and Issues in Testing Services Organization:

• The outsider effect and estimation of resources
• Domain expertise
• Privacy and customer isolation issues
• Apportioning hardware and software resources and costs
• Maintaining a bench

Success Factors for Testing Organizations:

• Communication and teamwork
• Bringing in customer perspective
• Providing appropriate tools and environment
• Providing periodic skills upgrades

6.3 Test Planning

A plan is a document that provides a framework or approach for achieving a

set of goals. Test planning is an essential practice for any organization that wishes
to develop a test process that is repeatable and manageable.
A plan describes what specific tasks must be accomplished, who is
responsible for each task, what tools, procedures, and techniques must be used,
how much time and effort is needed, and what resources are essential.A plan also
contains milestones.

Milestone:
Milestones are tangible events that are expected to occur at a certain time in the
project’s lifetime.Managers use them to determine project status.
216
 Essential high-level Items of test plan
1. Overall test objectives.
2. What to test (scope of the tests)?
3. Who will test?
4. How to test?
5. When to test?
6. When to stop testing?

Hierarchy of test plan

At the top of the plan hierarchy there may be a software quality
assurance plan. This plan gives an overview of all verification and validation
activities for the project, as well as details related to other quality issues such as
audits, standards, configuration control, andsupplier control. Below that in the plan
hierarchy there may be a master test plan that includes an overall description of all
execution-based testing for the software system. A master verification plan for
reviews inspections/ walkthroughs would also fit in at this level.
The master test plan itself may be a component of the overall project plan or
exist as a separate document. Depending on organizational policy, another level of
the hierarchy could contain a separate test plan for unit, integration, system, and
acceptance tests.

6.4 Test Plan Components

The basic test plan components should appear in the master test plan and in
each of the level based test plans (unit, integration, etc.) with the appropriate
amount of detail.

217
 Test Plan Identifier:
Each test plan should have a unique identifier so that it can be associated
with a specific project and become a part of the project history. The project history
and all project-related items
should be stored in a project database or come under the control of a configuration
management system. Organizational standards should describe the format for the
test plan identifier and how to specify versions, since the test plan, like all other
software items, is not written in stone and is subject to change. A mention was
made of a configuration management system. This is a tool that supports change
management.

Introduction:
In this section the test planner gives an overall description of the project, the
software system being developed or maintained, and the software items and/or
features to be tested. It is useful to include a high-level description of testing goals
and the testing approaches to be used. References to related or supporting
documents should also be included in this section, for example, organizational
policies and standards documents, the project plan, quality assurance plan, and
software configuration plan.

Items to be tested:
This is a listing of the entities to be tested and should include names,
identifiers, and version/revision numbers for each entity. The items listed could
include procedures, classes, modules, libraries, subsystems, and systems.
References to the appropriate documents where these items and their behaviours
are described such as requirements and design documents, and the user manual
should be included in this component of the test plan.

Features to be Tested:
In this component of the test plan the tester gives another view of the
entities to be tested by describing them in terms of the features they encompass.
Features may be described as distinguishing characteristics of a software component
or system.

218
 In this component of the test plan references to test design specifications for each
feature and each combination of features are identified to establish the
associations with actual test cases.

Approach :
This section of the test plan provides broad coverage of the issues to be
addressed when testing the target software. Testing activities are described. The
level of descriptive detail should be sufficient so that the major testing tasks and
task durations can be identified.

The planner should also include for each feature or combination of features,
the approach that will be taken to ensure that each is adequately tested. Tools and
techniques necessary for the tests should be included. Expectations for test
completeness and how the degree of completeness will be determined should be
described.

Constraints on testing should be also be included in this section, such as time

and budgetlimitations. The planner should also describe how the testing process
will be monitored to insure it is going according to plans. Criteria to be used for
making decisions on when to stop testing must also be included

Item Pass / Fail Criteria:

Given a test item and a test case, the tester must have a set of criteria to
decide on whether the test has been passed or failed upon execution. The master
test plan should provide ageneral description of these criteria

Suspension and Resumption Criteria:

In this section of the test plan, criteria to suspend and resume testing are
described. Inthe simplest of cases testing is suspended at the end of a working day
and resumed the following morning. For some test items this condition may not
apply and additional details need to be provided by the test planner. The test
plan should also specify conditions to suspend testing based on the effects or
criticality level of the failures/defects observed. Conditions for resuming the test

219
after there has been a suspension should also be specified. For some test items
resumption may require certain tests to be repeated.

Test Deliverables:
Execution-based testing has a set of deliverables that includes the test plan
along with itsassociated test design specifications, test procedures, and test cases.
Deliverables may also include other documents that result from testing such as test
logs, test transmittal reports, test incident reports, and a test summary report

Each organization should decide which of these documents is required for a

given project. Another test deliverable is the test harness. This is supplementary
code that is written specifically to support the test efforts, for example, module
drivers and stubs.

Testing Tasks:
In this section the test planner should identify all testing-related tasks and their
dependencies.

A Work Breakdown Structure is a hierarchical or tree like representation of

all the tasks that are required to complete a project.

High-level tasks sit at the top of the hierarchical task tree. Leaves are
detailed tasks sometimes called work packages that can be done by 1–2 people in a
short time period, typically 3–5 days. The WBS is used by project managers for
defining the tasks and work packages needed for project planning.

The Testing Environment:

The test planner describes the software and hardware needs for the testing effort. For
example, any special equipment or hardware needed such as emulators,
telecommunication equipment, or other devices should be noted. The planner
must also indicate any laboratory space containing the equipment that needs to be
reserved.

The planner also needs to specify any special software needs such as
220
coverage tools, databases, and test data generators. Security requirements for the
testing environment may also need to be described.

Responsibilities:
The staff who will be responsible for test-related tasks should be
identified.This includes personnel who will be:
• transmitting the software-under-test;
• developing test design specifications, and test cases;
• executing the tests and recording results;
• tracking and monitoring the test efforts;
• checking results;
• interacting with developers;
• managing and providing equipment;
• developing the test harnesses;
• interacting with the users/customers.
This group may include developers, testers, software quality assurance staff,
systems analysts,and customers/users.

Staffing and Training Needs:

The test planner should describe the staff and the skill levels needed to carry
out test- related responsibilities such as those listed in the section above. Any
special training required toperform a task should be noted.

Scheduling:
Task durations should be established and recorded with the aid of a task
networking tool. Test milestones should be established, recorded, and scheduled.
These milestones usually appear in the project plan as well as the test plan. They
are necessary for tracking testing effortsto ensure that actual testing is proceeding
as planned.Schedules for use of staff, tools, equipment, and laboratory space
should also be specified.
A tester will find that PERT and Gantt charts are very useful tools for these
assignments

Risks and Contingencies:

Every testing effort has risks associated with it. Testing software with a high
221
degree of criticality, complexity, or a tight delivery deadline all impose risks that
may have negative impacts on project goals. These risks should be: (i) identified, (ii)
evaluated in terms of their probability of occurrence, (iii) prioritized, and (iv)
contingency plans should be developed that can be activated if the risk occurs.
It is important for the test planner to identify test-related risks, analyse them
in terms of their probability of occurrence, and be ready with a contingency plan
when any high-priority risk- related event occurs.

Testing Costs:
The IEEE standard for test plan documentation does not include a separate
cost component in its specification of a test plan. This is the usual case for many
test plans since very often test costs are allocated in the overall project
management plan.

If the test plan is an independent document prepared by the testing group

and has a cost component, the test planner will need tools and techniques to help
estimate test costs.

Test costs that should be included in the plan are:

• costs of planning and designing the tests;
• costs of acquiring the hardware and software necessary for the tests
• costs to support the test environment;
• costs of executing the tests;
• costs of recording and analysing test results;
• tear-down costs to restore the environment.
Other costs related to testing that may be spread among several projects are the
costs of trainingthe testers and the costs of maintaining the test database.

Test cost impact items

✔ The nature of the organization; its testing maturity level, and general
maturity.
✔ The nature of the software product being developed.
✔ The scope of the test requirements.
✔ The level of tester ability.
✔ Knowledge of the project problem domain.
✔ The level of tool support and Training requirements

222
 Approvals:
The test plan(s) for a project should be reviewed by those designated by the
organization. All parties who review the plan and approve it should sign the
document. A place for signatures and dates should be provided.

6.5 Test Plan Attachments

The details needed for organizing and executing the tests, For example, what are the
required inputs, outputs, and procedural steps for each test; where will the tests be
stored for each item orfeature; will it be tested using a black box, white box, or
functional approach? are generally attached to the test plan as documents.
Test Design Specifications:
• A test design specification is a test deliverable that specifies the requirements of
the testapproach.
• It is used to identify the features covered by this design and associated tests
for thefeatures.
• The test design specification also has links to the associated test cases and test
proceduresneeded to test the features, and also describes in detail pass/fail
criteria for the features
• The test design specification helps to organize the tests and provides the
connection to theactual test inputs/outputs and test steps.
• To develop test design specifications many documents such as the requirements,
designdocuments, and user manual are useful
• A test design specification should have the following components according to the
IEEE standard
✔ Test Design Specification Identifier

✔ Features to Be Tested

✔ Approach Refinements

✔ Test Case Identification

✔ Pass/Fail Criteria Test

223
Case Specifications:
It defines the test cases required to execute the test items named in the associated test
design specification. There are several components in this document.

✔ Test Case Specification Identifier

✔ Test Items

✔ Input Specifications

✔ Output Specifications

✔ Special Environmental Needs

✔ Special Procedural Requirements

✔ IntercaseDependencies

Test Procedure Specifications:

A procedure in general is a sequence of steps required to carry out a specific task.
In this attachment to the test plan the planner specifies the steps required to execute a
set of testcases
The test procedure specification has several subcomponents. They are

✔ Test Procedure Specification Identifier

✔ Purpose

✔ Specific Requirements

✔ Procedure Steps

Steps in Procedure:
Setup: to prepare for execution of the procedure
Start: to begin execution of the procedure

Proceed: to continue the execution of the procedure

224
Measure: to describe how test measurements related to outputs will be made

Shut down: to describe actions needed to suspend the test when unexpectedevents
occur

Restart: to describe restart points and actions needed to restart the procedurefrom
these points

Stop: to describe actions needed to bring the procedure to an orderly halt

Wrap up: to describe actions necessary to restore the environment

Contingencies: plans for handling anomalous events if they occur duringexecution of this
procedure.

Locating Test Items: Test Item Transmittal Report

Suppose a tester is ready to run tests on an item on the date described in the test plan.
She needs to be able to locate the item and have knowledge of its current status. This is
the function of the Test Item Transmittal Report. This document is not a component of
the test plan,but is necessary to locate and track the items that are submitted for test.
Each Test Item Transmittal Report has a unique identifier.

It should contain the following information for each item that is tracked
(i) version/revision number of the item;
(ii) location of the item;
(iii) persons responsible for the item (e.g., the developer);
(iv) references to item documentation and the test plan it is related to;
(v) status of the item;
(vi) approvals—space for signatures of staff who approve the transmittal.
225
6.6 Test Management
Test management, process of managing the tests. A test management is also
performed using tools to manage both types of tests, automated and manual, that
have been previously specified by a test procedure.
Test management tools allow automatic generation of the requirement test
matrix (RTM), which is an indication of functional coverage of the application under
test (SUT).
Test Management tool often has multifunctional capabilities such as test ware
management, test scheduling, the logging of results, test tracking, incident
management and test reporting.

Test Management Structure

Test Management Responsibilities:

● Test Management has a clear set of roles and responsibilities for

improving the qualityof the product.
● Test management helps the development and maintenance of product
metrics during thecourse of project.
● Test management enables developers to make sure that there are fewer
design or codingfaults.

226
 6.7 Testing process
The general testing process is the creation of a test strategy (which
sometimes includes the creation of test cases), creation of a test plan/design
(which usually includes test cases and test procedures) and the execution of
tests. Test data are inputs that have been devised to test the system Test
Cases are inputs and outputs specification plus a statement of the function
under thetest.
The stages in the testing process are as follows:
1. Unit testing: (Code Oriented)
2. Module testing
3. Sub-system testing: (Integration Testing) (Design Oriented)
4. System testing
5. Acceptance testing

Stages of testing phase

98
 Reporting Test Results
The test plan and its attachments are test-related documents that
are prepared prior totest execution. There are additional documents related
to testing that are prepared during and after execution of the tests.
The IEEE Standard for Software Test Documentation describes the following
documents
✔ Test Log

✔ Test Incident Report

✔ Test SummaryReport
Test Log:
The test log should be prepared by the person executing the tests. It is
a diary of the events that take place during the test. It supports the concept
of a test as a repeatable experiment. The test log is invaluable for use in
defect repair. It gives the developer a snapshot of the events associated
with a failure. The test log, in combination with the test incident report
which should be generated in case of anomalous behaviour, gives valuable
clues to the developer whose task it is to locate the source of the problem

The test log is valuable for

(i) regression testing that takes place in the development of future
releases of a software product, and
(ii) circumstances where code from a reuse
library is to be reused The test log can have many
formats. It has the following sections
• Test Log Identifier
• Description
• Activity and Event Entries

99
Activity and Event Entries include the following
1. Execution description
2. Procedure results
3. Environmental information
4. Anomalous events and Incident report identifiers

Test Incident Report:

The tester should record in a test incident report (sometimes called
a problem report) any event that occurs during the execution of the tests
that is unexpected, unexplainable, and that requires a follow-up
investigation. It includes
1. Test Incident Report identifier
2. Summary
3. Incident description
4. Impact

Test Summary Report:

This report is prepared when testing is complete. It is a summary of
the results of the testing efforts. It also becomes a part of the project’s
historical database and provides a basis for lessons learned as applied to
future projects. When a project post-mortem is conducted, the Test
Summary Report can help managers, testers, developers, and SQA staff to
evaluate the effectiveness of the testing efforts.
Test Summary Report Includes the following
1. Test Summary Report identifier
2. Variances
3. Comprehensiveness assessment

100
 4. Summary of results
5. Evaluation
6. Summary of activities
7. Approvals

Relationships between all the test-related documents:

The role of three groups in Test Planning and Policy Development

101
 In the TMM framework three groups were identified as critical players
in the testing process. They all work together toward the evolution of a
quality testing process. These groups were managers, developers/ testers,
and users/clients. In TMM terminology they are called the three critical
views (CV). Each group views the testing process from a different
perspective thatis related to their particular goals, needs, and requirements.

• The manager’s view involves commitment and support for those

activities and tasks related to improving testing process quality.
• The developer/tester’s view encompasses the technical activities
and tasks that when applied, constitute best testing practices.
• The user/client view is defined as a cooperating or
supporting view. Reaching TMM level 2: summary of
critical group roles

102
 Summary of critical group roles
For the TMM maturity goal, “Develop Testing and Debugging Goals,” the
TMM recommendsthat Project and Upper Management:
• Provide access to existing organizational goal/policy
statements and sample testingpolicies
• Provide adequate resources and funding to form the committees
(team or task force) ontesting and debugging
• Support the recommendations and policies of the committee by:

✔ distributing testing/debugging goal/policy

documents to project managers, developers, and other

103
 interested staff,

✔ appointing a permanent team to oversee compliance and policy

change making.

• Ensure that the necessary training, education, and tools to carry out
defined testing/debugging goals is made available
• Assign responsibilities for testing
and debugging.

Developers:
Developers have an important role in the development of testing goals and
policies. They serve as members of the goal/policy development teams. As
representatives of the technical staff they must ensure that the policies
reflect best testing practices, are implementable, receive management
support, and support among technical personnel.
The activities, tasks, and responsibilities for the developers/testers include
• Working with management to develop testing and debugging
policies and goals.
• Participating in the teams that oversee policy compliance and
change management.
• Familiarizing themselves with the approved set of
testing/debugging goals and policies, keeping up-to-date with
revisions, and making suggestions for changes whenappropriate.
• When developing test plans, setting testing goals for each
project at each level of test that reflect organizational testing goals
and policies.
• Carrying out testing activities that are in compliance
with organizationalpolicies.

104
 Users and Clients:
Users and clients play an indirect role in the formation of an
organization’s testing goalsand polices since these goals and policies reflect
the organizations efforts to ensure customer/client/user satisfaction.
Feedback from these groups and from the marketplace in general has an
influence on the nature of organizational testing goals and policies.
Successful organizations are sensitive to customer/client/user needs.

For the the second management-oriented maturity goal at TMM level

2 “Initiate a Test Planning Process,” input from the three critical Groups are
required
Upper management supports this goal by:
• Establishing an organization wide test planning committee with
funding.
• Ensuring that the testing policy statement and quality standards
support test planning with commitment of resources, tools,
templates, and training.
• Ensuring that the testing policy statement contains a formal
mechanism for user input to the test planning process, especially for
acceptance and usability testing.
• Ensuring that all projects are in compliance with the test planning
policy.
• Ensuring that all developers/testers complete all the necessary
post-test documents suchas test logs and test incident reports.
Project managers support the test planning maturity goal by preparing
the test plans for eachproject with inputs and support from developers.

Developers:
Developers who are experienced in testing support this maturity goal
by participating in test planning. They assist the project manager in

105
determining test goals, selecting test methods, procedures and tools, and
developing the test case specifications, test procedure specifications, and
other test-related documents Developers are also responsible for ensuring
that testability issues are addressed during the requirements and design
phases of development to support test planning and test design.

User/Client:
From the user/client point of view support for test planning is in the
form of articulating their requirements clearly, and supplying input to the
acceptance test plan. The required functional and performance-related
attributes that are expected by the client/users must be specified.
Users/clients may also participate in the development of an operational
profile which may be used to guide system and acceptance tests. They can
also participate in usability test planning

6.8 Introducing the Test Specialist

The maturity goals at TMM level 3 calls for the “Establishment of a

test organization.” This is an important step for a software organization. It
implies a commitment to better testing and higher-quality software. This
commitment requires that testing specialists be hired, space be given to
house the testing group, resources be allocated to the group, and career
paths for testers be established.
It also implies that the functional and managerial hierarchy of the
organization be redesigned, changes in the reporting structure be made, as
well as changes be made to the organizational Culture. By supporting a test
group an organization acquires leadership in areas that relate to testing and
quality issues.

106
Responsibilities of Test Specialist / Test Engineers
• maintenance and application of test policies
• development and application of test-related standards
• participating in requirements, design, and code reviews
• test planning
• test design
• test execution
• test measurement
• test monitoring (tasks, schedules, and costs)
• defect tracking, and maintaining the defect repository
• acquisition of test tools and equipment
• identifying and applying new testing techniques, tools, and
methodologies
• mentoring and training of new test personnel
• test reporting

6.9 Skills needed by a Test Specialist

Personal and Managerial level

• organizational, and planning skills
• the ability to keep track of, and pay attention to, details
• the determination to discover and solve problems
• the ability to work with others and be able to resolve conflicts
• the ability to mentor and train others
• the ability to work with users and clients
• strong written and oral communication skills
• the ability to work in a variety of environments
• the ability to think creatively

107
Technical level
• an education that includes an understanding of general software
engineering principles,practices, and methodologies;
• strong coding skills and an understanding of code structure and
behaviour;
• a good understanding of testing principles and practices;
• a good understanding of basic testing strategies, methods, and
techniques;
• the ability and experience to plan, design, and execute test cases
and test procedures onmultiple levels
• a knowledge of process issues;
• knowledge of how networks, databases, and operating systems
are organized and howthey work;
• a knowledge of configuration management;
• a knowledge of test-related documents and the role each
documents plays in the testingprocess;
• the ability to define, collect, and analyse test-related measurements;
• the ability, training, and motivation to work with testing tools and
equipment;
• a knowledge of quality issues.

6.10 Building a Testing Group

Major activities required to manage the testing process are

• organizing,
• staffing, and
• Directing

Organizing:
108
 Organizing includes selecting organizational structures, creating
positions, defining responsibilities, and delegating authority. Hiring staff for
the testing group, organizing the testing staff members into teams,
motivating the team members, and integrating the team into the overall
organizational structure

Staffing:
Staffing activities include filling positions, assimilating new
personnel, education andtraining, and staff evaluation

Directing:
Directing includes providing leadership, building teams, facilitating
communication,motivating personnel, resolving conflicts, and delegating
authority.

Step in forming a test group

Bartol and Martin’s guidelines for evaluation of employees:

109
It can be applied to any type of team and organization.
They describe four categories for employees based on their performance:
(i) retain,
(ii) likely to retain,
(iii) likely to release,
(iv) release.

For each category, appropriate actions need to be taken by the manager to

help employee and employer.

A test organization is expensive, it is a strategic commitment. Given the

complex nature of the software being built, and its impact on society,
organizations must realize that a test organization is necessary and that it
has many benefits. By investing in a test organization a company has access
to a group of specialists who have the responsibilities and motivation to:
• maintain testing policy statements
• plan the testing efforts
• monitor and track testing efforts so that they are on time and within
budget
• measure process and product attributes
• provide management with independent product and process quality
information
• design and execute tests with no duplication of effort
• automate testing
• participate in reviews to insure quality are meet.

The duties of the team members may vary in individual organizations.

The following gives a brief description of the duties for each tester that are
common to most organizations.

The Test Manager: In most organizations with a testing function, the test
110
manager (or test director) is the central person concerned with all aspects of
testing and quality issues. The test manager is usually responsible for test policy
making, customer interaction, test planning, test documentation, controlling
and monitoring of tests, training, test tool acquisition, participation in
inspections and walkthroughs, reviewing test work, the test repository, and
staffing issues such as hiring, firing, and evaluation of the test team members.
He or she is also the liaison with upper management, project management, and
the quality assurance and marketing staffs.

The Test Lead: The test lead assists the test manager and works with a
team of test engineers on individual projects. He or she may be responsible
for duties such as test planning, staff supervision, and status reporting. The
test lead also participates in test design, test execution and reporting,
technical reviews, customer interaction, and tool training.

The Test Engineer: The test engineers design, develop, and execute
tests, develop test harnesses, and set up test laboratories and
environments. They also give input to test planning and support
maintenance of the test and defect repositories.

The Junior Test Engineer: The junior test engineers are usually new
hires. They gain experience by participating in test design, test execution,
and test harness development. They may also be asked to review user
manuals and user help facilities defect and maintain the test and defect
repositories.

111