Timing Reliability in Product Design, with Jeffrey Lewis (A Chat with Cross-Functional Experts)

Dianna Deeney interviews Jeffrey Lewis about new product development: how timing the right activities can lead to product success.

This interview is part of our series, “A Chat with Cross Functional Experts". Our focus is speaking with people that are typically part of a cross-functional team within engineering projects. We discuss their viewpoints and perspectives regarding new products, the values they bring to new product development, and how they're involved and work with product design engineering teammates.

About Jeffrey

Jeff is a senior director of corporate quality at Globus Medical. He's a quality, reliability, risk management and product development professional. He is experienced at building quality into products, manufacturing processes and all business processes. Jeff is an accomplished executive with experience directing design and development and quality staff to meet company goals and objectives.

Jeffrey and Dianna talk about:

• The delicate balance between knowing what you know and discovering what you don't.
• Incorporating reliability tools like Design FMEA (failure mode and effects analysis) and TAFT (test-analyze-fix-test) into the design process to improve designs and make products more reliable and manufacturable.
• Signs that a product development process needs improvement.
• How, by fostering a collaborative environment, product designers can balance the pressures of completing a project within a given timeframe and still ensure the quality and reliability of their work.

Jeff's wealth of experience and insights provide a roadmap for quality and reliability in product design, making it a must-listen for all in product development and design.

So, join us for this interview to gain a different perspective of incorporating quality and reliability into your work.

Visit the podcast blog for more information.

Give us a Rating & Review

**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.

Transcript

Dianna Deeney: 0:00

Welcome to the Quality During Design podcast. I'm Diana Dini. Today I want to talk more about the timing within new product development processes, specifically when it comes to incorporating quality and reliability. To do this, I've invited a guest onto the podcast, jeffrey Lewis. Jeff and I share some working history and I have to give Jeff some credit for really instilling some of the good baseline quality and reliability thought processes into my career. This interview is part of our series a chat with cross-functional experts. Our focus is speaking with people that are typically part of a cross-functional team within engineering projects. We discuss their viewpoints and perspectives regarding new products, the values they bring to new product development and how they're involved and work with product design engineering teammates. If you are a product design engineer or are in product design, jeff has been in your shoes and he'll talk about how he started in product design engineering and, over time, worked to gain the knowledge and expertise needed to fulfill the role he does today, which is an executive who is well versed in reliability, quality, risk management and product development. Let me introduce Jeff a little more to you after the brief introduction.

Dianna Deeney: 1:31

Hello and welcome to Quality During Design, the place to use quality thinking to create products. Others love for less. Each week, we talk about ways to use quality during design and product development. I'm your host, diana Deedy. I'm a senior level quality professional and engineer with over 20 years of experience in manufacturing and design. Listen in and then join us. Visit qualityduringdesigncom. I want to welcome today to the Quality During Design podcast, jeff Lewis. Jeff is a senior director of corporate quality at Globus Medical. He's a quality, reliability, risk management and product development professional. He's experienced at building quality into products, manufacturing processes and all business processes. He's an accomplished executive with experience directing design and development and quality staff to meet company goals and objectives. Hi, jeff, welcome to the show.

Jeffrey Lewis: 2:38

Hi Diana. Thank you, it's good to be at your podcast.

Dianna Deeney: 2:41

Now you're here to talk with us about quality and reliability in ways that affect engineering decisions and share some actionable steps to best work with the quality function as a cross-functional team or just as part of another business function. So I'm glad to be talking with you about this today.

Jeffrey Lewis: 3:02

Thanks. It's a big topic, one that I know we've shared in the past, and it can present a lot of challenges to folks.

Dianna Deeney: 3:09

Yes, and that would be great to get into that in more detail. Your role in product design. How would other product design engineers relate to you Like if they work for the same organization today?

Jeffrey Lewis: 3:25

Right.

Jeffrey Lewis: 3:25

So it's pretty interesting because in my past what I would tell them is you know, I've learned from my mistakes, like everybody, and early on I did some things that you know.

Jeffrey Lewis: 3:36

