Risk drivers and 5 whys

We begin the analysis phase and look at risk drivers and the 5 Whys technique - a simple and powerful technique for discovering the root of the problem (the root of the risk).

How do you analyze risk?

To use an analogy, while mitigation is where we score the touchdown, and planning is where we determine which plays we’ll run to drive down the field, analysis is where we see the deficiencies in the opposing team’s defense that tells us which plays to run. The touchdown is achieved through effective analysis and mitigation.

Analysis consists of determining and documenting some specific characteristics of the risk.

Remember, we put risks through the process quickly so we are focused on a single risk going through the process.

We’ll provide a quick overview before we dive deeper into each of these areas:

Risk drivers: In short, these are the questions we’ll need to answer to mitigate the risk.
Impacted objects: These are the parts, subsystems, assembly processes, test processes, and/or documents that will need to change as we answer the questions around risk drivers and mitigate the risk. In most Risk Management processes, evaluating the objects impacted is happening in the back of people’s minds. However, we highly recommend surfacing this critical thinking. In our opinion, understanding the object that are impacted is integral to managing risk. As far as we know, this aspect is unique to our process.
Probability, Impact, and Exposure: These are the assessments of the severity of the risk.

Wanting a deeper dive into Lean-Agile and Playbook Principles? Check out our free Lean-Agile training on Playbook Academy such as Rolling-Wave Planning, Applying Agile to Hardware and Critical Chain Project Management.

Risk Drivers

Preston Smith and Guy Merritt, in their book, Proactive Risk Management define a Risk Driver as:

"Something existing in the project environment that leads one to believe that a particular risk would occur."

We describe them as the specific concerns which make us feel like this is a risk.

For our first example, we’ll refer back to the first post in this series, where we observed kids in New Zealand jumping into the river from 40 foot high branches. The whole concept of jumping 40 ft into a narrow river seems really risky. Why? By answering this question we come up with the risk drivers.

5 Whys

This brings us to the method of the 5 Whys, one of the methods used in Toyota lean processes…and a powerful method for discovering the root of any problem

Root causes of issues are similar to drivers of risks. In fact, when an unrecognized and mitigated risk comes to fruition, it becomes an issue and its risk drivers become some of the issue’s root causes. (With the other root causes being the reason the risk wasn’t mitigated.)

Only asking why once, when probing for risk drivers will often leave us with misleading mitigation plans.

Here is an example. If we stopped asking why when we identified the potential to break our legs, we might have chosen to mitigate that risk via avoidance. Avoidance is one of the primary categories of mitigations – just not doing whatever it is that is risky.

However, avoiding risks in product development often means we’re avoiding innovation, which isn’t a great option.

Rather, we might choose to mitigate the risk of jumping into the river by doing a belly-flop, or back-flop. However, the outcome could be even worse. This choice could result in a broken back, paralyzation, or worse.

To avoid overly costly mitigations like these, we can often simply ask why, again. Why would we break our legs?

When we find the answer to that question, we arrive at the key risk driver; The one that can lead to effective mitigation.

So, why might our legs get broken? The river might be shallow enough that we’d hit the bottom. “The river might be shallow,” is a risk driver we can address pretty easily. There are any number of ways we could determine the depth of the river to mitigate the risk.

When using the 5-Whys for root cause analysis, when you get to the cause that can be addressed, you can stop asking why.

Similarly, when the team reaches a risk driver/question they can easily take action to answer, they have dug deeply enough. Sometimes this occurs in less than 5 whys, and sometime it takes more.

Unfortunately, just as the 5 why’s method has valid criticisms for root-cause analysis, it doesn’t perfectly apply to identifying Risk Drivers either. Still, the point is very valid. The first drivers that come to mind when we are assessing risks are very often not the best for driving our mitigation plans. A few minutes spent digging deeper to get to the specific fundamental information we need can save hours, days, or even weeks of effort.

It’s often said, "90% of the answer is knowing which question to ask," and this absolutely holds true in risk management.

This brings me to the recommendation that drivers be put into the form of a question. The differences between the statement, “The river might be shallow” and the question “Is the river shallow?” are subtle, but important.

Why pose risk drivers as questions?

When planning how to mitigate a risk, if we recognize that we are simply trying to answer questions, we can more clearly leverage concepts from Information Theory and other related techniques. We can approach mitigation planning by asking, “How can we most quickly answer that question?.” The result is more often a fast, de-batched mitigation plan that will generate the information we need quickly.

In addition, people naturally think in terms of questions. Plus, it enables us to easily incorporate knowledge gaps of all kinds. It’s said that, "the product of product development is information (Don Reinertson)," and putting risk drivers into the form of a question helps us recognize this and arrive more quickly at the answers.

While posing drivers as questions is generally easy, some can be a bit difficult to translate into a question. In these cases, our recommendation is not to force it. If the statement doesn’t work as a question, it doesn’t have to be a question.

Join us in the next post as we present a real-life example of a hardware product development risk, and discuss the drivers a little bit more before we move on to the other steps of Risk Analysis.