MENU

 

11-Jul-2017

Risk Mitigation in Product Design: Part 2

By Doug Harriman (Chief Technology Officer)


While developing a product, you must take risks to achieve market success. To achieve business success with that product, it’s critical to assess and address risk as early and affordably as possible. At Simplexity, we’ve spent our careers helping companies simplify designs and reduce risks.

Steps to mitigate risk

Now that we have a tool for assessing risk, how do we go about addressing it? More importantly, how do we mitigate risk as affordably as possible? Buying insurance certainly can mitigate risk, though it’s an expensive option. Better to eliminate threats as early as possible in the design process where the cost is lowest.

Risk mitigation starts upstream of the DFMEA (Design Failure Modes and Effects Analysis) process. These risk mitigation steps are a subset of Simplexity’s 7 Steps to Simplification©.

Step 1: Specification

The first step in risk mitigation is to figure out exactly what you’re designing. The design team and the client must hammer out a specification document calling out as many requirements as possible with as much detail as possible. This document makes the product requirements clear to the design team so nothing major is missed. Adding a feature late in the design process is typically very expensive.

Write everything down in a single document. The simple act of writing things down can provide an amazing amount of clarity. It’s also critical that it is a single, living document so everything is visible to everyone. Email locks information away to only those in the conversation, but a single document available to the whole team provides the required visibility.

The key here is to get as much as you can into the document early. It will not be complete at the start of the design effort and that’s OK. Try to shoot for 80 percent completion and be sure to update the document as the team makes decisions. Also, the design team will often make major architectural decisions during this phase. Iterating those architectural decisions early in the process is comparatively cheaper and important for reducing risk later.

Due to the effort required in developing a specification, Simplexity typically recommends that this be a preliminary phase completed before diving into the next level of design. It can be tempting to skip the time and expense of this step, but changing a few lines in a document is much cheaper than scrapping a tool because a key feature was misunderstood.

Step 2: Brainstorming

Equipped with product requirements listed in the specification document, the team can dive into a detailed design process. That starts with a brainstorming session. Brainstorming reduces risk in the design by producing multiple potential design options. Moving forward immediately with one design increases risk by prematurely reducing your design options. Also, we want multiple design options to feed the DFMEA process.

Step 3: DFMEA

The DFMEA process is how we assess design risk. Using the output from the brainstorming session, we can now assess the risk for multiple design options with DFMEA.

Here’s what the design team gets out of this analysis: The design candidate list should be narrowed to the top one or two options with the best risk profile so we know which areas of each design we need to de-risk to move forward.

Step 4: Partial Prototypes

The DFMEA process brings the areas of highest technical risk to the surface. Note that at this point the design has not been fully detailed and we have not spent effort or cash generating prototypes. This keeps the cost of the program low.

With the risk areas identified, it’s time to generate hardware that will support the testing. From this testing, we can generate the data necessary to provably close out a risk item. The first prototypes created are not of the whole product. To keep costs low, we only create partial prototypes of the portions of the system where the risk is concentrated. These partial prototypes are often known as “testbeds” or “test development vehicles” (TDVs).

With the partial prototypes, we can test and iterate the design of the riskiest subsystems until we are confident that we’ve mitigated the risk. Again, we don’t want to jump to a full prototype initially, as that requires many additional decisions and will constitute a significant portion of the program’s NRE (non-recurring engineering cost). If we must iterate key subsystems underneath the full prototype design, we will incur a significant cost in redesign.

Step 5: Full Prototypes

With the key risk areas addressed, the detailed design of the full product can commence. It’s finally time to generate a full product prototype. In fact, it’s typically a good idea to generate multiple copies of the first revision of the design. These prototypes will be run through a battery of tests to assess how well the design performs against the requirements. We’ll want to characterize product performance limits, performance sensitivity to environmental factors, design robustness, life, shipping and handling performance, and more. We may also want to run tests where key parts or subsystems are modified to tolerance limits.

Expect to iterate the full design at least once to address any shortcomings that surfaced in the prototype testing. The more units you can build and test, the more tests you can run and the greater the statistical significance of the results.