Some things worked out well, some things didn't, and then I had this desire to try to figure out why, what was behind the things that were successful and the things that weren't, and so that became a journey, not only to improve my skills in product design and development, but I went in the direction of quality and reliability engineering. I went back to school and got my master's degree with a special focus on quality and reliability engineering and using those tools and the thinking that comes behind them to be a more successful you know product development engineer. And so when I come across folks and you know on their journey, I'd like to tell them about that because it becomes very important. I think there's a lot that you learn on the job and a lot that you can learn from academics, and then a lot that you learn from doing, and you learn from both the things that work out well and then the things that don't. So I think that can relate to just about everybody as you go through this whole process.

Dianna Deeney: 4:39

So you started in product design, and now I met you on a special project that I was really excited to join. It was an implantable heart pump. I found quality and reliability there, and it was really through you and some other members of that team and I really discovered that I enjoyed it. So you started in product design and decided to start looking into quality and reliability on your own. Did you have mentors too, or how did you discover the world of quality?

Jeffrey Lewis: 5:13

That's a great question, and it was really through things that didn't work out well. And when I started I was with a really small group of people. You know, I worked at Arrow International. In our department there were only like two engineers at the time before me, and so we came in as a class. There was probably like five engineers hired at the time, and so we were still a small organization. So there really wasn't a lot of mentoring within the company and it just became try something and if it works good, repeat that, and if it doesn't work, figure out why. So, because we didn't have a lot of internal mentoring. Being a small organization, I looked outside.

Jeffrey Lewis: 5:59

The first part of that journey took me to ASQ and quality, and it was folks like Deming and Geran. I just started reading and then, after reading some of those things, I decided, hey, you know what I always intended to go back to school at some point and I wasn't really sure what I wanted to do and what would complement my undergrad degree, which was in mechanical engineering, and that's how it became a product development engineer. But then I decided with this, with this newfound, you know, knowledge and quality, how it could complement all the things that I was doing to make them better. I decided I would go back and get my master's degree in engineering science and tailor all the coursework towards quality engineering and reliability. Engineering and that sort of opened up a whole new world for me.

Jeffrey Lewis: 6:52

That really became important in the project and the whole program that you were talking about with our cardiac assist program and the implantable heart assist pump. I mean, life support doesn't give you a whole lot of room for things to not work well or unreliable devices, so it became really essential, which you know. You go to school and you learn all these things, but being able then to apply them at the same time just became something for me that was really powerful. And as I was well into my journey when you and I met, I could start to convey those things to other people. And I think, as you found out, it becomes pretty exciting at that point when you realize there's a whole new set of skills that really can complement some of this basic engineering degrees that we get as an undergrad, whether it's mechanical engineering, biomedical, chemical, electrical and things like that. Learning how to do product development and learning how to do it more successfully and throughout this whole product lifecycle then became this journey that I've been on, you know, for the rest of my career.

Dianna Deeney: 7:55

So that's interesting that you've always had a bent toward product design, because some other quality professionals come in on the compliance end of it, which is also an important aspect of quality, the effect of quality and reliability in product design. I think when you start getting into it, like you said, you started taking classes and started learning how to do things differently or apply these new tools. You were learning to what you were doing already in the product design world and that I can imagine. That is pretty exciting.

Jeffrey Lewis: 8:33

Yeah, it became so useful at the time because I started thinking about things in terms of quality and reliability. In real estate, they talk about location, location, location and in product development. The biggest impact that you can have on product quality and safety since we work in the medical device industry and we're talking about life support devices the biggest impact that you can have is design, design, design and everything surrounding that process. This just opened up this whole new world and started providing the tools that were missing.

Dianna Deeney: 9:08

You started sharing that with other people, and one of them was me, which I jumped on the train. I guess you could say have you seen other engineers readily adopt these quality and reliability ideas and thought processes, or is there resistance to try to adopt some of these things because they think it might be quality at the back end of whatever is being produced? What are some of the challenges you've seen in implementing quality and reliability in product design?

Jeffrey Lewis: 9:47

