Strategies for Designing a Reliable Product
Abstract
Chris and Fred discuss different strategies for reliability. We start with a couple of strategies that don’t work (big shout out to virtually every military customer … ever!) and then come up with some approaches that have been shown to work – at least in some circumstances. And that is the key – different scenarios demand different strategies. Sound interesting? Then this is the podcast for you.
Key Points
Join Chris and Fred as they discuss strategies for designing reliable products. We get companies that think all they need to do is hire the ‘best’ engineers do build or design something – which means everything will be reliable … right? It is funny how many of these companies also think that customers don’t know how to use their products and flat out abuse them – and that is why they have high field failure rates. Then there is every military customer in the world who always pride themselves on how flexible and cunning their mindsets are when it comes to achieving challenging and dangerous missions. Funny how they revert to ‘drill sergeant lawyers’ when they produce a ‘War and Peace’ scale contractual/requirements document and think (hope?) their work is done. So these approaches don’t work. So what approaches do?
Strategies include:
- (reliability mindset) Baking reliability into the organization where every engineer is taught, exercised, practiced and assessed in terms of their reliability plan. Reliability is not something separate. Reliability is an equally important part of every design decision. So this means that electrical engineers (for example) know their reliability goals, where they come from, who they go to if they have issues with these goals, how they interact with vendors, telling these vendors that ‘FIT rates’ aren’t good enough and they need more and so on. This is a reliability culture. So it is a part of how you do business – from senior managers to the graduate engineers. Not a separate thing, but a part of how you do business.
- (prototypical) Build. Test. Fix. This is a strategy that is not universally accepted. Building prototypes quickly and subjecting them to things like Highly Accelerated Life Testing (HALT) is a proven way to quickly improve reliability. But there are some cases where you simply won’t get a prototype … or a prototype quickly enough. But perhaps the biggest problem with build-test-fix is that it can make people stop thinking about preventing failures before we even get to a prototype. Failure Mode and Effect Analyses (FMEAs) are proven ways of getting ahead of the ‘failure curve.’ So build-test-fix can often fall down if this is the only approach you use.
- (analytical) Simulation and modeling. You can learn a lot through modeling or simulating your ‘thing’ in a computer before it is built. Not only does this work our where your ‘thing’ will fail, but it will tell you what you need to do to reduce that stress through design change. But there are problems with an analytical approach as well. There is no good in studying a failure mechanism for 10 years so that you know it back to front … if your time to market window has come and gone. And then there are those who research analyses that (loosely) supports an existing position.
- Failure hunting. This is a little of every one of the strategies above. Quite simply, we hunt failures at every stage of design. Finding the vital few at the very start (FMEAs) then through prototyping (HALT) and then from any other data source. This is a very simple philosophy … but one that really works! Some might say things like ‘how do we know how reliable your thing is?’ or ‘how do you know if we make it too reliable?’ and so on. But there are precious few (i.e. virtually no) instances of products being accidentally too reliable. So if you are not afraid of making it too reliable, why wouldn’t you devote resources to finding failures versus measuring reliability (where the latter is often a lot more expensive)?
- Over-engineering and then shaving margin. Sometimes the cost is not nearly as important as time to market. So we (deliberately) over-engineer from the start and try to shave margin as the design matures. But this only works in certain circumstances. And weight is an important consideration these days (think carbon emissions for transportation). But by the same token … customers always want to do more. They want phones to get wet (they won’t say this), get thrown across a room (they won’t say this either) and so on until these things become the industry standard. Based on those few phones that were able to withstand this punishment from day one.
- (standardized) Build to a specification. These specifications come from somewhere else. International standards. Perhaps explicitly written customer requirements. Industry endorsed ‘drop tests.’ And if we meet the specification or standard … then it is good! The surface-level issue with this approach is that we rely on all these standards and specifications and industry practices to reflect what the customer wants AND what the customer sees in the market. But the bigger problem is that you very quickly create an organization that stops thinking. Why would they? Someone else has done this for them. But if the customer wants something new – they will need to wait for the standards committees to realize this, endorse a specific measure as ‘good’ and then (10 years later) re-issue an updated standard. Does this sound good?
- Make customers test engineers. This is not an approach you should endorse lightly. Essentially this means you ship your product to the customer with the intent of making something more reliable once they find issues with it. This has worked well when one company who manufactured servers sent four test engineers to their customer after they installed the server to make sure that failures were removed from the design. There was some marketing pushback, but the customer appreciated this commitment. But perhaps this should not be an approach for consumer electronics …
Enjoy an episode of Speaking of Reliability. Where you can join friends as they discuss reliability topics. Join us as we discuss topics ranging from design for reliability techniques to field data analysis approaches.
Show Notes
Very interesting and thank you for the insights to how to approach reliability even before having a tangible product.
Thanks for your comments! Keep the suggestions coming.
Another great discussion topic Chris and Fred! Just wanted to let you know someone is listening and appreciates your efforts.
Thanks Don. Your feedback is very valuable and appreciated!