Risk Management

From EUDP
Jump to: navigation, search

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.

Tx oodocs 5cb37a537c.gif

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 probability 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 customer and colleagues about possible risk events. List the possible risk events but do not asses them until all possible events are listed.

2. 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 at component level. Consider both external and internal events.

Give the risk a probability ranking of 1 to 10, where 10 represents a risk which will occur for example within a probability of 95-99,9% (events guaranteed to happen are not risks!).

Note that the probability intervals should be chosen specifically 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 necessarily linear). The scale in the table shown below does not necessarily match your project.

Tx oodocs 8dd56498f1.gif

3. 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 may 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.

Rank each risk by impact on a scale from 1 to 10 with 10 being the most serious one (i.e. that the project cannot be realised and will need to close).

In the table below, 'Estimated probability' is examples of impacts on (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.

Blah.gif

4. Estimate the probability of detecting risk events in tests

How likely is each risk to be measured/found by test before releasing the product to the customer. Rank the probability of detecting risks on a scale from 1 to 10. If the failure/event is almost with certainty 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.

5. 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 colours indicate the seriousness of the risks.

Tx oodocs 0168e7bef0.gif

6. Risk mitigation

First consider 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?

7. Document your risk management evaluations and decisions

To be effective, the risk management activities in your project should be a reoccurring 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 may most probably also be reused in your next projects. So be careful to document your evaluations and activities.

The risk management activities can be illustrated by the following figure:

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

Tx oodocs ae899a5d91.png

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 internally and externally 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 do not perform risk management, you will not have an 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 "firefighting" 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 a 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 have the capability of preventing. External risks come from outside of the project, and you cannot do anything to prevent them from happening; you can only reduce the impact on your project.

Note that:

Events that are guaranteed to happen are not risks.

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

Events that are common to all projects should not necessarily be included in the project risk management; they should rather be treated as part of standard project planning, as done in this EUDP method (e.g. read any 'why' section, and you will find possible, general risks listed and taken care of in the EUDP method).

It is important that you focus primarily on risks special to the present project in your risk management activity. 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

Examples of risks and rank considerations:

A hardware component cannot 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 (e.g. a man and wife) communicate with the system at the same time. Is this a risk (does it affect the system performance?)?

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

The inside temperature sensor is disconnected or out of order.

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