playbookLogoNew
Lean Agile Assessment
Watch the 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:

Risk Mitigation Strategy

Eric Graves- 02/19/19 05:30 PM


Risk Mitigation Strategy

In this post, we use a real life example--the risk of a product getting too hot--to demonstrate how to prioritize, manage and mitigate risk.

As discussed in the previous post, in risk analysis we accomplish two important things.

  • We understand the severity of the risk
  • We set ourselves up to effectively mitigate the risk

Steps for mitigating risks

There are different ways that heat can cause issues: 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.

The product is one that people will be in contact with during normal operations, such as a mobile phone, or hand-held drill or surgical device, or a video camera.

To get to the drivers of risk, we can start by asking “Why?” For example:

  • Why might it get too hot?: The circuit chip(s) or motor(s) might generate more heat than the device can dissipate easily.
  • 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.

Then we continue probing to get to the fundamental drivers such as:

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

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

We find on average it saves far more than 30 minutes.

Risk management and prioritization

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:

  1. (H) What is the maximum allowable temperature?
  2. (H) How hot will it get? (How much heat is generated? Dissipated?)
  3. (H) How long does it take to overheat?
  4. (H) Under what operating conditions does it overheat?
  5. (H) What do our competitors do to address this risk/issue?
  6. (M) What alternate materials look good enough and dissipate heat well enough?
  7. (M) What alternate shapes/designs look good enough and dissipate heat well enough?
  8. (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.

Join us on the next post where we discuss the value of capturing the objects impacted by each risk – the 2nd of the three risk analysis sub-steps.

Download a free risk management template to get you and your team started! 

Download free risk exposure spreadsheet

 

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)