Software Risk Management

Share this post
FaceBook  Twitter     

  1) Introduction

 1.1 What is risk?

 Risk is the possibility of loss. It is a function of both the probability of an adverse event occurring and its impact; the impact manifests itself in a combination of financial loss, time delay, and loss of performance. A risk is the precursor to a problem; the probability that, at any given point in the software life cycle, the predicted goals cannot be achieved within available resources. Risk cannot be eliminated from a software project, but it can be managed. Risk management is critical to the success of any software effort and is a strategic aspect of all software projects.

 1.2 What is software risk management?

Software risk management is a software engineering practice with processes, methods, and tools for managing risks in a project. It provides a disciplined environment for proactive decision-making to assess continuously what can go wrong; determine what risks are important to deal with; and implement actions to deal with those risks. Risk management planning addresses the strategy for risk management, the risk management process, and the techniques, methods, and tools to be used to support the risk management process.

1.3 What is the role of management?

Senior management support and commitment is critical to the success of any risk management initiative. A formal risk management process requires corporate acceptance of risk as a major consideration for software management. Senior management must support project risk management activities by: (1) providing adequate personnel, budget, schedules, and other resources (e.g., tools and equipment); (2) ensuring project management receives the required training in identifying, managing, and communicating software risks; and (3) ensuring project personnel receive the required training in conducting risk management tasks. Senior management reviews risk management activities on a periodic and event-driven basis.


2) Software Risk Management Process

2.1 Process Model

There are several models available for risk management. Below mentioned model may be tailored to be consistent with existing site project management processes. In all phases of a project, risks should be assessed continuously and used for decision-making.

This model identifies the fundamental risk management functions that must be taken to effectively manage risk: identify, analyze, plan, track, control, and communicate.


SRM Model Functions

Process Activity Steps




Identify Risks

The SRE Team analyzes taxonomy of potential risk areas to identify a candidate list specific to the project.

Initial Risk Form


Analyze Risks

The SRE Team completes Risk Management Forms noting impact on cost, schedule, product quality, and probability and reaches a consensus on each risk

Updated Risk Form

Prioritize Risks

A Risk Level is calculated for each risk serving as the means to rank the project risks. Risk levels could be: Tolerable, Low, Medium, High , InTolerable

List of prioritized risk


Identify Risk Aversion Methods

The SRE Team performs an analysis to determine what risk aversion actions could be taken - risk avoidance, control, assumption, or transfer

Risk Management Plan

Identify Risk Mitigation Methods

The SRE Team analyzes each remaining risk and develops a mitigation action to reduce the probability and/or severity of impact of each risk event

Risk Management Plan

Identify Risk Recovery Methods

For each of the top N risks, the SRE Team documents the contingency actions and determines the trigger for invocation of a contingency action

Risk Management Plan

Define Risk Metrics

The SRE Team identifies and documents the metrics necessary to determine if a risk is being averted or mitigated

Risk Tracking Metrics

Implement Mitigation Actions

Management proactively proceeds to implement the identified risk aversion and mitigation actions.

Updated Project Plan


Track Risk

Project leads collect, analyze, and report metrics on both a periodic and event driven basis to concerned management

Active risk metrics program


Implement Contingency Actions

Activate appropriate contingency action on identification off lagged risk metric value

Updated Project Plan


2.2 Stages of Risk Management:

While managing risks associated with their projects & products a manager should follow following four stages: 

1) Risk identification;
2) Risk analysis;
3) Risk mitigation (Plan); and
4) Risk monitoring (Track & Control).

Stage – 1: Risk Identification: 

In risk identificationthe risks presented by the project & product are identified & documented for further analysis

It is the initial step of recognizing what risks are present (i.e. what unwanted events might occur). At this stage the main priority is to ensure that as many risks as possible are identified rather than analyzing any of them in any depth. The emphasis is on taking the broadest possible view and involving as many different stakeholders as possible to ensure that risk is considered from many viewpoints.

Techniques for identification are those that encourage an open mind and speculation; all ideas should be welcomed and captured. Later stages of the process will analyze and quantify the risks. 

Following six identification techniques are most commonly used for risk identification.

 a) Using Brainstorming Technique:

Brainstorming is an ideal technique for capturing ideas quickly. To be really effective a brainstorm session needs to be short and intense, while participants are in a creative mood. A conducive atmosphere is vital, and participants need to feel safe from criticism or ridicule. A facilitator should be appointed to control the activity and ensure that everyone is encouraged to contribute. During the risk brainstorm session everything suggested should be recorded (ideally on a flip chart or whiteboard, but a sheet of paper would do) without comment or analysis. The session should be kept going while ideas are flowing freely, but stopped as soon as there are gaps in the flow of ideas. Often a second session, after a little break and starting from the list generated by the first brainstorm session, can yield more ideas triggered by the initial list.

 b) Organizing Risk Workshops:

A workshop is a more structured session than a brainstorm session. The aim is to have as many different stakeholder viewpoints represented as possible. However, the generally accepted view is that a workshop is more effective with 8—12 participants. As for the brainstorm session, a facilitator should be appointed to run the workshop.

 c) Learning from the Past Lessons:

