Poornima Holla

What is Risk Management?

Risk management means the actions taken to avoid things
going wrong on a software development project, things that
might negatively impact the scope, quality, timeliness, or cost
of a project.
Testing is a process designed to minimize software risks.

Responsible for Risk management

The project manager is usually the most appropriate risk

management person because he knows the entire product.

In testing, test managers responsibility to determine how

to apply the test methodology to achieve the greatest level

of confidence in the application under development.
It is recommended that brainstorming sessions are held at

the start of the project with all the members of the project
team to identify all the risks.

Why to manage risk and what are the

benefits?
Risk Management enables risks to be identified and mitigated or
eliminated before they become problems.
Any project is subject to risks.
Risk Management will assist projects to become more successful. By
completing all the components in the two stages of Risk Management,
The management, the project team and the business users may have
increased confidence that:
The project will be delivered successfully;

Surprises will be kept to a minimum;

Risks will be effectively managed and mitigated in a timely manner.

Benefits:
Projects that utilize Risk Management to manage their risks are more
likely to receive benefits such as:
adherence to user requirements;
higher quality deliverables;
maintenance of project schedules;

prevention of schedule slippage;

Reduction of project costs.
Acceleration in project completion

Risk management in testing

Risk analysis is one of the task in the test planning activity.
The test manager is responsible for identification of potential risks that

might impact testing.

The objective of performing risk analysis as part of test planning is to

help allocate limited test resources to those software components that

pose the greatest risk to the organization.
Testing is a process designed to minimize software risks. To make

software testing most effective it is important to assure all the high

risks associated with the software, will be tested first.

Stages of risk Management

There are two Stages in the process of Risk Management:
Risk Assessment
Risk Control

Risk Assessment
Risk Assessment

Risk Assessment
Risk Assessment is the first of two stages in Risk Management and
includes three main steps as follows:
Identify: Review all the project plans and identify areas of uncertainty.
Analyze: Define how the identified areas of uncertainty could effect the

performance and success of the project in terms of scope, quality, duration

and cost.

Prioritize: Prioritize the risks in terms of those risks that:

must be eliminated (resolved) completely due to their extreme impact to the
project;
are important enough to demand regular monitoring and reviewing;
are deemed to have a minor impact and will not require detailed monitoring; and
should not be totally ignored but demand less attention.

These steps are to be repeated in an iterative process until all known risks
are addressed.

What are Project Impacts?

All steps of the Risk Assessment are to be addressed in terms of the
impact to the project's scope, quality, time or budget.
Project Scope can be defined as the identified tasks and activities that
need to be performed in order to deliver the required features and
functions of a product.
Quality can be defined as accepted standard of performance or
deliverable that satisfies the expectations.
Time can be defined as the either the period of the project or the amount
of effort budgeted or assigned to each project task and activity.
Budget can be defined as the agreed or contracted amount of the project.

Risk Identification
Risk Identification consists of determining which risks are likely to affect
the project and then defining the characteristics relating to each risk.
Risk identification is not a one-time process. It should be performed on a
regular basis throughout the course of the project. Identification of risks
should be an ongoing question at each project status meeting.
Risk identification needs to address both internal and external risks.

How to identify the Risks:

Risks can be identified by utilizing the following processes:
Review known list(s) of project risk factors and sources;
Review project plans and schedules;
Review chosen technology architecture;
Review requirements;

Interview project team members;

Conduct brainstorm session(s) with project team.

It is important to note that "The project will not be completed on time" is

not a risk. It is an impact. This risk should be expressed as
Complications in completing the task # 35 may have been overlooked"

Some possible project risk areas are:

Not appointing an executive member as Project Sponsor;
Not appointing a Project Manager to the project;
Not clearly and accurately defining the project scope (requirements);
Not having a clearly defined technical environment;
Not clearly and accurately estimating project tasks and / or costs;
Not defining and forming a project team with all the appropriate skills

and roles;
The proposed technology has less functionality than promised;
The length of a project or project phase;

Possible risk in Testing

Not Enough Training/Lack of Test Competency
Us versus Them Mentality
Lack of Test Tools
Lack of Customer and User Involvement
Not Enough Schedule or Budget for Testing
Rapid Change
Testers are in A Lose-Lose Situation

Risks Analysis / Category

Before risks can be mitigated, they need to have their degree of severity
analyzed. Perform an analysis of the identified risks and categorize them
according to the likelihood of their occurrence against their impact to the
project.
This can be completed by using the four quadrant chart shown below. List
each risk and decide on the likelihood of its occurrence and identify its
impact on Scope, Quality, Time and/or Budget.

The categories from this Analysis described as:

1.

HIGH Likelihood and HIGH Impact: These are critical risks that will
have a severe impact and are more likely to occur.

2. LOW Likelihood and HIGH Impact: These are significant risks that

are not likely to occur but will have a material impact to the project if
they do.

3.

HIGH Likelihood and LOW Impact: These are significant risks that
may be able to be avoided with careful planning and monitoring.
Those that do occur however will have a low project impact which is
likely to be manageable.

