Consider the Decision Making First

If no one is looking for the results, then don’t do it

Published: Wednesday, July 18, 2018 - 12:02

Reliability activities serve one purpose: to support better decision making. That is all they do. Reliability work may reveal design weaknesses, which we can decide to address. Reliability work may estimate the longevity of a device, allowing decisions when compared to objectives for reliability.

Creating a report that no one reads is not the purpose of reliability. Running a test or analysis to simply “do reliability” is not helpful to anyone. Anything with MTBF (mean time between failures) involved... well, you know how I feel about that.

The Type III error

A common problem in engineering work is the desire to solve the wrong problem. I know I am guilty of working on the issues that hold my interest rather than on the challenges requiring action. A Type III error is when you solve the wrong problem.

We only have so much time and resources for reliability work. There are plenty of challenges and interesting aspects of sorting out the reliability of a system. However. it is the focus on solving the right problems that matter. It is solving the right issues that provide value to the team and organization.

For each action you plan or execute in a reliability program, ask if it is something you are doing because you want to, or because it will add value. One trigger to ask this question is the “we always do this test” concept. If you are tempted to build a plan based on previous plans or add activities and tests because, well, you always do those activities and tests, then stop. Stop and think through how those activities and tests will be used, by whom, when, and to what effect.

Pending decisions drive action

The key is to connect every activity and test to a decision. For example, if you are interested in conducting an accelerated life test (ALT) on a new technology, is there someone looking for the results of that ALT to inform a decision? In some cases, the decision may be to abandon the new technology if it isn’t reliable enough, or it may mean selecting a different technology.

Once you find the pending decision, then you will know who needs the information, the expected quality of the information, and when it is due.

From FMEA (prioritizing work assignments across the team) to field data analysis (Do we need design improvements?), each and every action we propose or take must connect to a decision.

MTBF and decisions

Let’s say we’re asked to create a reliability goal for a new product. Let’s explore who the stakeholders are in this case.

Customers want a reliable product and on occasion may ask for it via mean time between failures (MTBF). If asked, they actually want something else yet do not know how to articulate it. Providing them with a goal stated in MTBF is simply misleading them and allowing poor decision making.

Managers want a reliable enough product to both please customers and avoid undo warranty costs. Again, they want a product that lasts a long time with a low failure rate, not MTBF. If asked, they may ask for MTBF thinking it is a term used to request reliability information. As you know, it’s not, and providing them with MTBF values further confuses their understanding of product performance.

Engineers want to create a product that meets both customer and business expectations, including being reliable. We often break down reliability problems into two groups—early life failures and wear-out failures. Neither are well described by MTBF, so don’t try. Use reliability for the salient time points in your product’s life.

Vendors want to provide the right components to meet the design’s intent. They want to accommodate requests for reliability and often provide MTBF, as that seems to satisfy most requests. By asking for reliability rather than MTBF, you can learn more about how the component may actually perform in your application.

In each of these cases and in others, we’re talking about reliability; thus, use the probability of successful operation over a duration for a given function and environment. Help those interested in creating or using a reliable product actually make useful and meaningful decisions with a clear measure.

Summary

The same logic holds for any reliability activity. First think about the decisions involved with the results of the activity. Then craft activities that fit within the constraints and deliver suitable results to assist in better decision making.

From goal-setting to FMEAs, to HALTs (highly accelerated life tests), to field data analysis—if no one is looking for the results, then don’t do it. Help your team by improving the information they have, to make decisions.

About The Author

Fred Schenkelberg

Fred Schenkelberg is an experienced reliability engineering and management consultant with his firm FMS Reliability. His 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. Schenkelberg is developing the site Accendo Reliability, which provides you access to materials that focus on improving your ability to be an effective and influential reliability professional.