**NEW COURSE** FMEA in Practice: from Plan to Risk-Based Decision Making is enrolling students now. Visit the course page for more information and to sign up today! Click Here
**FREE RESOURCES** Quality during Design engineering and new product development is actionable. It's also a mindset. Subscribe for consistency, inspiration, and ideas at www.qualityduringdesign.com.
About me Dianna Deeney helps product designers work with their cross-functional team to reduce concept design time and increase product success, using quality and reliability methods.
She consults with businesses to incorporate quality within their product development processes. She also coaches individuals in using Quality during Design for their projects.
She founded Quality during Design through her company Deeney Enterprises, LLC. Her vision is a world of products that are easy to use, dependable, and safe – possible by using Quality during Design engineering and product development.
Speaker 1:
Things didn't go as planned in the test lab. Now we have destroyed parts and results that aren't as useful as they thought they'd be. They may need to do extra analysis or retest new parts. What could we do next time to prevent this outcome? Let's talk about some options 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 Diana. 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@qualityduringdesign.com, we sometimes develop complicated test plans in the name of trying to save the number of parts we need to test or to save test time. We have parallel test tracks and sequential testing that is done on one part. We cut our parts apart and test individual components separately. We submitted our parts to the test lab and our testing is done and we now have the broken or damaged parts, which we expected. We also have test results that when we plot the data, because we will plot the data, we always do, it looks a little off or there's some curiosities in our data or it doesn't look like what we thought it would look like, and we see that there are notes from the test technician about how the test went. So we visit the test area and we make an appointment with our test technician and our test engineers. We find out that there were problems during the test. They had to change fixturing in order to be able to even test the part, or they had to retest parts multiple times because of, well, for whatever reason it was slipping or there's a hiccup in the test equipment. Maybe a solution wasn't mixed properly, but it was used anyway because of timing. Test equipment wasn't available so a substitution was made or parts had to sit on a shelf between tests that we expected to be done back to back. These are all real issues that test engineers and test technicians have to work through. They have their own job and they also need to meet deadlines and they need to fit all this testing that they're getting from multiple projects within a schedule. All of these things can affect the results of our test. Introducing variables that we hadn't even considered when we were creating our complicated test plans. We want tests to be performed without a problem, but that's fairly the case. We do wanna avoid those exceptional conditions where we plan to do the test one way and the test ended up being performed in a different way. Things are going to happen. There are things we can do as design engineers to reduce these problems. One of the things we can do is to involve the test engineers and test technicians in our test planning. They will point out concerns and issues. They know their area, they know where things could be a timeline crunch. If you want this test equipment for your project, that's gonna be a problem because this other project takes priority. We're going to need to make a substitution for your test. That would be something good to know ahead of time, and their world is of testing and test methods. They've tested other parts and they've been around for a while and have performed many different tests. They have a perspective about testing that could benefit your test plan and the test results of your product. We've tested parts like this in this way before and these are the problems that we have. We should really address that before we test your parts. Your parts aren't going to fit into the typical test fixturing that we have. I would have to clamp it a special way and that could cause a problem. You may need to create a test fixture just for your product. These are the kind of things that test engineers and test technicians will be able to tell you about your product. Setting up some time with them and approaching them with these questions shows the respect that we have for what they do in involving the test people in the planning. Were also not just another engineer piling work onto their schedule where Joe working on project Awesome and doing final design verifications. Test engineers and test technicians are partners in evaluating our products in design. Now, they're professionals at what they're do. They're not going to fudge numbers because they like you. If they do, then I would question the validity of any test results that I've gotten from them before and I would get someone else to test my parts. We want test engineers and technicians to independently evaluate and test our products, but we also need to be able to work with them to develop a test that is more likely to avoid those exceptional conditions. Another thing that we can do to avoid getting results that are iffy or not, what we really wanted is when the test is happening, we can show up with curiosity. We can check in and ask, How's it going? Do you have any questions? Are you running the test per the protocol or have you needed a workaround? Many times I've checked in with a test technician and there was a question or a surprise happening in the lab, and this is despite the team's best planning. It's going to happen. Now, I don't hang around. I check in once, let them know that I'm available and then I go away. I let them do their job. If you're uncomfortable doing this and you think you're going to be negatively affecting this independence during the test, then partner with your quality engineer or your reliability engineer. Ask them to check in during testing to make sure that there aren't any questions or any hiccups that need to be addressed. The other option you can do is to let the test lab and the test technicians and test engineers know that you are available for questions during test. These are all proactive ways that affect how we design our test plan and how we can help manage the test as it's happening without influencing the results. After the testing is all done, there's something else that we can do at the end of a design development phase. Some place where it's natural In the product development process, we can do a mini lessons learned. We can meet with our team and the test engineers or test technicians and ask some questions. Were there ways that we tested that didn't work out? Are there protocols that we need to update? Are there new fixtures or tools we need to create? Do we need to redo any test method validations because we're really testing the limits of the tests that we're doing today. Even if our testing was benchtop or trial runs, we can still do this many lessons learned. That'll help us in the test plans that we're developing for later in the product development process like verification testing. This will help set ourselves up for success the next time. So what's today's insight to action? Work with your test engineer and test technician. They have insights into what will work and what won't. Give them an opportunity to share it. Consider the test lab people partners in product design while respecting their need to be independent. If you like the content in this episode, visit quality during design.com where you can subscribe to the weekly newsletter to keep in touch. This has been a production of Deany Enterprises. Thanks for listening.