3 Ways to Provide Field Reliability Feedback to the Design Team

By the time a product fails in the field, the design team is focused on the next design.

They are looking to the future and not looking for field reliability feedback. We know that each failure contains valuable information.

We, as reliability professionals, often work to create as much useful information concerning failure modes and mechanisms as possible. We want to improve the design.

Yet, what happens when the design team has moved on to the next project? When the expertise to effectively make changes to the design to improve product reliability performance is no longer paid to work on the previous design?

What can you do to engage the right people to implement the necessary changes?

Here are a few ideas that I’ve seen used to effectively make good use of field failures to create meaningful field reliability feedback.

What not to do

First, let’s make it clear there are some practices that are not useful:

• Create a tally or count of the number of field failures per month.
• Create a trend chart of reported calls or returns.
• Share customer complaint testimonials.
• Create goals to improve product reliability.
• Discount various types of reported failures (no trouble found or customer abuse)
• Ignore the failures as we are not going to make any improvements
• Panic
• Blame the customer

There is little actionable information in simply reporting counts of incidents. Maybe provides a magnitude of underlying issues.

Yet without additional information is a long shot to create change.

Failures will occur and our response not only may improve customer satisfaction, it may allow us to improve the current and future products.

Each failure is gold

The best reliability testing is done by the customers as they actually use the product in their environment, under the actual loads and expectations. When a customer declares a product has failed, that is a failure.

The information contained with each failure provides insights not only to the material or technology failures. It also provides an insight as to how a customer uses, expects to use and defines failure.

Remember customers define product failure, we often only guess.

During the design process, a failed prototype is often dissected to determine the root cause of the failure. We often know the history and immediate environmental & use conditions. The failure may have happened as we watched.

We do not have such luxury when the failure occurs in the field. This makes learning what exactly happened more difficult. Not impossible, though.

When a failure occurs what should we do?

A basic process may help. Is the customer safe? (If you ever called for roadside assistance, often the first question is, “Are you in a safe place?”)

Gather information about the symptoms, possible causes, and situation. Follow the normal or expected process to serve the customer, yet doing so, gather data that is relevant to understanding the failure.

With a call report or returned product, this is where we have the ability to create meaningful information for the design team. Can the customer or can we replicate the problem?

Do we know the sequence or situation that led to the problem or failure? While we may not understand the cause of the problem, what do we know and do not know about the failure?

With returned items, do the failure analysis. Determine root cause of the failure. This is not isolating the issue to a faulty part and returning the part to the vendor (this approach rarely is useful).

Instead, determine if the failed part caused the failure or simply is a victim or hero taking the damage for errant behavior elsewhere in the product or environment.

Immediate feedback to the design team

• Share the detailed root cause of the failure.
• Share the detailed description of the failure symptoms.
• Share the steps to replicate the failure.

In each case also supply the information concerning the age, environment, use profile, customer description and expectations, and as much other information as is available concerning the unit, customer, and failure.

One more thing —include the magnitude of the issue. Is the failure dangerous, does it create an unsafe situation?

Does the failure cause material or monetary damages for the customer? How often is the failure occurring? How much damage are these failures causes to sales, brand reputation, warranty expenses, etc?

Some issues are not worth addressing by reopening the design of an existing product.

The combination of fully understanding the issue and the consequences of failures, you and the design team can make an informed decision to address the problem or not.

Beyond the decision to address the existing product, you can create systemic field reliability feedback.

Two more actions based on field failures

The first is to influence the next product and the second is to influence the development process and reliability program in general.

The design team is already working on the next product. When the failure does not warrant the current product redesign, the issue may still lurk in the next design.

The information may inform the design team to identify and address the risk of the failure occurring in the next product.

Early identification lowers the cost of addressing the design change. Using the notion that a design change is more expensive with each phase of the product lifecycle, the feedback of field failures while not economical to address with designs in production, they may be quickly addressed in the next design.

Second, take a look at the development process and reliability program that permitted the conditions leading to the failure.

Did the design team not have sufficient information concerning:

• Customer expectations
• Use profiles and variability
• Environmental stresses and variability
• Material properties, interactions, or variability
• Supplier capability for component performance

The design team may have anticipated or witnessed the specific failure, yet why did they decide to not address it during the design process?

Feedback on those decisions is difficult, yet essential to improve our ability to identify and solve the problems that make a difference.

What risks or unknowns did the team accept? Which turned out to accurate, under or over, estimated impact?

Did the team dismiss, inadvertently an issue they witnessed once, which impacted a significant portion of the installed products? Why?

Summary

The ability to garner useful information from field failures is an ongoing and important function of creating reliable products to the market.

Use the information concerning field failures to:

• Determine if the redesign of an existing product is appropriate or necessary.
• Determine if the potential for similar failures will occur with the next product and mitigate or eliminate the issue.
• Determine what part of the development process and decision-making permitted the failure to occur.

We cannot avoid all field failures. We can focus on learning and dealing with failures in a constructive manner.

How do you deal with field failures? What mechanisms are in place to provide meaningful feedback to your design team?

Leave a comment and share your best practices in the comment box below.

Related:

Field Data and Reliability (article)

When to Take Action on Field Failure Data (article)

Failure Analysis: The Key to Learning from Failure (article)