Your Reliability Engineering Professional Development Site
A listing in reverse chronological order of articles by:
I just returned from a great conference in Stuttgart called “Reliability Days.” I presented on some new concepts and techniques with regard to assessing and improving reliability culture in the product development process. Enjoy the presentation.
-Adam
I was recently talking with my colleague Fred Schenkelberg from FMS Reliability (this conversation can be heard here), about a plane that he had never heard of. Most of the world hasn’t heard of it. And there is a reason you probably haven’t either. The plane in question is a case study on how to design something to fail.
I have heard that “Reliability and Quality are kissing cousins” and also that “Reliability is Quality over time.” Neither of these definitions ring true to me. To be honest I’m a smidge offended because both of these terms diminish the value of the objective of reliability. I would state that reliability is “The design of a device or system so that it works as intended consistently over it’s defined use-life.” To me the key differentiator from my definition and the previous two descriptions of reliability is the word “design.”
We all would like a clear path to achieve what we need. But we all know that it’s not the clear sections of the path where we spend most of our time. In product development many of these events we label as “obstacles” are in fact other individuals.
If these team members are noted as being strong enough to be considered an obstacle that means they have strength. This is a good quality in a team member. If we were to get ourselves headed in “generally” the same direction a lot of progress could be made very quickly.
There is no question that standardizing processes, techniques and best practices has contributed greatly to technological evolution. Just writing down or passing on what has worked well in the past helps anyone’s learning process. But there are many problems associated with this approach when blind obedience kills critical thinking.
If you finish the Design Failure Mode Effects Analysis (DFMEA) before the product is out in the field, you have made a horrible mistake. The worst DFMEA that can occur is one that is completed and filed away mid-program. A high value DFMEA is a live tool that has both inputs and directive outputs throughout the program. A tool that is interwoven into the day to day activity of the program. The DFMEA drives actions and aids decisions both technically and in project management. It is updated with design changes that change risk and mitigative strategies.
I was reading an article recently about Apple MacBook Pro keyboard issues, affecting the current generation of products, on which this article is being written. I also have an iPhone sitting next to me playing “music” whilst I wait for a call-center agent to reply on a travel issue. In both cases, I am dependent on their correct functioning. My past experience across many products is that my overall experience is also dependent on how product support is delivered in case of hardware failure.
Design and business choices strongly affect in-life support capability. They affect not only the basic ability to repair a product but also, through the cost and availability of spare parts, the economic policies for repair.
How do we influence and make these choices?
I joined the Reliability Belt training team in 2018 and have delivered 2 Reliability Green Belt and 1 Reliability Black Belt courses so far. This is article is a review of my experience and the feedback from the participants. Further information about the course is available on the Accendo website and on the Reliability Engineering Academy website.
This first article looks to the Reliability Green Belt. A future article will look at the Reliability Black Belt experience.
“Les, you were awesome. One of the characteristics I liked the most was your cadence of speech. The metered delivery of each word and concept was very effective for me and my style of learning. If the words and concepts get delivered too quickly, I don’t have enough time to connect with the concept, write down my notes, and still keep up with the next thing being said. I found your analogies and examples of real world applications to be very relevant and helpful. Overall, I feel I have received value well above my expectations for the course, and with your instruction I was able to hit the ground running on the first day I got back. Thanks for teaching the course, and I look forward to continuing my education with the Reliability Black Belt program.” — Chris, Reliability Engineer
When is the biggest ‘improvement’ in the reliability of a new ‘type’ of product? This is a very broad question with no doubt lots of answers that aren’t wrong. But what we do know is that the more experience we have with building something, the more reliable it gets. And this effect is most marked at the start of the product’s life. [Read more…]
InnoCentive CEO Dwayne Spradlin wrote in this article about how many companies in a rush to develop something new and innovative try to solve a problem that they want to solve rather than the problem the customer wants to be solved. He quotes Albert Einstein who once said
If I were given one hour to save the planet, I would spend 59 minutes defining the problem and one minute resolving it.
The formal definition of reliability is …
“The probability that an item will perform its intended function under stated conditions, for either a specified interval or over its useful life.”
The three key terms in this statement are
Imagine you are not feeling well and you go to a doctor. When you sit down in the doctor’s office, he doesn’t even look at you. Instead, he has a book opened on the desk and starts reading it aloud. You sit there without being examined, listening to a list of medicines, activities, exercises and diet changes. The doctor then looks up and says that you need to do all of them. Take all the medicines. Change all your activities. Start doing all the exercises. And completely change your diet. [Read more…]
In the late 1970s, Hewlett Packard was a company that valued quality compliance, certification and awards. But the then Chief Executive Officer noticed a problem. He (on a hunch) initiated an analysis of ‘quality related expenses.’ He wanted to quantify the cost of defects and failure. The results were terrifying. [Read more…]
In 1995, the United States Department of Energy (DoE) funded research into Princeton University’s Plasma Physics Laboratory (PPPL). PPPL was developing plasma fusion techniques, and the research in question focused on quality assurance within the laboratory. It was investigating the utility of a new type of quality assurance: on that was performance-based. [Read more…]
The effectiveness of “Design for X” (DfX) methodology is often limited by the non-negotiable “freeze” gates in the product development process. Freezes become points of negotiation instead of directing scheduling and resource decisions. Design changes continue past “design freeze” commonly resulting in an inefficient multi-iterative process.
A design freeze is the wrong tool for the job. Design Freeze is a “Put your pencils down” methodology. This leaves no room for input to the decision to halt activity other than what was available when the freeze gate was set. Often a good deal of new information about the design and program has been created between the program creation and the freeze. [Read more…]