This technique capitalizes on knowledge gained from previous projects. Looking back over past projects to identify mistakes made and risks not well managed can be a powerful trigger for recognizing potential risks in a current project. In this case the technique depends on the existence of some records of past projects, in the form of post-project reviews or risk registers. If a risk analysis was done for past projects and records kept, these can be useful if there are people available who were involved or who can remember the projects. This can be a good way to at least recognize risks that were not handled effectively in the past. If there are no records this is not a suitable technique, but it might be a good idea to begin keeping enough records to allow it to be used for future projects.

 d) Conducting Interviews:

Interviews are a way to ensure that all stakeholder viewpoints are considered. More structured than a brainstorm or a workshop, an interview can ensure that every viewpoint is considered and it can also ensure that every stakeholder's input is based on a consistent set of questions. An interview is inevitably more formal than a brainstorm or a workshop, and this may become an inhibiting factor; interviewees are likely to be less spontaneous and creative than in a workshop situation. Interviews can be a very good way to follow up on brainstorms or workshops to ensure that those who made little contribution are at least heard and to follow up on any questions raised by the brainstorm or workshop. The idea of workshops or brainstorming followed by interviews suggests a fairly time-consuming and expensive approach, but it will ensure that all participants have had the opportunity to contribute.

 e) Carrying out Independent Assessment:

Independent assessment by an expert can help to ensure that all important areas are covered, but independent experts are likely to be expensive, so this is not an approach that would normally be used except where the cost is justified, for example if an organization is entering a safety critical area of application for the first time. Of course an independent assessment does not necessarily require an expert and there may be specialists within the organization who are independent of the project that could carry out an effective risk assessment. This is still a relatively expensive approach, however.

 f) Use of Checklists and Templates:

Checklists and templates are both ways to provide a starting point for the risk assessment. Checklists can be based on past experience, lessons learned or input from an expert, or they can just be copied from books or produced in a brainstorm or a workshop.

Templates, typically providing the main headings for a risk assessment document, are an alternative to checklists, or they may be used to ensure that the topics included in the checklist are included in the documentation. The main thing is that everything the organization considers important in a risk assessment is incorporated into these guidance documents. No matter how shaky the initial checklists or templates, they will improve if they are continuously updated from real project experience.



Technique for Risk Identification


When we have individuals with knowledge of the technical and business domains.

Conducting Interviews


When we have access to information from previous projects.

Learning from the Past Lessons


When we do not have sufficient in-house knowledge, and have time and budget.

Carrying out Independent Assessment


When we have knowledge to provide a starting point of key areas to consider.

Use of Checklists and Templates


When we want to reach consensus on areas of highest risk.

Organizing Risk Workshops


When we want to gain an initial idea of potential risks.

Using Brainstorming Technique


Stage – 2: Risk Analysis
The risks are analyzed to find out for their probability of occurrence & the impact they would have if they would have materialized. The product of probability & impact is the overall level of risk. This allows the risks to be ranked in order of the level of the risks.

Risk analysis is about getting more information about the risks, especially the relative risk levels of the risks identified. Risk level is defined as the product of the probability of a risk occurring and the impact of the risk if it occurred. Thus if a risk had a probability of 1/100 of occurring and its impact would be a loss to the organization of $1,000, we would define the risk level as $10.

The aim of risk analysis is, as far as possible, to quantify the risks so that they can be ranked and prioritized. The simple example given is untypical because neither the probability of occurrence nor the impact would normally be quantifiable as precisely as in the example, if at all. Nevertheless, the definition of level of risk is still useful. If precise quantification is not possible then some more qualitative measure of probability and impact can be used. Grading of both probability and impact could be as simple as Low, Medium or High. We can use a 7 x 7 Risk Analysis Matrix to record risks by level as described in the following figure.

If more is known, then finer grain estimates of probability and impact can be used. Instead of three levels for each there could be five, seven or even nine. The most important thing is that the matrix provides a basis for ranking risks and deciding on the priorities for risk mitigation.

Following figure provides an example of a matrix with seven levels and populates the matrix with some examples of the number of unwanted events identified in the various combinations of probability and impact. Based on a populated matrix such as this a risk mitigation strategy can be worked out.

In the above figure of example we see that the unwanted events associated with risks are spread around the matrix. A few are in the extreme corners of low impact and low probability, which can be ignored, or high impact and high probability, which demand attention. The more difficult judgments are around what to do about those that occur around the middle of the table, and here some closer examination may be necessary before a risk mitigation strategy is decided.

Stage – 3: Risk Mitigation

Here each risk is considered for mitigation & mitigation actions are decided based upon the nature & level of the risk.

Risk mitigation is the term used for the action we decide to take in tackling each risk. Mitigation actions can be anywhere on a spectrum from doing nothing at one end to doing as much as possible to eliminate the risk at the other end. In between there are many options, such as taking out insurance to cover any losses, spending extra money on specialist resources to tackle a high risk area more effectively than we could do for ourselves, or outsourcing a risky area to a third party who will take on the risk and compensate us if it materializes.

