Playbook_Logo.png
Free Trial
Watch Demo

Eric Graves

Aerospace and mechanical engineer turned NPD systems engineer, Eric spends his time engineering better product develop systems, using PLAYBOOK as his tool of choice!

Search Result

Posts containing:

Project Risk Management for Hardware Development: The 5 Whys technique for discovering risk drivers (Part 7)

Eric Graves- 06/9/16 06:23 PM

This is Part 7 of our series on project risk management. In our last post explored Step 1: Risk identification. Next 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)!

As a reminder, in Part 1, we looked at the definition of risk management and discussed how the trick to effective risk management is to learn – both carefully and quickly – in the right balance.

In Part 2, we looked at the key piece of project risk management – the project’s objectives and how effective risk management must start with defining project objectives. We concluded that project objectives are best established in economic terms such as sales volumes, sales price, cost of goods sold, and project expenses. As well as the all-important launch schedule, which directly impacts the other objectives.

In Part 3, we looked at another key piece of project risk – the uncertain events and conditions that are the cause of a risk.

In Part 4, we looked at the return on investment of risk management and how to calculate risk exposure.

In Part 5, we explored the risk management (or learning management) process.

In Part 6 we looked at project risk identification and capture.

In this post, we look analysis and start with how to determine and document risk drivers. Including sharing a simple but powerful technique--5 Whys--for discovering the root of the problem (the root of the risk)!

For your reference, the full project risk management process is outlined at the end of this post.

Step 2 Risk Management Process: Analyze
   
a. Determine/Document the risk drivers

How do you begin to 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, which means independently, 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:

  1. Risk drivers: In short, these are the questions we’ll need to answer to mitigate the risk.

  2. 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.

  3. Probability, Impact, and Exposure: These are the assessments of the severity of the risk.

 

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.

 

But wait there is more ;-). Here's a free risk management template to get you and your team started! 

Download my free risk management template

 

The Risk (Learning) Management Process

The learning management process is cyclical, and we put each risk, issue, question, and opportunity through it as quickly and independently as we can.

We’ll start with an overview of the process steps, before we get into detail in each area (in future posts).


1. Identify
    a. Briefly describe the risk
    b. Give it a short name
    c. Assign it an owner


2. Analyze
    a. Determine/Document the risk drivers
    b. Evaluate impact, probability, and exposure
    c. Establish value rating (High/Medium/Low)
    d. (Sometimes) merge with or supersede another risk
    e. (On rare occasions) determine it is invalid


3. Plan
    a. Evaluate mitigation options and determine which mitigations to implement
    b. Establish a detailed mitigation plan, integrated with the overall project plan
    c. Establish burndown milestones (Milestones after which we re-evaluate the status and rating of the risk.)
    d. (Sometimes) decide not to mitigate the risk, because the mitigation cost is too high compared to the value


4. Implement