Yeah, again, very good question. I have seen a lot of enthusiasm in other organizations as I've taken the same philosophy to them and explaining the benefits. Where the resistance might come in is sometimes of the added complexity. There's this balance between keep it simple but also make it effective. That's a whole nother realm of how do we do this process and get the level of effort right, meet expectations and even understand what all those expectations are. That balance is really important because I think everybody that's been in this has also heard from our executive management folks.

Jeffrey Lewis: 10:33

It's like well, the engineers are taking too long to get this done again. Then they're also equally unhappy when, if you make a device and you put it out there and it doesn't perform the way it's supposed to, it becomes this journey of trying to get things right. How do you get the level of effort right? How do you get the right device? How do you get it out at the right time, on time, on budget, doing all of the right things? It's a lot to balance, so it becomes complicated.

Jeffrey Lewis: 11:01

There's a lot to learn. It's a difficult process. I would agree with anybody who also understands that it is a very difficult process and it's not a perfect process. There's a lot of learning that takes place throughout this organizational learning, personal learning and development. I think being able to harness that and put systems in place that capture knowledge and learning that you can integrate into the next iteration is really important too. This just became something to me that has been a lifetime pursuit. There's so much to it and there's so much to learn that it also can be overwhelming at times. There's the resistance too. You're not really deeply committed to this. It's a challenge because there's a lot of moving parts to it and it's still a learning process.

Dianna Deeney: 11:54

I guess that's true too. When project management gets involved in product development process, it is like you said. It's a very complicated thing to do in the first place. There's a lot of hands involved, from idea to just getting a product into the hands of the customers. And then you also mentioned a bit ago that design is really at the front of it, or if you can do the design right, other things will go smoothly, more smoothly in the end. When people are looking at a product development project and it's so big to try to inject some of these quality and reliability methods early, I can see where some of the resistance would be. We've already got too much to do and we don't want to try to learn this new thing that we're not that confident is going to get us the answers that we need. Is that the kind of resistance that you see or that you have seen?

Jeffrey Lewis: 12:57

Right and there's also a lot of enthusiasm at the start of projects. So everybody's like, hey, let's go, we've got to get something done, we have to show something, and that's true. Never want to lose that sense of urgency and focus. But at the same time those beginning steps are so critical and you sort of learn this. We learn things the hard way. Sometimes you can take advice from somebody who's been down this path, but it's almost not the same as experiencing it.

Jeffrey Lewis: 13:25

But some projects, like a cardiac assist project, take so long to do that if you don't start them correctly you just end up in the wrong place after a long period of time and it becomes very disappointing. So trying to make sure you have the right path, you have the right design, that you have the right understanding of the requirements and the whole customer needs, is so critical that it's worth putting in a little bit of extra effort in the beginning. And then, if you're confident you've got that right design and the right requirements, then the implementation and the execution of the project becomes a little bit more predictable and I think confident that when you get to the end you're going to end up with success.

Dianna Deeney: 14:14

I interviewed someone that has his own business and he helps companies with supply chain management. There have been some challenges with project managers changing mid development. So you have this, like you mentioned, these big projects that could take for years and everybody's up to speed with some of these quality reliability methods but then, because of wanting to grow people in the organization and have those employees have different experiences, they swap out roles of the team every so often and it really shakes things up in the product development process. Have you found that project managers or particular engineers are really on board and can really affect the impact of quality and reliability in product development, but that when they leave it's sort of like a vacuum and you have to start all over again with the quality and reliability initiatives?

Dianna Deeney: 15:15

Or are you working at it more from a top level, higher level business sense? I guess one question is have you seen that happen where individuals get swapped out and there's that vacuum, and is an answer to that more at a systems business level?

Jeffrey Lewis: 15:33

Yeah, again, also great points and good questions. I have seen it happen and that loss of continuity is really impactful in a negative way. If someone wasn't happy with the direction of a project, changing the leadership, changing project management is certainly a way to impact that in a different direction. But if you like the way things are going, it's really impactful in a negative way because you lose all this continuity, all the momentum that you had, all the understanding. It's really devastating and it really takes away from being able to accomplish the goals and objectives in a reasonable time. If you have to go and educate a new person, especially that person is in a leadership role, it completely changes things and so lessons learned. I mean, if it's a project that takes a long time and you can preserve the leadership and continuity, that's the best approach. It's really a challenge to maintain all that if you've got a change in direction at the top and so, yeah, that's kind of devastating.

