Reliability goals are often communicated in Mean Time Between Failure (MTBF) 40,000 hrs, Failure rate 0.00035, or percentage still functioning over time 99.98%. If you are not familiar with actually calculating these numbers they really don’t mean a lot. Are any of those above numbers good? bad? something we will even measure before release?
Are any of those above numbers good? bad? something we will even measure before release?
I calculate this stuff and sometimes I don’t know how to react. “Hmm look slike it has a failure rate of 0.0049 , and I feel like this will make the customer happy? no maybe unhappy? wait what does the customer consider good?. So without context the number doesn’t mean much. But the context seems to take some work each and every time the reliability is communicated. You can see it is the room when it is presented at an update. Everyone is trying to make that neutral face so they can’t be called out for having the wrong reaction to the number. Come on you’ve been there!
How about we go that extra step and present teh reliability goal or measured value in context. Change the scale from hrs or decimals or % and have a scale that includes what you care to compare it to. Put it next to the performance that the goal was derived from.
If the goal was created based on market analysis and a desire to drive market share with improved reliability, then that’s how it should be presented. because that is what the audience cares about.
- “Our new luxury car model is showing a demonstrated reliability of 99.999%” ” Ah Bob, I have no idea if that is good or bad. Can you just tell me how we are doing? Can we release on time?”
- “Our new Luxury car model is at an index of +2 over our target market share goal.” “So Bob sounds like you are saying we have room to either shorten the development schedule or look for some more cost reduction opportunities.”
SO what would a scale like a reliable target index look like. it would like many other indexes. The objective of an index is to give you a comparative value to a known mark. So if we establish a reliability goal in the program in MTBF hrs, Fail Rate, or Rel % we can place it at “0” on the index and then create a scale for max and min that would be a realistic range of outcome as the product develops and releases. The lowest Index number “-10” which would reflect an indication fo performance that is likely to require a significant redesign. “+10” index would indicate that the Reliability team has clearly taken over by force (hostages?) and someone needs to step in and implement some good cost reduction, feature add or early release initiatives. Too much reliability just means the team is not capitalizing on other program or product opportunites.
Leave a Reply