Your Reliability Engineering Professional Development Site
The Apex Ridge article series covers a diverse set of topics that relate to many of our reader’s work, interests, and experiences. The articles are inspired by industry experiences with the intent of sharing, educating and assisting you with your career challenges and growth. The content is targeted for a diverse audience with backgrounds even extending beyond engineering (Hmm talking to you project and business managers). My hope is that these topics inspire you to have discussions with your colleagues or right in the comments of the series. I look forward to seeing you on-line soon.
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 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.
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.
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
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.
The “design freeze” principle is driven by the proposed benefit of increased efficiency through reduction of schedule creep. Both time and money can be lost as serial program phases are stalled due to incomplete predecessors. Common freeze gates are “Specification Freeze”, “Concept Freeze”, “Design Freeze”, and “Tooling Freeze.”
It is important to distinguish between internal freezes that are the result of dependencies, and external freezes like lead times that are imposed on the design process. Quality control norms like ISO 9000 require a freeze point for change control to distinguish between the design phase and change implementation afterwards. Certifications like UL and FDA are also often positioned post freeze.
There are phases to freezing. The program leadership will begin to express restrictions on changes as the freeze approaches. This may be called a “Chill” phase. It is marked by an increasing needed justification for design and process changes. As the actual freeze gate is approached it will take higher authority to approve activities that threaten the planned schedule.
I believe DFMEA’s offer an interesting structure to approaching how to take action based on risk that may apply here. All the risk that is captured in a Design Failure Mode Effects Analysis (DFMEA) is associated to risk to the product or the end user. The “Severity” score relates to event in the field, injury?, inconvenience?, loss of revenue? The “Occurrence” ranking correlates to either a speculated likelihood or a projected percentage of failure based on test or analysis. What about using that methodology of creating a quantifiable measurement of risk factors and applying it to decisions on program schedule and budget?
Previous to the introduction of the DFMEA method teams still accessed severity of failures and the likelihood of occurrence. This happened in informal conversation, special meetings or simply by the coffee pot. By acknowledging that this process of accessing risk through metrics, instead of informal discussion, then driving actions a new tool was created. The Failure Mode Effects Analysis not only ensures this process occurs in a program, it improves it. Efficiency is created due to the inclusion of a multi-disciplinary team in all portions of the analysis. Endless debate is truncated by quantitative analysis, resources are directed to areas of the product and program that will mitigate the most risk. Actions to address issues don’t “fall through the cracks” of the program because they are captured in a live document.
The program activities are impacted by design failures as well. A design issue that is identified in development now requires previously unplanned schedule, resource, or both to be mitigated. The impact to the program is discussed to select the most optimal solution. But just as previous to DFMEA it is typically done in an informal manner. Design failure driven program decisions occur with undetermined team members and the critical decision factors change. A method to guide this process is needed, the same as affect to the product decisions needed DFMEA.
I am developing a process called Program Risks Effects Analysis (FMPEA). This create a quantitative method to determine if the risk associated to a found reliability risk should be mitigated or addressed in a later stage. By including input from both the technical and business sides of the program a well informed estimation for risk to the program can be made. The decision is calculated, not estimated by individuals, and the risk calculation process is documented. It’s a DFMEA for the risk to the program of found and hypothetical design issues. I am looking forward to seeing it in action soon.
-Adam
I find it interesting when high end brands look to maximize profit by going for the money grab of lowering quality while maintaining price point. It seems so foolishly short sighted. The amountof work that goes into creating a highly reputable brand is extensive and decades in the making. Brands can be tarnished very quick and very difficult to recover. So why do this? A few reasons I have seen:
We’ll the boat saga continues. As I shared she has turned out to be a cruel mistress. Enticing and a thrill at times and then without warnign I get the cold shoulder. So I am going to take a well known reliability strategy with her. Hopefully we can just be in love again with all of our interactions being nothing but bliss. it’s the oldest reliability trick in the book. “Less is More” The less parts you have the less there is to break.
The more I have gone through this fuel injection system the more amazed I am it has worked this long. The main power relays on the motor are automotive i.e. not for a very wet and humid application. Then !!!(this is infuriating) they are mounted upside down so the seams for the protective cover are on top. This is a boat motor compartment. It has water in the bottom that get’s heated up when the motor runs. Then cools off, condensates after use. Over and over again. That is basically a humidity cycling chamber.
I just finished my talk today at the Applied Reliability and Durability Conference in Portland Oregon. A great conference in a fun city. My topic was “Reliability Test and Analysis with Intent.” I explain a technique I have developed called “Anchoring” which ensures that reliability tools maintain connectivity to program phases throughout product development. Enjoy!
-Adam
A coach is an external set of eyes and ears. They will break down the way you do things and assist with building it up better.
In many disciplines our learning curve rolls over to a plateau as the years pass. Finding ways to continue to improve can be difficult. The traditional, methods of education, formal training, and self directed improvement take significant time investment.
Coaching is not training. Training is pre-constructed material. Coaching is an observation and prescriptive method for improvement.
It’s early in the boating season. It’s a beautiful Saturday and wee’re wakeboarding, My wife is driving. I am getting ready to line up to jump the wake and all of a sudden she cuts the throttle and then guns it again. I just let go of the rope and wait for her to come around so I can find out if it was the dirty dishes left on the couch or beard shavings carelessly sprinkled on her face soap. She said the boat just stuttered without her touching the throttle. Hmmm really? As we are talking the boat just stalls. Ughh!, and we are not close to the house.
Some leaders mistake “customer focus” to mean they have to serve all of the customers needs or respond to every request from the field. There are multiple needs I have for a vehicle. Because of this I have more than one vehicle. Many manufacturers have tried to make a car or truck that does everything. It often just ends up being a vehicle that is great at nothing. (See Pontiac Aztek)
Know your target. Make goals, make compromises. Don’t commit to high reliability without making sacrifices. Something has to move either it be schedule or new technology development. There are no worse words than a leader saying “…and it must be highly reliable” without discussing the cost of pursuing that reliability goal. Know up front if you are willing to trade reliability for growth of technology or time to market.
Stress Margin is an interesting topic because our gut reaction is “more is better.” But more isn’t better. The key is figuring out “How much and where?” this is where the attention should be paid.
Too much stress margin can end the project the same way making material too thick will turn a plane into nothing more than a crappy diner with too much security. It’s the correct margin that is needed. How do we select the correct margin?
When a product has broad usage profiles how do you create one for a test protocol. Do you select the easiest? Obviously not because there is risk of a high failure rate from poor evaluation. Do you select the hardest use-case? You could but there is the risk you spend too much time and money making the product overly robust for most of your customers.
In these cases where test time is limited and only a single use case can be tested I create a “Composite” use-case. It captures many of the different types of stresses from the full list of use-cases but keeps an accumulated stress on the design that represents at least 98% of the customers.
A common progression (stages of awakening) for an organization that has a minimal application of reliability tools to one that is large market holder with the right reliable product is often like this
Stage 1) “Reliability” testing is mostly re-labeled verification and validation testing. It measures if the design does what it is supposed to do
at the end of the program. Tests are executed with the intent of passing, not learning about the product or it’s performance under variability. The organization experiences a large field failure surge due a single or multiple issues. The pain of this experience in dollars, market image, and lost resource through “recovery phase” awakens them to the high ROI of incorporating reliability tools early and throughout the product development process
