There is a lot to be said for having a plan. Now, I’m not saying I always operate with a plan. In my personal life, I tend to shoot from the hip, so to speak, and those that know me would undoubtedly describe me as impulsive. As evidence of my spontaneity, I can cite a few ever-morphing construction projects that had to be half redone once the final was denied as well as dinners that ended up tasting a little weird because the recipe was composed of whatever I could find. Neither of these scenarios have devastating consequences when they are over budget, late to delivery or kind of suck as far as accomplishing the original goal. We can always fix the weird porch extension next year and if you really don’t like my chicken, rice, tartar, mustard and olive dish then just order a pizza.
However, there is a time and place for impulse, and there are many things that I plan in great detail. Luckily, for my customer’s sake, that is 100% the case when it comes to product development. The reason is simple; you can’t order a pizza to make up for a commercial product that is costing (hemorrhaging) the company $6 million a year in warranty costs plus immeasurable brand damage and loss of internal resources applied to new product development. There is no amount of pizza that can fix that.
What I find surprising is how many teams I have worked with in this industry that seem to build products the same way I might impulsively make an extension to my deck over a weekend. The part that really blows me out of the water is that these same teams are often just coming out of barely surviving a product release disaster. Moreover, a disaster that has, with certainty, been root caused at its most fundamental level to not having a pre-planned reliability program.
So, for those of you who are sick of running in circles, here is a general outline for a consumer product electromechanical product reliability program plan.
Purpose:
As you know, I am a stickler for anything we do in product development and reliability having an “intent.” If we don’t know why we are doing something, and communicate it, it is unlikely that we can truly implement it effectively. There is no need to go crazy and write a thesis on how the reliability program fits into the greater meaning of life and cosmos, but it should be clear what it is interacting with in terms of the larger product development program and, additionally, why. Remember that there is always going to be pushback throughout the program to trim activities. Our justification needs to be clear and compelling in order to defend what we are planning.
Acronyms and Definitions:
One of my more popular Adam quotes is “language is the tragedy of reliability,” and it truly is. So much valuable information is lost in translation within the reliability engineering discipline. To avoid this, it is critical to make an extensive definition section both up front and in the appendix so readers can quickly look up unfamiliar terms and thoroughly understand the contents of the program.
Product Design for Reliability (DfR) Strategy:
What is the specific DfR strategy for this program? Are we developing a product that has to have high quality in production but doesn’t require high durability because it’s single-use, or is it expected that the customer is going to put the product on a shelf after 4 weeks of use (low duty cycle) and never use it again? How many Christmas toys end up in the back of a closet only to be discovered again after someone’s parents decide to take their college kids room and turn it into a home office?
Maybe it’s the other way around and we can have a low-quality production but once the product is established in its field, it can’t break down unexpectedly over a five year period. This kind of product might include, for example, a piece of ultra-delicate scientific equipment that is left on top of an Arctic mountain. I have worked on projects that were so cutting edge that the production yield was 10%, and manufacturing the device required technology that really didn’t even exist yet. It was a total guessing game. One example was a part that required cutting material under an electron microscope; the shape specification was close to the atomic level. Although everything you can cut, even an apple, is cut at the atomic level, we don’t have any technology to control a cut anywhere near that degree of precision. So, we just randomly cut hundreds of parts, selected the ones that measured closest to spec and hoped they were good enough for the final assembly. If the final assembly didn’t work, no big deal. The customer was cool with that and we would just be ready to install another assembly until everything worked correctly. But once that system was put into full service, god help you if it failed because then the customers entire high level objective would be totally trashed. Simply put, it would have been stupid, in this case, to put high quality manufacturability into that reliability program objective. Requiring such high quality in a case such as this where it is simply unreasonable to do so would have stalled the program for 20 years until we figured out how to cut at an atomic level consistently. All the while the competitor who decided to set a 10% production yield goal would have enjoyed dominating the market for decades.
Reliability Goals:
There are very few ways to get me riled up. Here’s the top three, in order.
- Tell me that a water-cooled Porsche is just as much a Porsche as an air-cooled Porsche. My Mom and I didn’t speak from 1999 to 2005 because of this.
- Do a reliability program without crystal clear metrics, use cases, uptime definitions, or reliability goals tied to product development goals. Seriously, just save your money, cancel the whole thing and send your prototype to the field. You’re gonna need that money allocated for HALT testing to pay for warranty bleed out.
- Tell me that Sammy Hagar Van Halen is equivalent to David Lee Roth Van Halen. I mean “Van Hagar” is great music, but come on. (R.I.P. Eddie, the harp ensemble must be kickin’ now).
Risk Analysis:
Formally doing risk analysis in the form of FMEAs of FTA is so important. They can be cumbersome, but the returns are well worth it. FMEAs are really a project management tool more so than an engineering tool. They ensure that the limited resources in a program are focused on the “CRITICAL FEW” and not the “TRIVIAL MANY” risks of the product.
I’ll stop there because this is supposed to be a blog post and not a thesis. Actually, if I keep going it could cut into my book sales. I laid all this out in great detail in “How Reliable is Your Product, 50 Ways to Improve Product Reliability” using language that even your non-technical leadership, like a Director of Marketing, could understand and implement.
I think this post has actually inspired me to make an abbreviated e-book pocket guide of “50 Ways” so that anyone can pop it open on their screen and take a glance when program discussion occurs. So look for that in the near future.
Below is a table of contents from a reliability program plan for reference on what the full approach may look like.
-Adam
This is what the full table of contents may look like
TABLE OF CONTENTS
- INTRODUCTION………………………………………………………………………. 4
1.1 Purpose………………………………………………………………………………………………………….. 4
1.2 Scope…………………………………………………………………………………………………………….. 4
1.3 Acronyms and Definitions……………………………………………………………………………………. 4
1.4 Product Description…………………………………………………………………………………………… 5
- DESIGN FOR RELIABILITY (DFR)……………………………………………………………. 5
2.1 Product DFR strategy…………………………………………………………………………………………. 5
2.2 Reliability Goals Parameters and Definitions…………………………………………………………….. 6
2.3 Recommended Tools by Program Phase…………………………………………………………………. 7
2.4 Design Failure Modes Effects Analysis (DFMEA)……………………………………………………….. 7
2.5 Reliability Education………………………………………………………………………………………….. 8
2.6 Reliability Allocation Model………………………………………………………………………………….. 8
2.7 Reliability Prediction………………………………………………………………………………………….. 8
2.8 Highly Accelerated Life Test…………………………………………………………………………………. 9
2.9 Sub-assembly Testing………………………………………………………………………………………… 9
2.10 Reliability Growth…………………………………………………………………………………………….. 10
- QUALITY ASSURANCE IN PRODUCTION……………………………………………… 12
3.1 Maintenance and Diagnosis Strategy…………………………………………………………………….. 12
3.2 Preventative Maintenance (PM)……………………………………………………………………………. 13
3.3 Environmental Stress Screening (ESS)………………………………………………………………….. 13
3.4 Highly Accelerated Stress Screening (HASS)…………………………………………………………… 13
3.5 Monitor Critical to Quality (CTQ) Parameters…………………………………………………………… 13
Leave a Reply