4. LOW Likelihood and LOW Impact: Although these risks should still

be monitored to ensure that they do not change category, the amount

of time devoted to these should be proportionate with their likelihood
and impact.

Risks Priority
Using the risk categories, prioritize each risk for action in the order that it
is to be addressed (1 to 4).
Prioritization of risks enables the Project Manager and project team to
focus on the areas that are most likely to have the greatest impact to the
project.

Risk Control
Risk Control

Risk Control
Risk Control is the second stage in Risk Management and includes four
main steps as follows:

Risk Mitigation: Identify the necessary actions that can be carried out
in advance to reduce (or eliminate) the impact of the risk.

Risk Planning: Develop an emergency plan for dealing with significant

risks.

Risk Monitoring: Monitor and track all the risks identified and manage
them to successful resolutions.

Risk Communication: Formally document and communicate the

project risks to the project team and project decision makers.

Risk Mitigation
Risk identification, analysis and prioritization is only beneficial if actions
are defined and executed to mitigate the risk.
Risk mitigation actions must be defined individually for each risk. In
some cases, immediate action will be necessary. For other risks, future
plans and considerations will be more appropriate.
Risks can be mitigated not only by eliminating the risk but also by
reducing their degree of occurrence and/or lessen the Impact to the
project. It can be broken down into two components:

Risk Elimination
Risk Reduction

Risk Elimination:
Aggressive, proactive risk mitigation for top priority (1) risks is essential to
achieve the full benefits of Risk Management. For these critical risks it is
ideal if the risks can be eliminated entirely as they will have the greatest
negative impact to the project.
Example:
Risk: Project Sponsor has not been appointed.
Priority:1, High impact to the success of the project.
Mitigation: Appoint an executive member, with available time to devote to
the project as Project Sponsor.

By carrying out this Risk Elimination mitigating action, the risk is

completely removed from the project.

Risk Reduction:
A reduction of the degree of occurrence, or lessening of the impact, can
be attained by actions early in the project.
Example:
Risk: Lack of training for testers
Priority:2, Low Likelihood and High Impact.
Mitigation: training should be provided prior to testing.

Risk Planning
A plan of action should be prepared for each high priority risk that is not
able to be proactively eliminated. An action plan will enable the project to
recover from or survive a risk's occurrence (a problem).
A plan should be prepared for each risk, identifying:

The problem description;

The Risk Monitor, who is to be responsible for carrying out the plan and
ensuring that the project survives the problem.
The key identifiers that will announce the problem as having occurred
The activity (ies) to be performed to resolve, reduce and or eliminate
the problem;
The measurements that will announce the problem as resolved (if
known).

High priority risks are still likely to remain a High Risk. Even after being
addressed once, it may still re-occur at some time in the future
(eg: Staff leaving the project).

Risk Monitoring
Each risk that requires mitigation plan to be prepared should be assigned
to a member of the project team to monitor. The Risk Monitor will be
responsible to the Project manager for monitoring the risk, reporting any
change in condition, taking the agreed contingency action (Plan) if the
risk occurs.
Monitoring of Project Risks can be achieved by using the following
actions:

Include risk mitigation tasks in the project schedule;

Define appropriate risk milestones;
Review risk tasks regularly in project status meetings;
Perform inspections on risk status.

Risk Communication
Project decision makers and project team members are more likely to
respond to formally written information than on verbally communicated
project concerns.
A formally documented process will enable anyone involved or interested
in the project to be aware of the project risks.
It also assists the Risk Monitor's commitment to the monitoring and
mitigation of an individual risk.

Example
Sl. #

Risk Element

Wrong algorithm, too many

revisions in the requirement
specification documents, and/or
document versions not
controlled properly.

Generation of output taking

unusually long time (beyond the
time the algorithm is expected to
take).

Risk Mitigation actions

Review requirement specification
documents properly by the domain
expert, before baseline and maintain
the version control.
For every feature, make a reasonable
and realistic estimate of the time
needed to generate output. Get the
code tested for any possible bugs
(redundancies, infinite loops, lack of
or inaccurate initialization, etc.).

Sl. #

Risk Elements

Risk Mitigation actions

Check for all possible dependencies
with existing features before or
while coding. Get the code/product
tested at every stage of development
(unit, integrated, alpha, beta, etc.).

Existing feature(s) becoming

inaccessible or getting disabled
without apparent reason, on
adding a new feature.

Output format, options, dialog box

structure, menu structure, lookand-feel, etc. being inconsistent
with existing features.

Note the output format, options,

dialog box structure, command
syntax and usage, menu structure,
look-and-feel, etc. of existing
features. Adopt a style that is
common.

Key staff leaving the organization

at critical times in the project.

Assign more than one person to

work on a feature.

Sl. #

Risk Elements

Risk Mitigation actions

Tester not having knowledge of

product
Test cases are not ready

Thorough training need to be

given

Allocate test engineer in the

beginning of the project.