Is Reliability Just Testing?

Is Reliability Just Testing?

14597483807_4d45aa3e9e_oI endured a difficult conversation with a project manager yesterday. The meeting agenda included an initial discussion about the product development reliability plan. She agreed that we needed to identify risks and provide feedback to the team concerning product reliability.

And, we talked about sample sizes for environmental, discovery, and life testing. When I brought up FMEA, modeling, simulations, derating and stress-strength analysis the conversation became difficult. I expected push back on sample sizes, which occurred. Yet, we really didn’t connect concerning the reliability tools outside of testing.

At one point, she asked me to focus the reliability plan just on the testing elements.

It became apparent that she thought the role of a reliability engineer was to conduct reliability related testing, and that was all. Furthermore, she believed that the testing alone would prove the product would perform reliably over time.

The design and engineering of the product was separate from reliability performance in her mind.

Of course, I argued that the reliability performance of a product was primarily a function of the design. This countered her experience that testing was the only way to identify problems that, if the team had time, would be able to remedy. The design team’s focus was on creating a product on time that met the product specifications.

We then opened the product requirements document and found a passage on the reliability requirements for the product. Than the discussion became more difficult.

Resistance to Engineering in Reliability

Once in an interview for a reliability engineering position, the hiring manager asked me how I would go about improving the reliability of the product. I started to discuss working with the design engineers to help them make good decisions considering the impact on reliability performance. He stopped me right there saying I would not be allowed to interfere with the design engineers.

I thanked him for his time and left. Later that team launched a product that enjoyed a very high field failure rate, in part due to design decisions that made the product prone to break. (As much as I would like to say, “I told you so…” I’ve resisted calling that hiring manager for a chat.)

On another occasion a director of engineering resisted having a reliability program assessment that included talking to electrical and mechanical design engineers. He claimed that he hired the best engineers and they could only create reliable products. The results spoke differently.

Engineers tend to design items that they would like to work and work over time. These engineers have wonderful skill in what they do to create a new product. Unfortunately, considering how a product fails is not their speciality.

Building a supporting structure and set of engineering practices around these engineers is how reliability engineering actually improves reliability. This may be a significant change for some organizations, yet one well worth doing to create reliable products.

Product Reliability Is Not Just Testing

Just as you can not test in quality, reliability testing only reflects an estimate of the current reliability capability. Often reliability testing is too late and too little to catch and fix problems.

Reliability occurs at the point of decision — the choice of a component, the selection of material, for example — by the design engineer. Not later when considering test results.

In order to improve the reliability performance of a product, it has to be designed into the product.

If you are doing just reliability testing, you have a difficult challenge ahead when trying to improve the reliability performance of a product. You have to influence the decision making process well before any prototypes become available.

So, get out of the test lab and go talk to a design engineer today. Find out what they need to make decision that improve product reliability. Help them ask and answer better questions concerning reliability. Help them become part reliability engineer in their daily work.

About Fred Schenkelberg

I am an experienced reliability engineering and management consultant with my firm FMS Reliability. My passion is working with teams to create cost-effective reliability programs that solve problems, create durable and reliable products, increase customer satisfaction, and reduce warranty costs.

7 thoughts on “Is Reliability Just Testing?

  1. I think most reliability engineers would agree that design improvement is fundamental to reliability improvement. I think another point is that the earlier in the design phase that any potential reliability issues can be identified the easier of less expensive they are to correct .

    1. Thanks for the comment Jim, and full agreement here. It often is getting the message across that the early investment in solid reliability design will pay off long term, when there are so many other immediate priorities facing the team.

  2. Good article, Fred ! I have heard that statement about not bothering the engineers. However, it’s really important to talk with the engineers, and build up a rapport. Going to design reviews helps. Everyone is so busy, and so stressed out, they often don’t have time to discuss designed in reliability

    1. Hi John, good to hear from you and thanks for the kind words and comment. yes, we’re all busy, and helping those busy engineers remember to consider the reliability impact of today’s decisions is key. cheers, Fred

  3. I understand the collaboration with the design team is necessary but not only to give input to the designer, but also to learn form the way the designer implement the product features. So a better inside on physics of failure and test setups can be made.
    In this way you can also improve you testing techniques and failure predictions.

    In quality minded organisations the designers are already using design rules. This makes the life of the reliability engineer more easy.

Leave a Reply

Your email address will not be published.