The Fear of Reliability
MTBF is a symptom of a bigger problem. It is possibly a lack of interest in reliability. Which I doubt is the case. Or it is a bit of fear of reliability.
Many shy away from the statistics involved. Some simply do not want to know the currently unknown. It could be the fear of potentially bad news that the design isn’t reliable enough. Some do not care to know about problems that will require solving.
Whatever the source of the uneasiness, you may know one or more coworkers that would rather not deal with reliability in any direct manner.
Is ‘Reliaphobia’ a Thing?
Maybe not directly, yet the symptoms seem to be there. A set of avoidance concerning the topic. The lack of focus to understand or improve reliable. The dismissal of estimate or test results. The rush to ‘put right’ any life-limiting problems.
The general desire to move on or away from detailed discussions concerning reliability is a clue. This may be difficult for reliability professionals to grasp as we tend to enjoy understanding failure mechanisms. We tend to work to estimate or analyze reliability performance. It is what we do.
Other than the math, does mechanical engineering engender such avoidance? For power electronics, a bit of fear is good, as touching a live circuit could be fatal. Discussion a plan to improve reliability performance may require a bit of thinking, yet certainly isn’t dangerous.
Maybe there is a fear of reliability at work around us.
A Personal Fear
Maybe those we work with avoid little more than saying reliability is important and avoid understanding reliability because it may lead to more work or reflect poorly on their design.
If you have been part of an FMEA discussion, you may have noticed the uneasiness of the person responsible for the design. The group of people around the table one by one describe potential weaknesses or flaws with the design. We’re basically saying the design may be inadequate, which in a way is saying the designer is likewise inadequate.
Few enjoy such sediment from their peers.
Others may see the highlighting or understanding of a design’s reliability performance as just another way to add work to an already busy timeline. I did once work with a project manager that didn’t want to perform any testing to failure. One, failures are bad and we don’t want to have failures. Two, any weaknesses or flaws that would limit the life of the product would require additional time to understand and solve. Time that just was not available.
The less he knew the better the development plan (fictitious that it was) appeared.
An Organizational Fear
We set up systems and processes within organizations to facilitate decision making. We attempt to provide just the right information at the right time to permit moving forward with a project.
At times we learn about field failures that may or may not lead to major warranty expenses. The ability to recognize, understand, and report the problem all too often relies on individual heroism. The organizational system tends to provide a local focus and avoid spotting and dealing with reliability issues.
All too often the customer service team, dealing with product failures on a daily basis, does not delve into root cause analysis or time to failure tracking. They focus on helping the customer get working again or ship them a new product.
All too often the operations team focuses on yield improvement without paying attention to the latent defects they are shipping with each product.
Likewise, the development team focuses on delivering new designs on time and within budget with little more than a cursory review of the few field issues they have heard about at some point.
It is rare that an organization establishes the appropriate systems to encourage the identification, understanding, and systemic resolution of failures. Failures are bad and we don’t like to talk about bad things.
Summary
I do not think ‘reliaphobia’ is a condition that our medical community will offer a remedy. It is up to us to identify and cure the condition.
Oh, on MTBF. I suspect it is that easy to use, no need to understand, metric that does a fine job hiding the problems and limiting understanding that supports the fear of reliability condition. If your organization uses MTBF, it may be a coping mechanism that they are thus ‘doing’ reliability.
Setting up systems, reporting, education, and encouragement all seem to reduce the fear of reliability. A steady dose of solving problems and getting great results is another sure path to curing the condition.
Is the fear of reliability rampant in your organization? What steps are you taking to cure the local condition?
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. If you enjoyed this article consider subscribing to the ongoing series at Accendo Reliability.
Improving Product Reliability through Coaching & Training | Owner and Principal Consultant
4 年Thanks Fred for an inciteful read on an important topic. I think Reliability Engineers (RE's) understand the old adage that it's difficult to improve something (say the durability of a product) if you cannot measure it. Most I think understand this but fall back on the simplest of metrics (MTBF) when faced with other more useful reliability metrics that may appear somewhat confusing. Our job as RE's is to bridge the gap with clear and concise explanations of these metrics.
Principal at Prelical Solutions, LLC.
4 年Love the term ‘Reliaphobia’, thx Fred Schenkelberg, great read!
I think you make it clear in this article there is a "testaphobia" which is why many still want to test to spec only.
Manager product reliability engineering at Bosch
4 年I recognize all issues that you point out. In my experience, the power of reliability engineering is in early engineering phases; for a great deal in the hands of the designers. Failures during classical validation testing at the later project phases is what is killing project schedules, which is why project leaders tend to be weary of such tests. Motivate the developers to change from 'function' to 'function over time' and help them understand the boundary conditions (loads, usecases, physics of failure).