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 in Hardware Development: How to define risk drivers and prioritize them

Eric Graves- 06/21/16 04:30 PM

This is Part 8 of our series on project risk management for hardware teams. In the last post, we explored risk drivers. In this post, we use a real life example--the risk of a product getting too hot--to demonstrate how to define risk drivers and prioritize them. 

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 Part 7 we began the Analysis phase and looked 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)!

Tip: You may want to download and look at our free risk management template while you are reviewing this post.  It will provide with with a great framework for thinking through this example. Also for your reference, the full project risk management process is outlined at the end of this post.

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

Download my free risk management template

As discussed in the previous post, in risk analysis, we accomplish two important things. The final output is understanding the severity of the risk. However, in the risk analysis phase we also set ourselves up to effectively mitigate the risk. Fundamental to achieving these goals are defining and understanding the risk drivers. This is step 2a of the risk management process: determine and document risk drivers. 

Defining Risk Drivers Using an Example: The risk of the product getting too hot

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 risk drivers, 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.

The devil is in the detail

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 typical 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 typical 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 Drivers: Few in number, but as impactful as project requirements

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 debatched (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 risk--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.

Not All Drivers are Equal: High, Medium and Low risks

Generally, some 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. For now, a quick estimate is good.

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 my free risk management template

 

The Risk (Learning) Management Process

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