The 3 Best Reasons to Use MTBF

This may seem an odd article for the NoMTBF site. Stay with me for a moment longer.

Over the years of speaking out on the perils of MTBF, there has been some pushback. A few defend using MTBF. Here are three of the most common (maybe not exactly the best, per se) reasons to use MTBF.

MTBF is Easy to Use

I have to agree, MTBF is easy to use. It’s a simple average. There are many textbooks and sites explaining how to use MTBF for nearly any circumstance. Plus, you avoid any backlash by not using something so easy to use.

It is in the simplicity that we lose or mask the very information we need to make decisions.

The common assumption that we’re in the flat part of the curve to justify using MTBF is rarely checked. That would not be easy, apparently.

If what we want is to use our data and information concerning the durability of an item to make a decision, maybe we need to work a little more than just the easy way. Sure using a cumulative plot or Weibull CDF may require gathering time to failure data, not just the count of failures and operating time, yet it provides so much more useful and relevant information.

Using reliability (probability of success over a duration…) is also easy. Sure, not as easy as using MTBF.

Making good decisions is really the goal here and repairs, rework, recalls, and the like is not my idea of easy at all.

Get the data, do the math and create the plots that is just a tad more difficult than calculating MTBF. Make good decisions concerning reliability and your business.

Everyone is Using MTBF

This one always makes me think of my mother’s comment to this argument (which I’m sure to have used in grade school, such as, “well everyone is letting their hair grow long, or everyone is going to the beach tonight). My mom would retort something along the line, “if everyone was jumping off a bridge, would you?” or something like that.

As a teenager, my friends and I did jump off a bridge which was about 2 meters above our favorite summer swimming hole, yet, that wasn’t my mother’s point. She was suggesting that I think for myself. Not blindly follow the crowd.

In a discussion with a professor teaching the in’s and out’s of MTBF, he suggested that because MTBF is so common, and it was so easy, it was a convenient means to introduce reliability distributions, functions, and basic concepts to his students. Plus, he added, MTBT is in all the textbooks, standards, software, and certification programs.

Seems we have a vicious cycle. It’s everywhere so we have to teach and use it.

Well, you don’t.

If you want to understand your system reliability, make improvements, or anything remotely useful, do not use MTBF. Just because Jimmy jumped off the bridge does not mean you have to do the same.

My Boss or Customer Requires We Use MTBF

It’s required. Hard to argue with that.

You may even have a solid understanding that MTBF is the wrong metric to use. Are you willing to alienate your customers or risk your job? Probably not the best move, so use MTBF.

AND, use the data and information appropriately to make your proposals, recommendations, improvements, etc. When possible report both the Weibull CDF plot or reliability value over the duration of interest along with the MTBF value.

I did this a few years ago when a client insisted they need to use and report MTBF values to their customers. The MTBF value was something like 10,000 hours. They offered a three-month warranty yet knew their clients would use the product for at least a year and longer in many cases. The reliability over a year of use was close to 40%.

My client thought the 40% reliability over a year sounded pretty bad and didn’t want to report that value to their customer. The 10,000 hour MTBF sounded much better.

Use the very common textbooks and readily available online formulas and calculators, convinced my client that the two values were really the same. Any of their customers could quickly sort out the product they were offering has over a 50% chance of failing over the first year of operation.

The decided to focus on improving the product reliability in the design phase and would consider reporting reliability instead of MTBF as it provided an easier to understand metric.

Maybe reporting reliability along with MTBF is a form of tough love. I do want those I work with to understand the data, estimates, predictions, clearly. Using MTBF with those that do not know what it represents, even when they demand the use of MTBF, is not in service to them or the decisions they are making based on the data.

Summary

Granted these reasons to use MTBF are not all that compelling when you step back and look at what those defending the use of MTBF are really trying to accomplish. To be of value to our teams, customers or clients, we need to represent reliability information clearly.

Thus, despite the rationale offered to use MTBF — you must resist.

What reasons have you heard for using MTBF and have you spotted the flaw in the rationale? Share your experience in the comments below. I’d love to hear from you, plus it helps to let others know they are not alone in our journey to eradicate the mis-use of MTBF.