If your livelihood consists of providing MTBF upon request, what good is your service?
Sure you earn some money, yet did the customer receive value in the transaction? As you know, or should know, MTBF is so commonly misunderstood that it is likely the customer confused what they want, reliability, with MTBF. Providing them MTBF does not answer their question.
Worse the customer thinks they got something of value and blithely heads off with rather meaningless information.
My contention is by providing MTBF because customer’s request it is wrong. We know better. Those performing predictions, doing data analysis, and other reliability engineering work know that MTBF is a faulty and rather meaningless metric often confused with reliability, R(t). (probability of success over a duration).
Part of providing a service and value to customers is helping them actually solve problems and improve their ability to create a reliable product. Providing MTBF does neither. Asking your customer what they really want and will use the information for allows us to provide R(t). Something that is useful.
The Customer Expects MTBF
One view of business is to offer the custom exactly what they request. Don’t ask questions, don’t question the validity of the customer’s request.
The customer is always right.
Well if they are asking for MTBF, they are likely not right.
Every time someone asks me for MTBF I ask they want they really want to know. How do they expect to use the MTBF value. Every time they describe something that MTBF cannot provide or help to answer. Every time I describe R(t) and they say that is what they really want. They want to know the chance of their product surviving over some duration.
I often ask how does their product fail – they never describe a random and constant failure pattern. They describe issues with installation, early life failures, wear out, and degradation patterns. MTBF is not able to describe these behaviors in a meaningful manner.
The customer may request MTBF yet they want information to help them make decisions. They want something that describes the reliability performance of their product over time.
In consulting, we often ask questions to fully understand the clients initial request. We know the initial request is likely not the real issue that needs to be solved. A few questions helps the consultant and client determine the underlying issue that should be solved to make a difference.
Ask you customer that is requesting MTBF, what they really want.
The Customer Only Pays for MTBF
A comment on a previous NoMTBF article included the situation that the customer would only pay for MTBF. They expected and only would pay for a report or component that included MTBF.
If the condition of sale is MTBF that does not preclude you also providing a warning that the MTBF value may be of little value, provides limited information, and may not reflect the reliability performance of the item. Then provide the R(t) formula or graph which provide value, information and a description of reliability performance.
I like the idea to add a warning. Hopefully, the customer thinks about the value of asking for MTBF and instead asks for reliability in the future.
We’re Providing What The Customer Requests
Sure, part of business is satisfying the customer. Providing what they request is great. Providing what is of use is better.
When questioned, your customers probably are interested in the reliability performance of their product or system. They want to know the chance of failure over a duration ( 1 – R(t) ). They may want to understand the probability of mission success, or have an idea of expected failure rates to stock spares. They need accurate and reliable reliability performance information.
If your service can only provide MTBF are you helping your customer to answer the questions they have about their system? No. You are providing a crude and often mis-understood value that oversimplifies, leading to poor decisions.
Instead provide what the customer needs. Provide some education to help them improve their design and reliability performance. Instead really understand what the customer needs, not simply requests, and provide a meaningful and useful solution.
How do you request reliability information? How do you respond to requests for MTBF? Add you comments below and let’s share best practices around requesting and providing reliability information.