Your Reliability Engineering Professional Development Site
A comprehensive reliability engineering program for a new product is a large investment. Not just in dollars, but more importantly, in time. No matter if you are a Fortune 500 company or a startup in your second year, time is always the freight train bearing down on you without mercy. I am going to give you a simple recipe I use for making a highly reliable product when that train horn is blaring and only getting closer. [Read more…]
More often than we think, customers who aren’t even trying to Use Case 7 our products seem to end up doing so regardless. That’s fine, it happens. However, it also tends to result in $1 billion + lawsuits that could have easily been avoided.
The big question is, who do YOU blame? I mean you, the person reading this article. When your team discovers a field failure root cause to be user error do you either:
I recently held a lunch and learn about infographics. The recorded session is below. In our work as engineers, we often spend a great deal of time extracting amazing information from complex data sets only to find no clear way to get our message to those who need it which can include leadership, peers, or even the customer.
Changing how we present information can be the difference between driving change and simply being a slide in a weekly status meeting that solicits the response “next.”
There are many scenarios that can arise throughout product development programs. There is one in particular that I have seen unfold more than once: I call it the “Plus one program.” Don’t let the name fool you; it’s horrible to watch unfold.
A startup or established player introduces an impressive jump in industry-standard technology, or sometimes an established player introduces an innovation to their industry. Since the technology is so innovative, there is great value in getting it to market quickly even if it isn’t a mature design. In this case, it is actually a smart move to go to market with a device that doesn’t have “ideal reliability.” In other words, the value of getting it out there quickly is worth the field issues. Those issues will be tolerated by the customer as well, if the technology is that good.
The fist part of this post you likely already know. It’s the second part that may be helpful.
I love HALT testing and almost always include it in a new program. With a team new to the concept there is always the hurdle of getting them to understand it’s value. It’s not intuitive to see value in destroying a product with stepped stresses. Often these stresses aren’t even apart of the product’s use case. Why vibrate a lab electronic device that spends its entire life on a bench? Seeing the failure mode is a capacitor flying off the PCB at 50 G’s doesn’t reinforce the value of the activity without some explanation.
A helpful analogy in communicating the concept of statistical reliability confidence is the “new airplane” example. Let’s say I am developing an entirely new technology for airplanes. The airplane has an engine that has never been used before for air travel; a fusion engine. I tell the world that this new airplane with a fusion engine will have a reliability of 99.99999999%, the highest any airplane has ever had. It’s not possible to fully demonstrate this reliability until every single unit of this airplane has been produced, used to full life, and the full fleet is retired. As long as one is still flying it can add or subtract from the reported reliability number. So, how do we make decisions at product launch regarding the design’s reliability? No products have yet to be produced or used by customers, so how can we trust the design?
Anyone who knows me knows that I tend to only think in terms of cars. I can remember the car someone pulled up in at a party four years ago, but will have no recollection of what their name was. Moreso, I view culture, politics and economics through a sort of automotive anthropologist lens. For example, darker colors are more popular in luxury car sales when an economic downturn has occurred and major shifts in industrial focus will be reflected in increased offerings of economy cars that can hold 4 to 5 people. I think you can see what the problem is here.
In any case, I came up with a cooking analogy (in no way automotive related) for a principal of data organization and I have to say, it’s actually pretty good! So, I am documenting it here.
[Read more…]
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. [Read more…]
There is an issue up for vote this year in my home state of Massachusetts. It’s called “Right to Repair.” The proposed law states that automotive manufacturers can not lock owners and independent repair shops out of vehicles on-board diagnostic computers. These are the arguments on either side of the issue:
Auto manufacturers don’t want independent repair shops completing work on their vehicles with technicians who are not factory trained. They are also concerned about repairs being completed with non-factory parts that could potentially be sub-standard. These manufacturers believe they should have control regarding repairs because they are held responsible when issues occur under warranty. So why is this an issue now?
Sometimes we can only test one use case before we ship our product. So what should it be? Should it be the hardest use case? The nominal use case? The 95th percentile use case?
No! It should be the “midlife crisis use case.” What is it? I’ll show you.
Adam and Fred discussing the best methods for integrating field data into established reliability programs.
ᐅ Play Episode
Adam and Fred discussing how customer satisfaction with a product affects their perception about reliability performance.
ᐅ Play Episode
Adam and Fred discussing how the philosophy of HALT and Use Case 7 share some common ground.
ᐅ Play Episode
Well, it’s time for another exploration in Use Case 7. Unfamiliar with UC7? It’s simply when customers do unexpected things to our products. We often ignore it, but in fact, it is one of our best ways to learn about our product’s reliability. [Read more…]
This is a direct followup to my post last week.
I usually don’t do two part posts but….
I got some great responses to my post last week. I then got this image from my buddies at NASA (on the ground, not on the space station). One is actually my roommate from college. His hair is much shorter now.
