Risk Management

A risk is a potential issue waiting to happen leading to some unintended effects. If there is zero probability for the risk to happen, then it is not at all a risk. Similarly, if there is no adverse effect with the happening of the issue, it is not a risk. If the issue had already happened, it is no more a risk, but a problem.

Risk Identification and Analysis

There could be various risks inside the projects. Those needs to be first identified and then analysed based on their probability of occurrence and effect (impact). Based on these analysis risk needs to be prioritised for action.  Here we are actually prioritising the risks based on three factors i.e. Probability of occurrence, impact and detectability of the risk

Highly probable, huge impact and low detectable risks needs to be treated first. For prioritization of risks we need to have some metrics associated with it. We call it as risk value. It is the product of probability, impact and detectability.

Probability can range from a value near to zero (not zero) to a value near to 100(not 100). Assume the range of impact is given as 1 to 5 (where 5 corresponds to high impact) and detectability as 1 to 10 (where 1 corresponds to highly detectable). So the maximum and minimum value of risk is

R max = 0.99 * 5 * 10
R min = 0.01 * 1 * 1

Risk Treatment

Definitely not..

So we need to know some critical values for the risk above which only actions are required. Below to that value, we are accepting the risks. We call that critical value as the threshold value. For example if an organization has defined the risk threshold value as 3 (out of 1 to 5 rang of scale), and identifies a risk with a value 2, then, no further actions are required upon the risk.  Simply we can keep that risk in watch mode till the impact time frame of that risk. Once the impact time frame is over, that risk could be retired.

For all the risks above the threshold value, we need to have mitigation actions for reducing the risk value below to the threshold level. In addition to mitigation steps, we should plan for the contingency steps also to face a situation when the risk hits.

We will deal the scenario first with a real life example and then move to a project case.

 Example 1:

The roof of a classroom is in damage. Students are sitting inside the classroom. So here the risk is “If the roof falls down, it will cause serious injury to students”.

The actions taken to solve the issue should be normally

  • Shifting the students to another class room or
  • Repairing or removing the roof and continuing in the same class.

Here along with the first solution we are actually trying to address the impact of the issue. So naturally once we take this mitigation step, impact value is going to be reduced. And along with the second solution we are reducing the probability occurrence.

If there is someone who monitors all these kinds of stuffs, risk should be easily detectable also.

Example 2:

A project has reached the end of coding phase. In order to do the integration testing a module is required from a third party. If that module is not received before the end of module testing phase, integration testing would be delayed, leading to overall slippage in product delivery to customer. (On-time delivery is critical to the project)

  • Cause of the risk: Delay in receiving a module from third party
  • Impact due to the risk: Delivery slippage.

Let Probability of occurrence be 60% and impact be 5 (1 to 5 scale)

Assume, the organization has a matured process to detect the risk as early as possible. So detectability is going to be high for all the projects in the organization. So let us ignore that detectability part (specific to this example).

Risk value = 0.6 *5 = 3

Assume the accepted threshold value in the organization is 2.It means that proper mitigation steps needs to be taken for the above case. Mitigation steps could be

  • Release without integration testing under consensus with customer
  • Identify some simulators to replace the module and do integration testing

Here along with the first solution we are actually trying to address the impact of the issue. So naturally once we take this mitigation step impact value is going to be reduced. And along with the second solution we are reducing the probability occurrence.

Once we take the mitigation steps to reduce the probability or impact value or to increase the detectability, we are actually trying to reduce the risk value. If the risk value has not reached below the threshold level, further mitigation steps should be taken and process continued.


Akhila is the founder and sole contributor of wordsandnotion.com and qualitynotion.com. By profession she is a software Quality and Quantitative data analyst. She is a self motivated life long learner who loves to decode signs from the universe. Her weirdness is totally aligned with her real life stories and thought experiments. She is the author of “Know them, One answer to many questions” (a General Knowledge book) and “I Had a Crush - The 17 Kinks” (A free ebook of 17 short stories)

You may also like...

One thought on “Risk Management

  1. Sreejith

    April 19, 2012 at 6:34am

    First up, congrats for setting up such a discussion forum/blog/whatever you call, for discussing QA matters. Hope this will grow and act as a quick reference for all QA people.

    Btb, coming to risk management, I am not sure if delivering the code without integration testing (i.e without the third party module) would reduce the impact. The customer would be unhappy right?

    Permalink  ⋅ Reply

Leave a Reply