Dianna Deeney: 16:46

The main target audience of this podcast are the product designers. I call them the boots on the ground, people that are making decisions daily about the product, the source for components, creating the design specifications and the drawings, and I encourage them to work with their cross-functional team before they even get to that point to help understand the use space at a concept design level so they can develop their design inputs. I think you're probably aligned with that too, is that right? Yes, okay. So what are some of the things that product design engineers can do with their quality and reliability counterparts when they're assigned to a project or when they're working in a project? What have you found have been some best practices for those two groups to interface and work together?

Jeffrey Lewis: 17:47

Yeah, I mean to start. I mean making sure that there's requirements for reliability, the reliability of the system and then those system reliability requirements can be translated to different parts of the system. So, if it's a complex system and it has a bunch of different pieces and parts, modules, that there's an understanding of what those requirements are. So think of it in terms of product quality. Right, it has a bunch of different dimensions, like conformance to specifications, so manufacturability, performance, and then you have reliability, durability, maintainability, usability. Those types of things are really important, and so, working with your quality engineer, reliability engineer and counterparts, you can get those perspectives. A good reliability engineer will help you make sure that your design is optimized and it's robust, right?

Jeffrey Lewis: 18:45

So one of the things that I learned early on, too, was challenging these designs to make sure they're going to perform under all conditions of use. And do we even understand all the conditions of use under which they're going to be used? So the usage profile. And then we talk about well, what does that look like and how do we define that in engineering terms, so that we make sure that this device performs not only for all of the uses that it's intended? But this has always been a big thing with FDA and product quality, have to consider foreseeable misuse. People don't always use devices in the manner in which we intended or under the conditions which we might have thought of. So can we even anticipate what those might be and design or account for that in the beginning, and how do we challenge that design to make sure it's going to be reliable under those conditions, if that's something that we can do and try to balancing all of those things? So that input in the beginning is really important as well.

Jeffrey Lewis: 19:49

I've done things in the past where I thought it had a good design but I didn't really challenge the design at its limits. And those would be the limits of the design in terms of its characteristics and how those characteristics affect performance and reliability and usability and things like that, as well as the conditions under which it's going to be used. Do I even have a complete understanding? That's really the reliability part, the quality engineering part. Is this design really manufacturable? Is it optimized for manufacturing? Can I make some changes now in the beginning to make it easier to manufacture, because all those things really help in the end.

Dianna Deeney: 20:25

Now these kind of conversations with reliability and quality people. They can happen before we even have a prototype in hand correct. So even just a high level concept, a layout and some experience especially if you're iterating on a previous design, you have experience with something that you've already had and maybe you're changing some components or making the next generation of something I mean, there are those some things that you can start with before you start designing and mocking up prototypes. To get reliability engineers involved. It's really just about having some frank conversations about what engineering could plan to do. It's maybe even some simple schematics, and I think reliability engineers can provide some useful input and independent reviews at that level. Have you experienced that also?

Jeffrey Lewis: 21:26

Yes, absolutely. The earlier you can start having those discussions the better, because the opportunities to influence changes in the design obviously goes down as you progress through the design phases. So the concept stage, making sure you have the right concept, that is the most important part. So, are there different concepts? Does one concept fundamentally solve this problem better than another one? And have we considered those things up front? Once you sort of challenge that concept thinking, then you get into the detailed design work. Then you can start with some other analysis tools.

Jeffrey Lewis: 21:59

So design FMEAs, for example, a really powerful tool for reliability engineering and engineers in general, to start to break that design down into all the pieces and parts and their intended functions and how we specify those and how they're intended to work. And the interfaces between these parts become very important. There's a lot of failures that occur just between the interfaces, so starting to consider those things is really important. And then there's, from a reliability engineering perspective, certain things are known to be more reliability problematic than others, like cables and interconnects or just design choices like hey, if we have a bunch of parts that go together, can we design them in a way where they can't be misassembled? Can we make it more user friendly from the beginning too. So the way people are going to interact with this Good time to ask all those questions is really in the beginning, because it's the easiest time to make changes.

