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: How to effectively navigate risks in hardware development projects! (Part 5)

Eric Graves- 05/3/16 04:41 PM

This is Part 5 of our series on project risk management for hardware product development.  Now that we have confirmed risk management has a high return on investment, it's time to explore the risk management (or learning management) process.  How do you effectively navigate risk in hardware development projects...?

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.

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.

So, we agree, risk management has a high return on investment. Now what? Let's look at the process.

Risk Management 

When I refer to risk management process, I refer to the process that each risk will go through, rather than a process that all risks go through together.

(While, at times, it may seem like the process is applied to all risks simultaneously, a key aspect of truly Lean product development is debatching. Debatching allows quicker mitigation.)

This risk management process may be more aptly called the knowledge generation process. In fact, at PLAYBOOK we prefer the term “learning management,” because when we manage risk, we usually generate knowledge. Our risk management process has many things in common with what some call Knowledge Based Product Development or Learning First Product Development. It also has a lot in common with LAMDA, PDCA, and the good ‘ole Scientific Method. The 5-Why’s are in here, too.

Call it what you will, risk management is the essence of product development. Doing it well (Leanly) will improve your success rate immensely.

As a reminder from previous posts, the definition of a project risk is “an uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives.” As such, we can apply this risk management process to:

  1. Traditional Risks: Where some condition may or may not occur and result in negative impacts on the project objectives.
  2. Issues: Where the condition is quite certain.
  3. Knowledge Gaps: (Questions): Where we are pretty sure we need to learn something specific in order to meet the project objectives.
  4. Opportunities: Where we might be able to create some conditions which have a positive effect on the project objectives.

Issues, knowledge gaps, and even opportunities are commonly associated with LAMDA and PDCA processes, which themselves are variations of the Scientific Method. If you are familiar with these processes, you will likely see some similarities. We are simply pooling these variations with traditional risks in our processes.

Throughout the remainder of this post and in future posts, we generalize and call each risk, issue, question, and opportunity a “risk.” We also generalize and use the word “mitigation” when we refer to the actions and steps taken deliberately to achieve the goal of reducing risk, eliminating an issue, answering a question, or realizing an opportunity.

Finally, before I leave the definition of project risk and move on to the process, I’ll simplify it in one more way. That is, I don't distinguish between an "event" or "condition" that causes the risk. Events cause conditions, and it’s the conditions which ultimately have an impact. But sometimes conditions cause events which cause other conditions.

Rather than distinguish between events and conditions, I prefer to think in terms of symptoms and root causes. If we drill down enough to find whatever event or condition resides at the root and address that, we’ll be doing the right thing.

Stay tuned for our next post on how to effectively navigate risks in hardware development projects!

The 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

 

Interested in taking risk management a step further?  Download your free risk management template.

 

Download my free risk management template