One thing to keep in mind when testing: Maintain configuration control over the device under test. You want to make sure you know exactly what revision of the design is being tested and if any specific modifications have been made. It’s always frustrating to get test results and then realize you don’t know if the testers used revision one or revision two of the part.

Product development is and must be an inherently risky process. The business will determine if the development process was successful both by how well the risks were removed from the design and by how costly the risk mitigation process was. By structuring your product design process correctly, risks can be removed early and at the lowest possible cost.

If you want to see how our approach to product development can help you with risk mitigation, contact Simplexity today.


 

 


Subscribe For More

To receive more articles like the one above in your inbox, sign-up to our newsletter below.

Blog Posts


Better Firmware Faster

19-Nov-2018

Demystifying What it Takes to be a CEO

18-Oct-2018

Considerations for Code Refactoring

24-Sep-2018

American Association for Clinical Chemistry Annual Meeting

30-Aug-2018

Simplexity's Answer to Growing Pains

09-Aug-2018

Consumer Electronics Show 2018 | Part Three | So, What is a Robot?

29-Jan-2018

Consumer Electronics Show 2018 | Part Two | CES 2018 and IoT

22-Jan-2018

Consumer Electronics Show 2018 | Part One

15-Jan-2018

Why on earth are heavy weights being suspended from this printer?

22-Dec-2017

10 Best Places to Buy Parts for Product Development

29-Nov-2017

Robust Firmware Stack Sizing

08-Nov-2017

Senaptec Strobe: A Study in Simplification

19-Oct-2017

Treatment, Prevention, and Medical Engineering Solutions

04-Oct-2017

Options in Product Development Models: Internal, CDM, or Design Specialist

20-Sep-2017

Designing Thermal Control Systems

30-Aug-2017

Simplexity’s 7 Steps to Simplification©

15-Aug-2017

Battle of the Buttons: UCSD vs. PSU

02-Aug-2017

Considerations For Medical and Biotech Designs

13-Jul-2017

Risk Mitigation in Product Design: Part 2

11-Jul-2017

Risk Mitigation in Product Design: Part 1

28-Jun-2017

San Diego's Biotech Consortium

09-Jun-2017

Appropriate Models for 3D Motion Analysis: Part 3

25-Apr-2017

University of Oregon’s Product Design Program Is One of a Kind

19-Apr-2017

Appropriate Models for 3D Motion Analysis: Part 2

14-Apr-2017

From Engineer to Leader: How Do You Get There?

12-Apr-2017

Appropriate Models for 3D Motion Analysis: Part 1

06-Apr-2017

Why Engineering Still Matters in Product Development

29-Mar-2017

How Mechatronics Improve Drone Technology

16-Feb-2017

Why You Need a Gyro to Measure Position

20-Jan-2017

Why I, As The CEO, Get The Same Bonus As All My Other Employees

13-Dec-2016

Mechatronics Aids In Embedded System Design

07-Dec-2016

Top 10 Tips for Designing Injection Molded Plastic Parts

22-Nov-2016

British school kids and car hackers: the widespread appeal of open source

14-Nov-2016

When should you consider designing custom gears?

07-Nov-2016

Conference Report: Open Source Hardware Summit

31-Oct-2016

What is a Motion Control System?

20-Oct-2016

The Top 10 Questions to ask a Product Development Firm

05-Oct-2016

The Potential of the Apple AirPods To Disrupt A Whole Industry

12-Sep-2016

How to Use Open Source Hardware in Product Development

01-Sep-2016

What is the mech in mechatronics?

16-Aug-2016

3 Tips for IoT Product Success

02-Aug-2016

When Should I Start Designing For High-Volume Manufacturing?

19-Jul-2016

Designing a 3D Printer for the Home

29-Jun-2016

It Turns Out That EMC Is Not Black Magic

22-Jun-2016

Selecting the correct motor type and size

06-Jun-2016

When brainstorming fails, throw an imaginary cat

18-May-2016

Five Tips for Mechatronic System Integration

09-May-2016

Three Tips for Designing High Volume Mechatronic Products

28-Apr-2016

What Is Mechatronics?

18-Apr-2016

If I could only do 3 things to simplify a design, what should they be?

06-Apr-2016