Failure Prevention Analysis
At the ASQ World conference I had a chance to talk with Lee Dawson from Quality Associates. He said something I found startling but inherently true: "One-third of all design defects are repeatedin subsequent designs." Lee works in the automotive industry, but from my 30 plus years in software, I'd say the same thing is true of software development: we tend to repeat the same errors.
Failure Prevention Analysis is a simple solution to this problem.
How to Prevent 33% of All Design Errors
In the APQP (Advanced Product Quality Planning) manual, the Automotive Industry Action Group (AIAG) recommends that designers include "Historical Warranty and Quality Information" in the Voice of the Customer (VOC).
Historical problems and concerns include:
- Things Gone Wrong (TGW) reports
- Warranty Reports
- Capability Indicators
- Supplier plant internal quality reports
- Problem resolution reports
- Customer returns and rejections
- Field return product analysis
By simply reviewing the problems with similar designs and incorporating the solutions into the new design, you can avoid a third of all design defects which will save you a fortune in production and operation expenses.
Failure Prevention Analysis (FPA)
To facilitate this time and cost saving process, Lee created what he calls Failure Prevention Analysis. We've added a template to the QI Macros to simplify the collection of this data that fuels the voice of the customer. The template looks like this:
The process for filling out the template requires a bit of historical data diving, but once you've completed the analysis, you can simply add to it in the future.
- Assemble a cross functional team from each key functional area identified in Step 3 below.
- Review the FPA process and desired outcomes with the team(s)
- Assign data collection tasks for the Failure Prevention Analysis.
Examples of relevant data include:
- Past Product Recall or Campaign Issues – Design Engineer
- Known Warranty Issues – Design Engineer; Product Health Representative
- Past Continuous Process Improvement Issues – Design Engineer; Product Health Representative
- Manufacturing Related Issues External and Internal – Quality Engineer
- Assembly – Manufacturing/Assembly Planner
- Test Failures – Validation Engineer
- After the relevant data has been assembled, it can be input into the FPA template / form.
- Review the FPA data and analysis for accuracy and completeness.
- Conduct a detailed review of the current system/component design to ensure that the historical failure modes identified through the FPA process cannot be repeated with the proposed new design.
- Capture any failure modes that the team feels have not been adequately addressed in the new design.
- Analyze all failure modes identified in the FPA in the Design FMEA.
- Verify that actions taken in the new design will eliminate or mitigate failure modes identified in the FPA.
- Failure modes not adequately addressed in the new design need to be addressed in the Design FMEA and reviewed in more detail for risk mitigation.
While many of these actions seem reasonable for a manufacturing environment, they would serve equally well in a service environment. In software engineering, we have issues with software releases, compilation and assembly errors as well as all of the testing issues uncovered from unit test through system test. Couldn't we review past failures and prevent them?
Here's My Point
It doesn't matter if you're making a brake liner, coding a new software program, or administering treatment to a patient, the historical failure data is all there; so why don't we make better use of it?
Shouldn't we be preventing known problems in new products and services rather than repeating them?
All it takes is a little forethought and analysis rather than hours of reactive rework.
It's up to you: fire prevention or fire fighting. The latter is often more exciting, but the former will let you sleep at night.