I was recently asked by a product design engineer why their organization struggles with reliability even though they have a very ‘robust’ design process that seemingly has lots of different ‘good’ reliability engineering activities embedded in it. And when I say ‘good’ reliability engineering activities, I mean activities that have (in the past) shown to have a really good impact on reliability.
When I looked at some of this engineer’s processes as summarized by a ‘process flow chart,’ the reason his organization struggled with making reliable products was quite obvious.
The process was so complex that it became the ‘product.’
What this means is that the process required so much time, effort, study, obsessive review of standards and lots of other things that being able to say we ‘completed the process’ became an overwhelming relief. If much of your project involves preparing for design review boards, qualification testing, reliability reports, PowerPoint presentations with more than 100 slides, reliability allocation efforts that last more than a week and so on, then engineers are already exhausted before they even think about actually making something reliable using their own inquisitive brains.
If your engineers are going to get exhausted … make sure it is from designing and manufacturing amazing products. Not ‘ticking the boxes’ your process says they should.
How do you know if your process is too complex? There are lots of indicators. The first is that you ‘import’ process elements from somewhere else. One example is the old Military Standard 785 B – ‘Reliability Program For Systems And Equipment Development And Production.’ This standard has been removed from service for over 40 years, but many organizations blindly copy ‘word for word’ the standard in the hope it will result in an amazing process.
The second indicator is that the process is seen as a ‘safety net’ to catch all ‘reliability problems.’ This is not possible. At best, your reliability process can test for and identify problems from your previous products or models. Remember that solder joint problem we had two years ago? Well now we test every solder joint. But testing doesn’t improve reliability. Presumably, you have resolved the solder joint problems through ‘corrective actions’ that should be part of a new and better way of doing things. But now all the new problems of your most recent product aren’t being tested for because your process has not had time to include them in your test plans. And instead we keep testing for problems that have already been solved.
The third indicator is that there is a (mis held) belief that following the process will guarantee a reliable product. Why is this bad? Because now there is no critical thinking. Everyone is on autopilot as they grow very tired from ticking every reliability box.
So what is the solution?
It starts with coming up with a process that focuses on finding the vital few problems that are going to destroy good reliability performance of your product. Every product has them, and no process (of itself) can predict them. Many of the most successful companies whose profit is built on reliability performance have remarkably simple reliability engineering philosophies. And when I tell this to engineers from those organizations with monstrous reliability processes, they simply don’t believe me. In fact, many of the most ‘reliable’ organizations never even bother to measure reliability.
You must create a culture where engineers, designers and manufacturers are trained and encouraged to identify the vital few weak points as early as possible. And yes, this means before your first design or process flow. And yes, this is possible. If your people are smart enough to be able to design something that should work, they should also be able to predict with reasonably accuracy where it might fail.
There are two keys to this. The first is that leadership needs to trust its engineers … and their ability to critically think. This means wrestling trust away from the process and instead placing it on sentient beings who are prone to both genius and mistakes. And the second is to invest in a process that streamlines the process of identifying weak points early. Simply pondering about the millions of different ways your product can fail won’t help. Tools like fault trees and Failure Modes and Effects Analyses (FMEAs) can be great for this. But remember – these are group activities that need dynamic and well prepared facilitation. Simply relying on standards and following the ‘bouncing ball’ to generate outputs that look like they are robust is simply reverting back to the problem you are trying to avoid.
The sad reality is that processes are symptoms of a disengaged leadership who don’t want to spend the energy it takes to create a culture of critical thinking. Nor do they want to engage with and develop engineers whom they can trust. Processes are easy to ‘delegate’ to someone else to create.
And delegation is not leadership.
Leave a Reply