Testing is a key element of risk mitigation because it can provide evidence of the effective countering of a risk. For example, if there is a risk that a system will have inadequate performance there will need to be development action to ensure that adequate performance is achieved, and it will then be performance testing that identifies objectively whether the performance is adequate or not. For this reason the testing associated with the higher risks needs to be the priority. This is the main principle behind risk-based testing.

Stage – 4: Risk Monitoring
Risk mitigation actions & risk levels are continuously monitored throughout the project to ensure that the overall risk levels remain acceptable.

3) A complete description of the Software Risk Taxonomy is available in

A. Product Engineering

1. Requirements

a. Stability

b. Completeness

c. Clarity

d. Validity

e. Feasibility

f. Precedent

g. Scale


2. Design

a. Functionality

b. Difficulty

c. Interfaces

d. Performance

e. Testability

f. Hardware Constraints

g. Non-Developmental Software

3. Code and Unit Test

a. Feasibility

b. Testing

c. Coding/Implementation

4. Integration and Test

a. Environment

b. Product

c. System

5. Engineering Specialties

a. Maintainability

b. Reliability

c. Safety

d. Security

e. Human Factors

f. Specifications

B. Development Environment

1. Development Process

a. Formality

b. Suitability

c. Process Control

d. Familiarity

e. Product Control

2. Development System

a. Capacity

b. Suitability

c. Usability

d. Familiarity

e. Reliability

f. System Support

g. Deliverability

3. Management Process

a. Planning

b. Project Organization

c. Management Experience

d. Program Interfaces

4. Management Methods

a. Monitoring

b. Personnel Management

c. Quality Assurance

d. Configuration Management

5. Work Environment

a. Quality Attitude

b. Cooperation

c. Communication

d. Morale

C. Program Constraints

1. Resources

a. Schedule

b. Staff

c. Budget

d. Facilities

2. Contract

a. Type of contract

b. Restrictions

c. Dependencies

3. Program Interfaces

a. Customer

b. Associate Contractors

c. Subcontractor

d. Prime Contractor

e. Corporate Management

f. Vendors

g. Politics

 4) Risk Treatment

 Each risk in the risk list is subject to one or more of the following Risk Treatments. 

 a. Risk Avoidance:

For example, if there is a risk related to a new component, it is possible to postpone this component to a later release. Risk Avoidance is uncommon because it impacts the project objectives e.g.  delivery of new features. 

 b. Risk Transfer:

For example, if the risk is insufficient security testing of the system, it may be possible to hire a specialized company to perform the security testing. Risk Transfer takes place when this vendor is held accountable for ample security testing of the system. Risk Transfer increases the project cost.

 c. Risk Mitigation:

This is a common risk treatment. The objective of Risk Mitigation is to reduce the Risk Impact or Risk Probability or both. For example, if the testing team is new and does not have prior system  knowledge, a risk mitigation treatment may be to have a knowledgeable team member join the team to train others on-the-fly. Risk Mitigation also increases the project cost.

d. Risk Acceptance:

Any risk not treated by any prior treatments has to be accepted. This happens when there is no viable mitigation available due to reasons such as cost. For example, if the test environment has only  one server, risk acceptance means not building another server. If the existing server crashes, there will be down-time and it will be a real issue in the project.


5) Roles and Responsibilities

The paragraphs below identify the participating individuals and/or teams of the Software Risk Management Process with their corresponding responsibilities.

5.1 Program Manager

The Program Manager has overall responsibility for several projects and provides the support and funding for risk management activities.

5.2 Project Manager

The Project Manager has overall responsibility for managing the risks associated with the development and maintenance of the system and ensuring that risk management is performed in consonance with the process described herein.

 5.3 Risk Management (RM) Manager

 The Project Manager may choose to be the Risk Management Manager (RM Manager) depending upon staff size and project complexity. Otherwise, this leadership responsibility is assigned as a collateral duty to one of the technical leads on the project. The RM Manager is responsible for ensuring risk management is preformed as described in the Software Risk Management Plan.

 5.4 Software Risk Evaluation Team

Software engineers generally serve as members of Software Risk Evaluation (SRE) Teams. These SRE Teams analyze and document any risks associated with the tasks the project is required to perform.

 5.5 SRE Facilitator

The SRE Facilitator is a person who does not have a vested interest in the results of the process and can effectively move the process to closure. This person could be the quality engineer assigned to the project.

 5.6 Software Quality Assurance (SQA) Manager

The SQA Manager periodically reviews the risk management activities to ensure that the requirements of the organization’s Software Risk Management Process are being followed.

 5.7 Configuration Management (CM) Manager

 Depending upon project size, organizational structure, and assigned responsibilities, the CM Manager may play a role in risk tracking (measurement and analysis of risks) and reporting the status of designated risks to the RM Manager. For example, the CM Manager would be responsible for maintaining the database of Risk Management Forms and for providing summary information to the RM Manager to be used in developing project risk-related reports.