You're being brought in to help decide if what the testers are rejecting during your verification or validation test is really a reject. The acceptance criterion was clear to us when we wrote the protocol, but the test engineer is interpreting it differently. It's still within the acceptance criteria, but is it OK? Or you might be part of a root cause analysis team for a larger issue, and they're finding defects getting through a production system. Being aware of the problem is step two. Taking action is step three. So, what is step one? Prevention! I'll share my go-to tool for these scenarios after this brief introduction.
Hello and welcome to Quality during Design, the place to use quality thinking to create products, others love for less. My name is Dianna. I'm a senior level quality professional and engineer with over 20 years of experience in manufacturing and design. Listen-in and then join the conversation at quality during design.com.
There's an old saying, “A picture is worth a thousand words,” and it's true! Visual standards, visual aids, and quality standards: they’re drawings or photographs of product defects, or failure modes and a classification of whether or not it's acceptable. The best visual standards are tied back to a risk analysis like your design FMEA or process FMEA. I see visual standards a lot as a quality assurance tool, but this is not just for quality assurance or process engineers. For design engineers, when determining if a verification test result is acceptable or not, we can use a visual standard. Or to help with our root cause analysis, or as input into an FMEA to develop preventive controls so that you can design your new part to eliminate that issue.
Visual standards take the guesswork out of the decision process. If levels of acceptability are documented before the test or inspection (which they should be) then the final decision is less handwringing and suspect than if it were defined upfront. Visual standards help clearly define that acceptance criteria before you start the test.
It's been my experience that process development engineers and product test engineers include great photos in their root cause analysis or other investigations. Or the process development engineer creates an awesome troubleshooting guide, complete with pictures and causes and what adjustments are needed to fix it. But these things get stuck into that one document, buried in the design documents. So the next time that another group is developing a similar product, the information is hidden or lost. It's a huge loss of brain trust.
As a designer, part of our responsibility is to communicate what's OK and what's not. As we develop a component or subsystem, we're thinking about its details. How will it fail? If it gets this type of defect, is that OK? If not, let's design it out! A systematic way to think through this with other teammates (and just ourselves) is Failure Mode Effects Analysis. It's a table that helps us think through and capture: what could be the failure or defect, what could cause it, what type of system failure or response would happen to our parent system if this happens? We could also use a Fault Tree Analysis or Event Tree Analysis - those two tools help us to visually graph out chain of events.
We're going to see failures in our product. Remember, “Every failure is a gift.” So, through testing, we're going to figure out what level of defect is OK and what's not. A visual standard helps communicate the type of defect, the location on the part, and the extent of it. If it's a small pit at the center of the part: it’s acceptable. If it’s a small pit at the edge, it’s not acceptable.
Designers can add visual standards into the verification acceptance criteria. Look to existing sources. Existing or developing process validations may have visual standards that you can use. And also look to your root cause analysis. Use visual standards to communicate the acceptable window of defects or faults in your design. Ensure what you do for test and the root cause analysis makes it into your risk analyses, inspection criteria, and other places where others might benefit.
To conclude: as a product development team, decide that (for your project) you're going to develop visual standards for the product. Pull information from your own test results, your root cause analysis, process development process, and other investigations. Tie it to your design FMEA other risk analyses. Let other project teams know what you're doing and set up the visual standards as a normal part of your quality assurance program.
Please visit this podcast blog and others at qualityduringdesign.com. Subscribe to the weekly newsletter to keep in touch. If you like this podcast or have a suggestion for an upcoming episode, let me know! You can find me a quality during design.com, on Linked-In, or you can leave me a voicemail at 484-341-0238. This has been a production of Deeney Enterprises. Thanks for listening!
