Risk Management

Common Activities

What

Risk is the possibility of suffering loss. Risk management is the activity of eliminating or reducing the impact of undesired events that will make your project suffer.

How

The dish

Risk Management.

Ingredients

• Risk events.
• Risk probabilities.
• Risk impact.
• Possibility of detection before release.

Process

Do risk management in a systematical way and let it be a continuously repeated task through the different phases of your project.

Use the following process to arrange risks with respect to seriousness. The risk given the highest rank should be addressed first in your subsequent risk mitigation activity.

  1.     Identify risk events and their probabilities.
  2.     Evaluate the possible risks.
  3.     Estimate the chance of detecting a risk event in tests.
  4.     Rank the risks by multiplying the probability, the risk impact and the test-detection rate. Plot the risks (identification and rank) in a table as the one below.
  5.     Do Risk mitigation. The most serious risk first.
  6.     Document your risk management evaluations and decisions. 

How in detail

Use the following process to arrange risks with respect to seriousness. The risk given the highest rank should be addressed first in your subsequent risk mitigation activity.

1. Identify and list possible risk events:

Identify possible risk events by research and interviews: Study available project documentation and ask the costumer and colleagues about possible risk events. List the possible risk events but do not asses them until all possible events are listed.

1. Classify how likely each risk event is to occur.

Classify how likely each of the listed risk event is to occur.

To systematically do so it is important to analyse your project at different levels.

First consider the system from an overall perspective, then on components level. Consider both external and internal events.

Give the risk a possibility-rank from 1 to 10, where 10 is the rank for risks which will occur for example within a probability of 95-99,9% (Events that are guaranteed to happen are not risks!).

Note, that the probability intervals should be chosen specific for the current project. As an example the rank 10 in the automobile industry corresponds to a probability of more than 10%, and the rank 5 corresponds to a failure probability of 0,2% (the ranking scale is not necessary linear). The scale in the table shown below does not necessary match your project.

1. Evaluate the possible risks:

Clarify how serious each risk will affect the project if it occurs. Would the considered risk event introduce serious effects on the project schedule, project quality or ability? Or does it introduce only a minor consequence? To evaluate the effects of a risk event it is important to consider all possible consequences from a given risk event. As an example a defect electrical component could result not only in a detected failure of the system, but could also cause other components to suffer due to unwanted current/voltage levels. Or it could introduce 230V on the front panel causing a dangerous situation for the customer.

Give the risk-impact a rank from 1 to 10; 10 being the most serious one: that the project can not be realised and will need to close:

In the table below, the estimated impact listed are examples of impacts to (software, hardware and mechanical items) performance, support, cost and schedule and should be used only as a guideline to rank the actual risk event. For each risk events, the (true) statement given the highest rank in the table decides the rank of the risk impact.

1. Estimate the chance of detecting a risk event in tests:

How likely is each risk to be measured/found by test before releasing the product to the customer. Give the risk-detection a rank from 1 to 10. If the failure/event is almost certain found in the planned tests, the rank should be 1. If it is not possible to detect the failure/risk event in a planned test, rank the risk event by 10.

1. Rank the risks.

The risk-seriousness is the product of probability, impact and detection ranks. This gives numbers from 1 to 1000. 1000 indicating the most serious risks which should be addressed first in the project risk management activities.

RISK RANK = PROBABILITY RANK x IMPACT RANK x DETECTION RANK

As an illustration and to get an overview of the listed risks, the risks can be indicated in a table as the one below. Each risk is shown in the proper place indicating reference name (or number) and the corresponding seriousness (rank). The colors indicate the seriousness of the risks.

1. Risk mitigation.

Consider first the risks that belong to the red areas in the table. These are the most serious (important) risks and should be addressed first. To reduce the impact of this risk, either the probability or the impact of the risk should be reduced to allow the risk to be moved from the red area into a yellow or even to a green area.

Can there be or are there scheduled activities to prevent each risk to occur or to change the possibility that the risk event will happen? Are there straightforward methods to reduce the impact of this risk?

1. Document your risk management evaluations and decisions.

To be effective, the risk management activities in your project should be a re-occurring activity through the different phases of your project. Therefore it is very important to document your risk management activities in order to take care of your evaluations and decisions throughout the project. Be sure that recommended actions are implemented.

Risk management considerations from the current project can most probably also be re-used in your next projects. So be careful to document your evaluations and activities.

The risk management activities can be symbolised by the following figure

(ref.: http://www.sei.cmu.edu/programs/sepm/risk/paradigm.html):

Function Description

Identify Search for and locate risks before they become problems.

Analyse Transform risk data into decision-making information. Evaluate impact, probability, and timeframe, classify risks, and prioritise risks.

Plan Translate risk information into decisions and actions (both present and future) and implement those actions.

Track Monitor risk indicators and mitigation actions.

Control Correct for deviations from the risk mitigation plans.

Communicate Provide information and feedback internal and external to the project on the risk activities, current risks, and emerging risks.

                Note: Communication happens throughout all the functions of risk management.

Why

Risk is the possibility of suffering loss.

Risk management is to eliminate or reduce the impact of undesired events on your project; Events that when happening will affect your project schedule, quality or ability, and the project will suffer loss.

If you don't perform risk management you will not have insight into what could go wrong in your project. Consequently more resources will be spent correcting problems that could have been avoided. Catastrophic problems (surprises) may occur without warning (and with no recovery possible). The overall probability of successful completion of your project is reduced, and your project may always be in a crisis. Resources will be spent on "Fire-fighting" instead of avoiding problems before they arise.

It is very important that the risk management is a "before-the event"-action and not an "after-the-fact" exercise. Often when a risk event is identified, there are obvious (and even easy) solutions to reduce or eliminate the risk.

In general, using the OOA methodologies in the project development already includes several initiatives to discover and reduce possible risks, such as programming errors in software or requirements specification changes. As an example the recurrence of the disciplines in the realisation phase of the project reduces the impact of the risks that can be detected in software test. But still it is important to focus continuously on possible risks, especially those which are special for the present project.

It can be useful to divide the risk events into categories: Internal risks and external risks. Internal risks are those that you yourself has the fully capability to prevent. External risks being those coming from outside and you cannot do anything to prevent them to happen, you can only reduce the impact to your project.

Note that:

Events that are guaranteed to happen are not risks.

Events that do not affect the project, that is the project schedule, quality or ability are not risks.

Events that are common to all projects should not necessary be included in the project risk management. They should rather be treated as part of standard project planning, as done in this EUDP method (For example: just read any "why-section" and you will find possible general risks listed and taken care of in the EUDP method.)

It is important in your risk management activity to focus mainly on risks special to the present project. Ask yourself: what is new compared to my previous experiences in this field? What special risks do I take in this project? References:

The Carnagie Mellon Institute:

http://www.sei.cmu.edu/programs/sepm/risk/risk.mgmt.overview.html

"Potential Failure Mode and Effects Analysis (FMEA)", Third Edition July 2001, DaimlerChrysler Corporation, Ford Motor Company, General Motors Corporation.

Example

Example of risks and rank considerations:

A hardware component can not be delivered from sub-contractor within the time needed for implementation in your project.

The single potential customer goes bankrupt. Probability: 1-2, Impact: 10

Use of new methodologies. Did I do this before? How experienced am I in this field?

Two customers (for example man and wife) communicate with the system at the same time. Is this a risk? (Does it effect the system performance?)

The outside temperature sensor goes out of order and gives erroneous data.

The inside temperature sensor is disconnected or is out of order.

A software bug which starts a loop. Can this be tracked in the planned tests?