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

Tech We Can’t Wait To See At CES 2019


Ossia Cota Forever Battery: Collaborative Design


Better Firmware Faster


Demystifying What it Takes to be a CEO


Considerations for Code Refactoring


American Association for Clinical Chemistry Annual Meeting


Simplexity's Answer to Growing Pains


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


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


Consumer Electronics Show 2018 | Part One


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


10 Best Places to Buy Parts for Product Development


Robust Firmware Stack Sizing


Senaptec Strobe: A Study in Simplification


Treatment, Prevention, and Medical Engineering Solutions


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


Designing Thermal Control Systems


Simplexity’s 7 Steps to Simplification©


Battle of the Buttons: UCSD vs. PSU


Considerations For Medical and Biotech Designs


Risk Mitigation in Product Design: Part 2


Risk Mitigation in Product Design: Part 1


San Diego's Biotech Consortium


Appropriate Models for 3D Motion Analysis: Part 3


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


Appropriate Models for 3D Motion Analysis: Part 2


From Engineer to Leader: How Do You Get There?


Appropriate Models for 3D Motion Analysis: Part 1


Why Engineering Still Matters in Product Development


How Mechatronics Improve Drone Technology


Why You Need a Gyro to Measure Position


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


Mechatronics Aids In Embedded System Design


Top 10 Tips for Designing Injection Molded Plastic Parts


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


When should you consider designing custom gears?


Conference Report: Open Source Hardware Summit


What is a Motion Control System?


The Top 10 Questions to ask a Product Development Firm


The Potential of the Apple AirPods To Disrupt A Whole Industry


How to Use Open Source Hardware in Product Development


What is the mech in mechatronics?


3 Tips for IoT Product Success


When Should I Start Designing For High-Volume Manufacturing?


Designing a 3D Printer for the Home


It Turns Out That EMC Is Not Black Magic


Selecting the correct motor type and size


When brainstorming fails, throw an imaginary cat


Five Tips for Mechatronic System Integration


Three Tips for Designing High Volume Mechatronic Products


What Is Mechatronics?


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