Dianna Deeney: 22:59

And then you're kind of getting into. The next question I have is even if that early conversation and early work when it happens not even if, but when that happens that information is just. It's not like you just talk and then you're done and you move on. You talk, you explore and then you iterate on it as you're developing the product through the development project. So you start it early but then you can iterate it like you mentioned with with FMEA. My experience is you get more detailed or you get to understand what type of reliability or quality analyses you need so that you can better make decisions. Wherever you are in the development process, whether you're doing that detailed work or you're starting to develop tests have you seen a lot of that iteration happening and is that how you view that kind of work, that you kind of continue to build on it throughout the development process?

Jeffrey Lewis: 24:05

Yeah, I think if you have a good design and development program, those are the things that you do see. I think when you don't see those types of things, it can be a red flag, because there's this you know, we need to produce something and let's just get something done. Well, that does result in something, maybe something not very good. I mean, there's always a chance. You just somebody has just a great design from the beginning. But this process is engineered. It's not supposed to be one of just chance, right? So we're bringing quality and reliability engineering tools to this and a discipline to consistently produce better results. So we want to look at how we can optimize that design process. So, having these discussions, using these analysis tools early in the process, even if at a high level, just to help shape and challenge the concept, and then challenge the design in the beginning, make prototypes. I remember doing this in the cardiac assist program. One of the first things that we did, and we had just very early in this program, is let's just get one of these put together, let's get a system put together, and we ran it on mock loops and then we went and did some testing. Our objective was let's just see a reality check for where we are, give us sort of a gauge, you know how close are we or how far are we. And that was even the purpose. So it wasn't about do we need to see everything work the way it's supposed to right now? Are we going to be really upset if there's a failure? But it was really about let's see where we are in this process. I kind of made the analogy at the time to hey, sometimes you just need to pick up a ball and throw it as far as you can. It's like where are we at? And that's what we did, and we kind of went for it. And so we did a lot of work. We built the system, we put it on test and it failed in like less than 30 days. I was like, well, this is a pump and our intention is to be able to go two years and then, shortly after that, to go five years with high degree of reliability. And so here we are. We're like so this failed in 30 days. So I'm like, well, it looks like we have a pretty far way to go. But the reason it failed was for a little detail that we missed. And so what it did tell us it's like, ok, well, we might have a really good design, but we're also going to have the we need. We need some real discipline in terms of how we put it together and then the checks that we put in place.

Jeffrey Lewis: 26:39

So as we started developing this design and then doing the detailed work and we realized we had to put a process in place for putting it together and that process had to include certain checks throughout, so then it became OK, well, here's where we are. It's going to take everything working together to do this right. So I think it's worth, in the very beginning, challenging your concept and challenging your design and doing some aggressive testing even Because if we're going to experience a failure and this this is another thing about reliability testing versus what we used to call success testing, and I'll explain that in a minute. But the reliability testing is to challenge this design under conditions of use, even foreseeable misuse, even under maybe some high levels of stress, to see where we are. It tells you a lot when something fails and you understand the conditions under which it fails, because then we can relate that to the use of the device and say, well, are those conditions going to occur in use or has this design really performed well. The conditions under which it failed are really beyond the design life, beyond the usage profile. That tells you a lot versus. I mentioned success testing.

Jeffrey Lewis: 27:57

Sometimes you go through a project, you start testing things and your objective is to prove that they work the way you said that they were going to work.

Jeffrey Lewis: 28:06

And so you end up with we did this test and everything passed. But did you really challenge it? And then did you test to failure and did you find out where failures occur in the design and under what conditions? Because that's really valuable. So putting all that together challenging the concept, challenging the detail, design, using your analysis tools then going on to build things and test them aggressively in the beginning to me was really valuable. Because the opposite especially if you're doing life support devices you design and you build something and you spend a year getting to that point and then you put it on test and then it goes a year and has another failure. So there's multiple years that have gone by and then you look at it and say is this something that I could have learned in less than three years? Maybe I could have learned this in six months if I had this aggressive test plan working in parallel with all of the other things that need to come along throughout the design and development process. So we really learned early on to challenge these things in the beginning.

