Defining Risk Drivers
Product development is a risky business. So how do you effectively minimize the impact of risks on your project? In short, you need an effective strategy for prioritizing, managing and mitigating risks. It's a team effort.
As discussed in the previous post, in risk analysis we accomplish two important things.
- Understanding the severity of the risk
- Effectively mitigating risk
It's easiest to demonstrate how to mitigate risk using a real life example. The example we are looking at is the risk of a product getting too hot. We are going to use this example to demonstrate how to uncover and rank risk drivers.
Step 1. Uncovering Risk Drivers
Uncovering risk drivers is the first and most important step in the process. It requires the team to ask and answer "why" in great detail.
There are different ways that heat can cause issues in product development. For example, the system could start to break down at higher temperatures, or the user could be hurt or suffer some discomfort while using the product. This example uses the latter case and uses a product that people will be in contact with during normal operations. Think of a mobile phone, hand-held drill, surgical device or a video camera.
So, for example the team may begin with the questions.
- Why might it get too hot?: The circuit chip(s) or motor(s) might generate more heat than the device can easily dissipate.
- Why might it not dissipate heat easily? It’s a condensed package, using materials and a design that look good and sell well, but don’t dissipate heat well.
Next the team continues probing to define risk drivers in more detail.
- What is the maximum allowable temperature?
- How hot will it get? (How much heat is generated? Dissipated?)
- How long does it take to overheat?
- Under what operating conditions does it overheat?
- How do our competitors address/avoid this risk/issue?
- What alternate materials look good enough and dissipate heat well enough?
- What alternate shapes/designs look good enough and dissipate heat well enough?
- What other industries / products might have similar challenges, and how do they address them?
There may be more fundamental drivers for this risk, but you get the idea.
Step 2: Be specific when defining risks
Reviewing the list above, notice that these questions are carefully worded to be as specific as possible. Specific questions are much easier to answer quickly than vague questions. In fact, we find that if teams take the time to phrase a question well, it will save them many hours of time.
In addition, notice that these drivers can be applied to many different products. If we are in the business of developing hand-held devices, we will surely encounter this risk again and again. If we develop a set of well defined drivers, we can reuse them each time we encounter this risk.
Is this a risk or standard design work?
We get this question almost every time we engage with a team in identifying project risks.
The example we present here illustrates the grey area between risks, knowledge gaps, issues, and just standard design work. As I’ve described in prior posts, we see very little benefit in trying to distinguish between these only slightly different things, especially because we can put them all through the same process to resolve them quickly.
The question is, would the project benefit by being a little more deliberate in identifying and answering these types of questions? For example, would 30 minutes spent laying out the questions we need to answer likely save us more than 30 minutes of design and documentation rework, extra/repeated discussion, and/or answering the wrong questions? Even if it doesn’t in all cases, it will in most cases.
Step 3: Prioritizing Risks
The total number of questions we need to answer to mitigate project risk pales in comparison to the number of specifications we establish during a project.
I estimate the ratios to be about 100:1 detailed specifications (e.g., part dimensions) to risk drivers (e.g., an answer to a driver question will impact on average about 100 detailed specifications), if there is still enough design flexibility to accommodate the answer.
If the answers come too late to make changes, the cost of the late information comes in the form of reduced sales and/or higher than necessary production costs. With a little time spent defining drivers early, we minimize late changes to all of the related specifications and these costs.
The number of fundamental drivers we identify for each risk typically varies from one, to a high of about fifteen. If you find yourself identifying more than ten drivers/questions for a risk, there is probably a way to break that risk into two or three different risks, which has the added advantage of driving a de-batched (faster) approach to mitigating those risks.
For example, by separating the risk of heat-caused user discomfort and the risk of heat-caused technical issues, each risk gets simpler and easier to manage. In addition, if you use a software tool such as Playbook during the risk analysis phase (and Excel to a much lesser extent), it’s easy to have questions which are common to multiple risks--so they only need to be asked (and answered) once.
Once we have identified the risk drivers, we are ready to move on to identifying the impacted objects, which I will describe in the next post. However, when we get to the mitigation planning step, we’ll develop better plans if we take one more step involving the drivers.
Assigning High, Medium and Low risks
Generally, some risk drivers, or their associated answers rather, are more important than others. There are big questions and little questions. For example, There are answers with a bigger impact and answers with a smaller impact on the project. Making it clear which questions are most important can help drive a better mitigation plan, where we get the most important answers earliest.
In order to prioritize drivers, we recommend simply rating each one (H)igh, (M)edium, or (L)ow in terms of how much value there is in the answer. For example, I might rate the heat risk drivers as follows:
- (H) What is the maximum allowable temperature?
- (H) How hot will it get? (How much heat is generated? Dissipated?)
- (H) How long does it take to overheat?
- (H) Under what operating conditions does it overheat?
- (H) What do our competitors do to address this risk/issue?
- (M) What alternate materials look good enough and dissipate heat well enough?
- (M) What alternate shapes/designs look good enough and dissipate heat well enough?
- (L) What other industries / products might have similar challenges, and how do they address them?
We assign High value to the answers we think can quickly tell us if the Medium value (more costly) answers are worth pursuing. The rationale is that the High’s are where the impact of getting that answer late is highest.
For example, exploring alternate designs (answering questions 6 - 8) before we know whether we even have a problem (questions 1 – 5) could be a waste of time and/or our alternative design might be overkill or might not solve the problem.
When evaluating objects impacted, the risk severity, and even doing the planning, we can refine these priority ratings. However, at this stage in the risk management process a quick estimate works well.
Download a free risk management template to get you and your team started!
Related Posts
What is Risk Management?
Risk Management and Project Objectives
8 Types of Risk
ROI of Risk Management
Risk Management Process
Risk Identification and Capture
Risk Drivers and 5 Whys
Risk Mitigation Strategy (part 1)
Objects Impacted and Modular Architecture
Calculating Risk Exposure and Free Risk Exposure Spreadsheet
Risk Mitigation strategy (part 2)
