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:

Risk Management for Hardware Development: Objects impacted and taking a modular approach to architecture (Part 9)

Eric Graves- 08/2/16 03:46 PM

This is Part 9 of our series on project risk management for hardware teams. In risk analysis, it's critical to capture the objects impacted by a risk, as well as to take a modular approach to product architecture. Here's why...

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 discussed how effective risk management must start with defining project objectives. 

In Part 3, we looked at the uncertain events and conditions that are the cause of a risk.

In Part 4, we discussed 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 covered project risk identification and capture.

In Part 7we began the analysis phase and looked at risk drivers and the 5 Whys technique.

In Part 8,  we used a real life example to demonstrate how to define risk drivers and prioritize them. 

In this post, Part 9, we discuss the importance of capturing the objects impacted by a risk in order to understand risk exposure, as well as taking a modular approach to architecture to enable faster product evolution.

Why make the effort to identify the objects impacted by a risk?

In Risk Analysis, we accomplish two important things: first we work to understand the severity of a risk; and then, set ourselves up to mitigate it.  So why make the effort to identify the objects impacted by a risk during this process?  Because identifying the objects impacted helps achieve both of these goals.

What do we mean when we say, “objects impacted?”

I define objects impacted as simply, “those parts, subsystems, documents, and deliverables which might need to change as the risk driver questions are answered.” See the last couple of posts for an explanation of risk driver questions. Objects impacted is most easily applied to technical, design, and manufacturability risks - those that impact any component’s design or production process.

In the last post we used the example of a hand-held device. We identified risk drivers such as, "How hot does it get?" and "How hot is too hot?" In evaluating objects impacted, we ask and answer (as best we can) the question, "What would we change it if it is too hot?" We’d probably change the housing to dissipate the heat, and maybe the circuit board or another internal component that is generating the heat, if we can.

Generally, the directly impacted objects have ripple effects on other objects. Take this arthroscopic camera for example:

Screen_Shot_2016-08-01_at_1.39.32_PM.png


If drastic changes are needed to the housing to dissipate heat, we may also need to change how the cable connects to the back, or how the accessories (black parts) connect in the front. It is important to recognize when we may need to change these additional parts as well, and it is important to recognize it early.

Documenting the objects impacted looks like this:

Objects Impacted:

Body (6 weeks)
PCBA (4 weeks)
Cable (12 weeks)
Accessories Mounts (6 weeks)

Why capture objects impacted?

When asking, “Is this risk a high, medium, or low?,” it is generally easy for people come up with a gut-feel answer. But the question is why? e.g., What makes a high risk high? Ultimately, a high risk is one where many objects are likely to be impacted or the objects impacted have long lead times.

Rather than doing this analysis in the back of our minds, we recommend making it clearly visible. It only takes a minute or two, but communication and documentation can shine a light on two important things.

First, communicating and documenting the objects impacted provides a standard, objective and reasonably accurate way to quantitatively assess the impact of the risk. Second, modularizing architecture can significantly accelerate product development.

Reason #1: What is the impact of the risk?

The risk’s impact is the amount of cost (usually in schedule delay and associated cost of delay), that we would realize if we did not mitigate the risk. In our example, it is the delay we’d incur if we do nothing and realize in some later test that the product is too hot, and we have to reduce that heat before we can launch.

If our solution to a heat issue is to change the design, and thereby impact the housing and circuit board, then the delay we incur, the impact of the risk, will be the time it takes to: define the design change, update the drawings, order and receive new parts, build them into units, and, test again that the solution has worked.

In other words, it is the time it takes to procure the longest lead time part, plus a few weeks for the design/document update, build, and test steps. The length of these steps can often be standardized – 3 weeks, for example. Then the impact of the risk is the maximum lead time of the impacted objects + 3 weeks.

Granted, when we need to buy another round of parts anyway because we found the heat issue in mid-project testing instead of late-project testing, the actual impact is the time required for the additional mid-project design/discuss/decide work to solve that issue PLUS the residual risk. The residual risk is usually the big part.

