Shipulski On Design

In a previous post I defined the term brand-damaging threshold and said I’d talk about how to improve product robustness. So, here goes.

Every company is at a different stage in their formalized product robustness efforts, so it’s challenging to talk meaningfully to everyone. But there are two especially meaningful principles that have served me well through the years.

I had the privilege of working with Don Clausing – Total Quality Design, The House of Quality, Enhanced QFD, and Robust Quality. I vividly remember the conversation where Don shared one of his secrets. As we watched a robustness test run, Don, in his terse way, barked out a guiding principle of improving product robustness. He said:

“Improve robustness at the expense of predicting it.”

I asked Don what the hell he meant (he liked to make his students work for it), and after some prodding, he went on to explain why it’s so important. He said people spend far too much time running tests to predict robustness and then spend even more time calculating mean time between failures (MTBF). If that’s not enough, then they spend time arguing about MTBFs and the confidence intervals. He said companies should dedicate all their time and energy improving robustness. “That’s what matters to the customer,” he said. And then he continued with something like: “Predicting robustness is worse than a simple waste of time.” (He wasn’t that polite.) But I still didn’t get it. What’s the big deal about predicting robustness?

There are several reasons why this is a big deal. Improving product robustness is hard. It requires new thinking and a singular mindset that demands focus, clear thinking, and a significant amount of emotional energy. Arguing about MTBFs distracts us in a major way and causes our thinking to shift away from what’s important the customer. Just when it’s time to make a difference, to design out a fundamental problem that has been a feature in your product, it distracts thinking away from what is important.

Predicting robustness puts us into the wrong mindset. Just when our engineering team should be relentlessly eliminating failures, driving them completely out the product, stopping at nothing to eradicate them, we start comparing MTBFs against the specification.  We tell the engineers that failures are okay and can be tolerated. Think about the MTBF specification – it’s an arbitrary level of acceptable failures pulled out of the ass of some program manager who can barely spell MTBF; it’s an acceptable level of failures. How can we flog the engineering teams to eliminate failures while we bookkeep them against an acceptable level of failures? As I tell my kids: “That’s not okay.”

In product development the schedule is king, and every second counts. Every second talking about predicting robustness is a second not improving it. And discussions on predicting robustness consume lots of time. As engineers, we think it’s sport to dig into topics just for the sake of digging in and we like to argue about subtleties. There’s plenty of fodder for that with reliability prediction. There’s that crazy Weibull math with its equally intriguing graph paper, the subtleties of assuming the right distribution so the statistics come out right, and the ever-popular calculation of confidence intervals.  All the while, the clock is ticking.

Tests to predict robustness take a long time and consume expensive, shared resources like test stations and test engineers and technicians. Every second testing to predict robustness is a second not testing to improve it. Simply put, those resources should be running tests to improve robustness not predict it.  Customers care about improved robustness not the predicted kind.

The second principle is from Don, too, though not his language – the censors would never have it. If you’re not using the words “failure modes” in every other sentence, you are not improving robustness. If you don’t define the specific failure mode you’re trying to eliminate, you don’t know what the hell you are doing. If you don’t know how and why it breaks, you can’t eliminate the failure mode.

“It’s all about failure modes.”

Mindset aside, if you focus on eliminating specific failure modes you’re on your way. But there’s a big problems with failure modes. We engineers hate them. We hate to write them down and we hate doing Failure Modes and Effects Analyes (FMEA) even more. There is no amount of cajoling that can get us to like working with failure modes, but we must learn to tolerate them if not embrace them. It’s good for us, like medicine – tastes like crap and a year later you feel better.

One last thing about failure modes. Don’t try to fix them all. Pick handful of the most important ones and eliminate them altogether.

To summarize, a strong focus on improving product robustness is magical. Your customers will notice the difference.