Dianna Deeney: 29:11

Yeah, and it's looking at those early tests as discovery tests, is that how you would describe them?

Jeffrey Lewis: 29:19

Absolutely.

Dianna Deeney: 29:20

So you're discovering more about the use, environment and limitations, and really just the problem that you're trying to solve. Even with a heart pump, there's a certain problem that you're trying to solve, and how is this concept going to perform? Is it going to be able to do what it is? We need it to do?

Jeffrey Lewis: 29:41

Yeah, it's very much like a reality check at that point, Like where are we and what do we know and what yet don't we know?

Dianna Deeney: 29:49

I'm just now reading a book about the Wright Brothers and they wanted to master flight, and this is early 1900s. One of the challenges that they had is they were going off of other people's calculations, other publications, of how they thought things were supposed to work and they ended up discovering that those calculations, estimations of variables, were just not right. They did that through some early prototype testing. So then they knew then that they knew a whole lot less than they thought they did and had to go back and redo some testing. But I can imagine, with a product development engineer testing out some prototypes and looking to evaluate this concept, that there can sometimes be external pressure to say, well, hey, you got a prototype, now let's run with it. Have you seen that kind of timeline pressure and what could? Is there anything product design engineers could do to fend that off?

Jeffrey Lewis: 30:53

Yeah, it's difficult because people get excited when they see a prototype.

Jeffrey Lewis: 30:57

All right so let's get it out there right away. We can start generating revenue and I'm like that all sounds great, but is it going to do the things that we needed to do or is this just a false start? So it's interesting that you talked about the Wright Brothers and that experience, because it's so valuable for them to learn early on what they didn't know. And it's also interesting because I was just recently in Dayton, ohio and I went and visited the Wright Brothers house. It was really great their whole creativity and approach to things. So it's like some people have this sort of natural curiosity and the way they go about things, where for me it just became something that I learned and then had to apply, and then I've tried to convey that to other folks. But all of those things happen and it is a challenge to sort of say hey, wait a minute, here's where we really are. And I think when you have a prototype and you can provide those results, you can also let people know where we are. Hey, are we where we need to be? That's the question, and if we are great, then we're ready to go forward, and if we're not there yet, then we know that and we know early on. So it's really important.

Jeffrey Lewis: 32:18

I think that's the way to address it, and everybody needs to be objective. Like are we on track? Are we not on track, and how soon can we figure that out? That's really important in this whole process Because the sooner you can learn if you're not on track or there's parts of this that we don't understand yet, that we need to put more effort into. That's really critical. And then trying to separate that from OK, well, what's the balance? Is this something that we can go with? Is it going to meet our business goals and objectives? Is it going to work the way we intend? And then can we work on a second generation after that. And maybe there's some technologically limitations right that you have to deal with. Those happen especially if you're on the forefront of some state-of-the-art type device or engineering solution to a problem. Sometimes some of the knowledge and the technology isn't there yet and you have to go and develop it.

Dianna Deeney: 33:12

And those are things that team meet up with other engineers and I think specifically reliability and quality engineers can help the product designers be able to discern and to understand.

Jeffrey Lewis: 33:26

Yep, I think that's a key Getting everybody on board.

Jeffrey Lewis: 33:30

And so those discussions, those design reviews that take place, the engineering analyses they shouldn't be taken lightly.

Jeffrey Lewis: 33:38

They're really, really important, and it's really important to define at the different stages, where you expect to be, so you kind of know are we on track or are we not on track? Is this something that we can live with or do we really need to make a change? And, like we were just talking about, the sooner you can do those things, the better. And if you can get to the point where, like, yep, we're really feeling good about the beginning of this, the concept's right. We're starting a detailed design work, we're getting the inputs that we need from reliability and quality, we've got an aggressive test plan to make sure that we're not missing something, and then we're going to deliver these prototypes. We're going to do some additional testing and all the way through to market launch, because once you're in product design and development not in R&D people expect execution and delivery when the product launch is going to happen. So it's balancing a lot of those things that's really critical to this process.