The residual risk is the impact (times the likelihood) of needing to do it again (and again) if we didn’t really solve it right the next time, PLUS the impact (times the likelihood) that we created other problems we’d have to solve before launch. Because the residual risks are substantial, and can be several iterations long an objective, happy medium is to just consider a single design-order-build-test iteration in evaluating the impact of a design risk.

This impacted object maximum lead-time approach corresponds well to our gut-feel high/medium/low approach, but has added benefits, in that it can drive risk mitigations that can be executed right away. Sometimes at very little time and cost.

Reason #2: Modularizing architecture speeds up development

Don Reinertsen does an excellent job of describing how modularity in our product architectures can help speed development, especially if we modularize in the ’high risk areas’. Please see his book, "Managing the Design Factory," for his overview.

I’ll summarize here by first defining modularity. There are a couple primary connotations to it. One is the ability to interchange, mix and match, and share ’modules’ across several different applications.

The second, and the one most pertinent to risk management, is that it reflects the ability to change one part of the design without any ripple effects across the rest of the design. The opposite of a modular design is a tightly integrated design, where changes are very likely to impact many other areas of the design.

Modular architectures, as opposed to tightly integrated architectures, enable faster iterations. We can change one area and procure a few parts, without needing to change lots of other areas and procure lots of other parts, too.

In our risky areas, more iterations are needed in order to learn everything and work out the kinks. If we want to deliver quickly, each iteration must be faster. Therefore, we want to modularize in risky areas.

When we capture the objects impacted by a risk, modularizing in the risky areas amounts to finding ways to get some of the impacted objects off the list, especially the longest-lead objects.
In our arthroscopic camera example, the cable in the back is a very long lead item, 12 weeks compared to the next longest item, the housing, which takes 6 weeks. If we have to change the cable design late, we will suffer a 6 week longer delay than if we don’t need to change the cable.
To get the cable off of the impacted objects list, and eliminate up to 6 weeks worth of the risk right away, we might be able to design that interface with enough design margin that the housing can change without needing to change the cable.

Or, perhaps the change we foresee on the circuit board that generates the heat would require an additional conductor in the cable. We could get the long-lead cable off the impact chain by adding an extra conductor or three, just in case we need them later, for this risk or any others.

Modularization results in much faster projects

Modularizing in risky areas is often a natural part of design, in those really obvious areas where modularization is relatively easy. However, it is easy to miss opportunities to modularize in the non-obvious areas. Capturing objects impacted as part of the risk management process, and dedicating a little time (and sometimes money) to getting some of them off the list, makes these powerful mitigations-via-modularization a visible and standard part of the risk-management process, which results in much faster projects.

There is a lot more I could go into about how and where to modularize, and the downsides of modularity (increased unit cost, usually), but I’ll refer you to Don’s book.

Are impacted objects always components?

The example above describes the natural ways we can capture objects impacted and leverage that information in analyzing and mitigating design-impacting risks. However, sometimes the ’objects’ aren’t necessarily components in our design.

Note, in my definition of objects impacted that I recommend including documents and other deliverables. These documents/deliverables include test protocols, instructions for use, regulatory approvals, requirements documents, and more.

There isn’t any need to list the documents directly related to producing the physical parts and subsystems. These impacts are implied by naming the part or subsystem impacted. For example, if eliminating the heat risk might be too difficult to do through design changes, perhaps the instructions for use, requirements, and regulatory submission documents will need to be changed to reduce the continuous operating time and allow time for it to cool off.

Surfacing impacted documents and deliverables can help drive discussions about whether those impacts are acceptable. It can help determine the exposure of the risk when the cost may be in the form of reduced sales volumes. These considerations help establish the exposure of the risk and how much we should be willing to spend on mitigation. This is one of the goals of risk analysis.

In the next post, we’ll take the next step in risk analysis – evaluating risk exposure (the high/medium/low-ness of the risk). Stay tuned...

 

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