More often than we think, customers who aren’t even trying to Use Case 7 our products seem to end up doing so regardless.  That’s fine, it happens. However, it also tends to result in $1 billion + lawsuits that could have easily been avoided.

The big question is, who do YOU blame? I mean you, the person reading this article. When your team discovers a field failure root cause to be user error do you either:

1. Investigate a way to minimize the likelihood of it happening again through design improvement or some other means?
2. Mark the investigation as “bad customer” and move on?

[Read more…]

I recently held a lunch and learn about infographics. The recorded session is below. In our work as engineers, we often spend a great deal of time extracting amazing information from complex data sets only to find no clear way to get our message to those who need it which can include leadership, peers, or even the customer.

Changing how we present information can be the difference between driving change and simply being a slide in a weekly status meeting that solicits the response “next.” 

[Read more…]

There are many scenarios that can arise throughout product development programs. There is one in particular that I have seen unfold more than once: I call it the “Plus one program.”  Don’t let the name fool you; it’s horrible to watch unfold.

A startup or established player introduces an impressive jump in industry-standard technology, or sometimes an established player introduces an innovation to their industry. Since the technology is so innovative, there is great value in getting it to market quickly even if it isn’t a mature design.  In this case, it is actually a smart move to go to market with a device that doesn’t have “ideal reliability.”  In other words, the value of getting it out there quickly is worth the field issues. Those issues will be tolerated by the customer as well,  if the technology is that good.

[Read more…]

The fist part of this post you likely already know.  It’s the second part that may be helpful.

I love HALT testing and almost always include it in a new program.  With a team new to the concept there is always the hurdle of getting them to understand it’s value.  It’s not intuitive to see value in destroying a product with stepped stresses.  Often these stresses aren’t even apart of the product’s use case. Why vibrate a lab electronic device that spends its entire life on a bench? Seeing the failure mode is a capacitor flying off the PCB at 50 G’s doesn’t reinforce the value of the activity without some explanation.

[Read more…]

A helpful analogy  in communicating the concept of statistical reliability confidence is the “new airplane” example. Let’s say I am developing  an entirely new technology for airplanes. The airplane has an engine that has never been used before for air travel; a fusion engine. I tell the world that this new airplane with a fusion engine will have a reliability of 99.99999999%, the highest any airplane has ever had. It’s not possible to fully demonstrate this reliability until every single unit of this airplane has been produced, used to full life, and the full fleet is retired.  As long as one is still flying it can add or subtract from the reported reliability number.  So, how do we make decisions at product launch regarding the design’s reliability?  No products have yet to be produced or used by customers, so how can we trust the design?

[Read more…]

Sometimes we can only test one use case before we ship our product. So what should it be? Should it be the hardest use case? The nominal use case? The 95th percentile use case?

No! It should be the “midlife crisis use case.” What is it? I’ll show you.

[Read more…]

Disappointment, Loss, Anger, Frustration, Fear, Discouraged

This is a direct followup to my post last week.

I usually don’t do two part posts but….

I got some great responses to my post last week.  I then got this image from my buddies at NASA (on the ground, not on the space station). One is actually my roommate from college. His hair is much shorter now.

[Read more…]

Sometimes I see images that speak strongly to how reliability engineering affects us everyday.  Think of how many items you own or use systems that you wouldn’t touch/interact with if  you couldn’t be absolutely sure they would work as expected. I wouldn’t use my microwave if I thought there was a 1/1000 chance it would catch fire.  The amount of faith I have in traffic lights working correctly is astounding.  If they malfunction it could be fatal.

[Read more…]

The clock in my ’79 Porsche 911 works perfectly. I don’t remember the last time I set it.  Maybe I made a small adjustment six months ago, a year ago, don’t know?  A modern day quartz clock does this no problem, a mechanical spring clock might struggle in such a rough environment.  So was it quartz or mechanical? the ’70s was when quartz came on the scene, so either was a possibility. First I wanted to find out if it was ever replaced or serviced. So what did I do?  I contacted the previous two owners.  One purchased it new in ’79 and the other owned it for a five year period before I bought it. Neither recalls it ever being serviced or having a problem.

[Read more…]

I have a customer that has developed an impressive wrist worn biometric sensor for athletes. The system is worn on the athletes wrist, like many other personal devices. But this product is for serious athletes that aren’t just looking for non-descript data like step count and heart rate. What are you even supposed to do with that information?

[Read more…]

“What’s the MTBF of a Human?” That’s a bit of a strange question?

I ask this question in my Reliability 101 course. Why ask such a weird question? I’ll tell you why. Because MTBF is the worst, most confusing, crappy metric used in the reliability discipline. Ok maybe that is a smidge harsh, it does have good intentions. But the amount of damage that has been done by the misunderstanding it has caused is horrendous.

MTBF stands for “Mean Time Between Failure.” It is the inverse of failure rate. An MTBF of 100,000 hrs/failure is a failure rate of 1/100,000 fails/hr = .00001 fails/hr. Those are numbers, what does that look like in operation? [Read more…]