Dianna Deeney: 34:39

Now Ethan engineer is listening. They're a product design engineer on a team coming away from our conversation here. What's one thing that they could do today to improve work with their team for new product design?

Jeffrey Lewis: 34:56

Yeah, I think bringing that understanding of there's a lot that we can accomplish through our engineering analysis process In reliability. One of the first things that I learned was this model called TAFTS Test, analyzed, fix and Retest. Bringing this perspective of if we have to do iterations and it comes at the end that we've learned something, we spend a lot of time, we have to make prototypes, we have to build parts then we're going to start to do testing. That's expensive. Do we have the right focus right now? Do we have the right understanding? Are we likely to be successful with that? Is there something that we can bring to this early on? What are the biggest risks?

Jeffrey Lewis: 35:44

I think using those risk analysis tools, particularly DesignFMEA, to see where those are. What are the things that we know from prior designs and things that we've done? Maybe our organization? We have a lot of knowledge because we've been in this business for a long period of time. Do we have standardized test methods? Are the methods that we're using for our testing good enough to tell us if we have a problem before we release this design and maybe have something in the field? I think bringing that perspective is really important. It's just as important as challenging the timeline to see if we're being efficient and we're moving things along per management's expectations, because everybody we're in a business, we have to produce devices and we have to make money. I think understanding that balance and understanding why the executive management team is so enthusiastic about great, we got a prototype. When are we going to see this product launch? Their expectation is always oh, I always expected that you were going to do things right and it's going to work the way it's supposed to.

Dianna Deeney: 36:48

That's true, that's a given right, I'm like huh. Yeah. So just taking a moment, instead of maybe in the daily grind, to just look up and understand what are the knowns and the unknowns, what have we learned and what do we still need to learn. Those are all valuable insights that can help balance the pressures of getting a project done with a timeline. Did I hear that correct?

Jeffrey Lewis: 37:13

Yes, absolutely, that is 100% correct. It's important to understand what you know and what you don't know. I think you said it perfectly.

Dianna Deeney: 37:23

That's good advice that you gave For next steps. If engineers wanted to learn more about quality and reliability because you mentioned, you started in product design and you got into and discovered quality and reliability Do you have any recommended resources for engineers that want to learn more about? Maybe they want to look into taking that journey too. It could be books or podcasts or websites.

Jeffrey Lewis: 37:56

Yeah, I mean there's some good reliability programs out there at schools. I know Arizona State, maryland has one. Largely. I went and worked with a company called ReliaSoft for many years. They were a startup company. At the time when I was first looking at information about reliability I ended up buying one of their tools, which was the YBOL++ analysis. Then they offered a lot of really world-class reliability training and they kept enhancing that. Reliasoft still exists. I know the company was sold maybe once or twice since then, but if you Google ReliaSoft, for example, there's still a lot of information out there and they have great tools and a great program. There's RAMs, right.

Jeffrey Lewis: 38:51

So organizations that specialize in reliability and maintainability. Getting involved in some of those can really open up contacts in your network. That's very valuable. There's some really good books on reliability engineering. There's one in particular too on effective FMEAs by Carl Carlson. I haven't spoken to him in a while but I talked to him many times at ReliaSoft and he's done a great job with that book. It really helps provide a really great perspective on a very powerful tool which is just FMEA in general. Then from there, like I said, looking into some of these organizations that specialize in reliability engineering, education is really helpful.

Dianna Deeney: 39:34

Well, those are a lot of good resources. Well, Jeff, thanks for talking with me today about quality and reliability and product design.

Jeffrey Lewis: 39:42

Well, thank you, I really enjoyed the conversation.

Dianna Deeney: 39:47

I hope you've enjoyed this episode of the Quality During Design podcast. As always, there is more information at qualityduringdesigncom. This episode is under the podcast blog, where there are a lot of other podcasts, including more in this interview series. If you haven't yet, subscribe to the podcast using your favorite podcast provider. This has been a production of Dany Enterprises. Thanks for listening.