Getting Information for Product Design with Fred Schenkelberg (A Chat with Cross-Functional Experts) - Part 2

Dianna Deeney interviews Fred Schenkelberg about getting information for product design, focusing on reliability engineering in new products.

This episode is part 2 of 2.

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 Fred
Fred is a Reliability Engineering and Management Consultant and founder of Accendo Reliability.  Fred’s expertise is program development, accelerated life test design & analysis, reliability statistics, risk assessment, test planning, and training. He is a graduate course lecturer with the University of Maryland, the initial Producer of the ASQ Reliability Division Webinar program, and a regular speaker at the Reliability and Maintainability Symposium (RAMS®). He also founded and maintains accendoreliability.com, a reliability engineering professional development hub. 

Fred and Dianna talk about

• the realities of internal team dynamics and the delicate dance between innovation and issue resolution
• advantages of initiating reliability conversations early in the design process
• practical advice on how design teams can triage problems by applying the right tools, thus ensuring a more robust product design process

Fred's tales from the trenches offer a unique lens into the challenges and triumphs of creating products that not only work but last.

Visit the podcast blog for links to Fred's recommendations.

If your team is still catching problems too late — let's talk.
→ Schedule a free discovery call: Dianna's calendar

Want insights like this?
→ Subscribe to my newsletter: qualityduringdesign.substack.com

Get the full framework.
→ Pierce the Design Fog

ABOUT DIANNA
Dianna Deeney is a quality advocate for product development with over 25 years of experience in manufacturing. She is president of Deeney Enterprises, LLC, which helps organizations and people improve engineering design.

Transcript

Reliability Engineering in Design Teams

Speaker 1 0:00

Welcome to another episode of the Quality During Design podcast. This is a special two-part episode series where I'm interviewing Fred Schenkelberg, a reliability engineering expert. You are now listening to part two of this interview series. 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. Let me share with you what kind of conversations that you can expect in this part two, after the brief introduction.

Speaker 1 0:48

Hello and welcome to Quality During Design, the place to use quality thinking to create products others love for less. I'm your host, diana Dini. I'm a senior-level quality professional and engineer with over 20 years of experience in manufacturing and design. I consult with businesses and coach individuals on how to apply quality during design to their processes. Listen in and then join us. Visit qualityduringdesigncom.

Speaker 1 1:18

In our previous episode and part one of this interview, we talked about how design teams prioritize and make decisions and the level of detail that's necessary in order to make those decisions. We continue our interview in this part two, where we talk more about the culture of how organizations handle information and about how reliability engineers can help design teams do a triage of problems. I'm glad you joined me for the second part of my interview with Fred, where he shares more stories that are really going to drive his points home. Enjoy, now, I kind of like what you've been. The phrase that you said before is that the team is there to help provide information for the design people to make better decisions. So sometimes I can see it being a challenge to know what questions to ask somebody or where to look for help, other than I've got a problem. I don't even know where to start.

Speaker 2 2:24

Who do I?

Speaker 1 2:25

ask. But I think and I want to know if you have any other viewpoints on this too but I think if the design engineers look at asking the other team members for help reliability engineers, quality engineers, the test engineers if they first start with the intent that I need more information to make better decisions, and then go and reach out to those people to talk with them about that, that that would set up some better conversations, more productive conversations to make design decisions.

Speaker 2 3:01

Very true, and it goes both ways. The design engineer can also go look for where those major decisions are and go talk to the people that are in charge of making that decision. It might be a vendor selection in the procurement organization, or it might be a setup of the heat transfer out of a particular product, and how are they attacking that issue and what major decisions are they making? And it's usually a very quick chat. I try to do it more elegantly than so. What's keeping you up at night? What could go wrong? Where's the tightest margins? Where's the newest components? Where's the things that we know the least information about, or variance of that? And sometimes it's in a team meeting. Someone says A we're having trouble with this, we saw this, this, this issue, and so we're seeing prototype failures or issues already. Well, let's double down on that, because those don't go away all by themselves. What was the set of decisions that led to that particular circumstance and what information was missing that we didn't avoid that problem? Other times it's interviews, other times it's. You know, comes from testing that we're doing anyway, or we. My favorite is go swing by the software folks or the marketing folks that are getting early prototypes and going well. What problems are you seeing? Because they're just trying to use the thing to make sure it's working or to check out their code or do stuff like that. And if the on off button doesn't work well, that's not going to go away all by itself. Let's go figure out if that's still an issue.

Speaker 2 4:45

Things like FMEA is more formal, where you're actually engaging the design team to say, well, what's the big issues that we need to go solve. So there's everything from just listening, you know, around the coffee pot or the zoom meeting or the reviews or interviews with people what are the big issues, what are the big problem areas? What part of this decision is hinging on reliability of your product and then offer hey, I can help, this is important, I understand that I can. I can do this, this and this with that help to understand this problem more. Or have you looked at finite element analysis? Or have you looked at this or that, these other tools to look at it? Or I know in one case it was. Well, we're not really sure of the tolerancing on this thing and if it's too loose, this will rattle apart, and if it's too tight, we can't manufacture it All right. Well, let's go measure it. Let's do capability analysis on it real quick and find out what this vendor's process capability actually is. And they go and they're like oh, you can do that. I got a micrometer. It's probably the worst instrument to use to measure this, but we can do it. Today I didn't get into measurement system analysis until after that experience, but we're able to bring the set of tools that we have available and instead of saying, oh, I love doing HALT, let's always do HALT. It's more, what problem are we trying to get better information about? Let's go do that and then pick the tools.

Speaker 2 6:22

So the process of the discussions with design engineers is understanding those pain points, those pressure points. And sometimes it's a new component, a new invention, a new material, a new vendor, a new manufacturing process. Those are kind of red flags for me, anyway to say you know, we don't have enough experience with this stuff to know what we need to know. So we need to go figure it out what's important, what's not important. And other times it's the design engineers saying you know, I'm really at a bind here. I know this is going to impact reliability, but I have a trade off and I don't know how to set this up. So while let's make you know, set up an experiment to see which one wears differently or whatever the particular issue is, but it's an ongoing, regular discussion about.

Speaker 2 7:17

It's not like at the start of the program you set the plan and then you just do that. It could change every single day if what's important and what information is necessary to be generated. The contrary is the absolute worst is you do run off and you do a bunch of environmental testing and it's late in the program and they're not going to change anything at this point because everything's locked in and you come up with all these wonderful results of this work that doesn't work and so on, and then nobody reads it because there's nothing they can do about it. What a colossal waste of resources. The intent is get the information that's possible to get within your constraints. When that information isn't to make a decision, it really doesn't serve anybody to say I told you so late in the program.

Speaker 1 8:12

And then for the people that are making the design decisions, the design engineers, knowing that if they're stuck making a trade-off decision, then their teammates may be able to help, but they may need to phrase it in a way that is looking for the information they need to be able to make that decision.

Speaker 2 8:34

You'll make a reliability engineer's day if you walk in and say I'm looking at these two options, which one has got the least risk of failure over the timeframe we're interested in. That's like just dropping it in a lap and going, oh, I can do that, that's what we're meant to do, kind of thing. It isn't always that clean and clear. I think the best organizations I've seen is that there isn't a reliability engineer at all. There are a bunch of people that knew to identify those types of issues or problems or trade-offs that using some of the reliability engineering type tools, like accelerated testing for example, really made a difference in making that decision. So the mechanical, electrical engineer would talk to one of the lab technicians and that supported the lab and they'd set up and run their own test and analyze it and go. They had the experience using what reliability engineers like to say is their toolbox. But it's the same with quality. There's no rule that says that the quality engineer is the only one that can set up a control chart. Anybody can set up one of those. Everybody should know how to read one of those and use them.

Speaker 2 9:57

The idea is that whether or not you have a reliability engineer or a team of reliability support doesn't really matter if it's never discussed or brought up or used, that information is not sought after or used during the design decisions.

Speaker 2 10:19

So I've seen teams that have no reliability engineers and make an amazingly reliable product. It's just part of the culture, is what they do, and they identify things and go get the information they need and make better decisions, as opposed to another team I worked with that had a huge reliability team that sat over in the corner and did their own thing and pretty much ignored everybody else and then would sit at a design review saying, well, that won't work, but it had no information about why or how or anything else. They were grumpy, stumpy, grumpy folks that just sit there and like, no, that won't work, they were less than useful and their products suffered and vice versa. Great teams that supported and augmented the design process so that they got great products out at the end of the day, and teams with no reliability engineers that had no idea why customers complained about their products. It's really about the culture around how you make decisions.

Speaker 1 11:19

That's interesting. Now, if I'm a design engineer listening to our conversation and I realize that I'm in one of those companies with a bad culture, that my reliability engineering staff is grumpy, what could they do? What can they do to improve their their design engineering if they're stuck in a situation like that, besides changing jobs?

Speaker 2 11:52

Well, that's my first reason Get your resume ready. But it is possible to change it. Don't have lunch with your favorite reliability engineer or somebody that's nominally assigned in the area that you're. If it's an electrical problem, somebody that has some electrical engineering experience or is worked on reliability of electronics, for example. If there's only one person, that makes that process easy. But it's like Ed told me he says you only bring me problems, I need solutions. I interpreted that over the years as he needed information to make better decisions in his process as a design engineer. I need these resources.

Speaker 2 12:37

It might be with the reliability team, it might be to your director of engineering, to wherever it is, as you recognize that, hey, I need to know if this solution or this solution is the right one from a reliability point of view, because it has a huge impact on, say, warranty or customer satisfaction. I understand that. That's why I'm asking At that point. It might not be phrased in a way a reliability engineer would understand it as oh, we need to run this test. That's where that discussion goes in. What are the tradeoffs in this decision? What are the constraints? What type of information do you really need to know? Then go figure out what to go do about it If the reliability team is off in their own corner. It's have lunch with somebody, start that discussion and saying this is why this is important. Can you help me with this? It might be a skunk works. If nothing else, then if it works and you make the right decision, don't move on and ignore it and say, hey, it's not failing in the field. Let people know both the reliability team and your engineering team going. I got this great information from this person that helped me make the right decision and we don't have problems. Here's the evidence, here's the information, here's what we did and how it worked. Let's demonstrate that hey, if I get the right information, I can create a reliable product.

Speaker 2 14:09

It doesn't happen because you run a bunch of tests at the end of the day or do a parts count prediction. It happens because we make the right decisions and anybody in the team can start that conversation and make that clear that it makes a difference. Sometimes it's going through the barriers get through, knock down the silos and things like that. At the end of the day, you're the person in charge of making this decision. You need better information? Well, go get it. If it's ignoring the reliability team, you can make the argument that their budget should go away and just move it to the design. I've seen that happen too is if they're not useful, get rid of them. If they're actually useful, they're a godsend. They can start on a one-to-one conversation. What's your experience with this? I'm looking at these design options. What kind of failure mechanism should I be worried about? It's a mini-FMEA. At that point, find somebody that's willing to talk to you in that realm and get moving on it. Or the other option we said get your resume together, move companies. Another one is go find the resources through your channels that you can. Or three is do it yourself.

Speaker 2 15:33

Reliability engineering is not, in here, as difficult as setting up a brand new integrated circuit and building a new fab that actually creates these things at such intricate dimensions, which a lot of engineers.

Speaker 2 15:49

That's a great challenge.

Speaker 2 15:51

Setting up an accelerated life test or thinking through the failure mechanisms is not rocket science.

Speaker 2 15:56

Unless you're working with NASA, then everything's rocket science.

Speaker 2 16:00

Exactly, the idea is is that you don't have to be a reliability engineer to create the information you need. Starts with recognizing you need better information and then go do the research. Go talk to people, go find the more experienced people with this particular material, set or whatever, or run that test yourself. If you need that information, go get it. If you have a staff that is budgeted just to help you with reliability stuff, well that's you know. Tap into that resource and make better decisions. And so I think, as a reliability engineer, it's a joy working with a design team that says you know I can do a lot of this stuff, but you set up and run the accelerated test because we really need to know which one of these will last for 20 years and it's a new material and here's why it's important, and so on. That's great, that's fun stuff, but it's even more beneficial to the organization if your input is considered on those early decisions and on the trade-offs that are being made that incrementally make an impact on the reliability performance of the product.

Speaker 1 17:20

You're good advice for the product design engineers. I mean, you've had a lot of it in this interview here, but the one of them is just identify where you're trying to make a decision, identify what information you need and then work to go get it.

Speaker 2 17:37

And yeah, there are lots of options to do that, and it's not waiting for some test that may or may not inform your decision one way or the other, and it might be too late, so that's not going to help.

Speaker 1 17:48

Well, fred, do you have? I know you're going to have some recommended podcasts and websites for the product design engineers. Well, especially with those that want to learn a little bit more about reliability, you have a shundo reliability and you've been curating lots of reliability information and tutorials for a long time. Do you want to talk a little bit more about that?

Speaker 2 18:11

Sure, the site started really out of. A handful of consultants started reliability engineering consultants. We were writing blogs and short tutorials. It's just a way to attract clients, essentially, but also as a way to give back to our industry and help people learn reliability engineering. One of the surveys we did with the audience that visits the site was that there is about 20% of the audience or people that visited the site looking for information were to identify themselves as design engineers and I thought that I wish I had more that were well, what is a fault tree versus a black diagram, and which one would be useful for me to model my system so I know where to focus and make better decisions.

Speaker 2 18:58

For example, or what are these tools? How do I ask the reliability team to do this versus that if I don't know what those terminology is or what? I don't have a reliability team yet I got to make a reliable product. How do I go about doing that? So there's over 60 different contributors not all active anymore, but there's close to 6,000 articles and podcasts and webinars pieces of content to cover all kinds of aspects of reliability, quality, safety, risk management and so on. Sometimes that's and I'm working to try to make that easier for people to find what they're looking for. But if you ever have a question, just leave us a note or a comment or a question and we'll help you find that information or find somebody that can create it or answer your question directly. We do have a pretty good network. The other place I go, diana, is the book that Carl and I put together is called the Process of Reliability Engineering.

Speaker 1 20:03

That was just released last year, right.

Speaker 2 20:05

And it's based on. I mean, there's plenty of articles and content on the site, yet the book puts it all together in a process, that structure and format. What are you trying to achieve? And then, where are the gaps? What's holding you back from hitting your targets for budget, costs, functionality and reliability, quality and so on? For more information on tech, please feel free to share your comment as well, thank you. And then, what can you do about those things? And then, what are those key, pivotal decisions? How do you identify those? And then, what can reliability do about that? How do the considerations of these different reliability tools?

Speaker 2 20:46

Nowhere in the book do we say that you have to have a reliability engineer. It's not a luxury many organizations have, or problem some organizations have. But the process is really aimed at that development process. If you're going to make a product, there's going to be decisions, and if you make poor decisions you will get poor results. And so part of that. If reliability, is that all on the radar. If you don't have reliability goals, you don't care about it, you just chunk out commodity products, well then, that book's not for you. Yet if customer satisfaction, the cost per new purchase or new customer, all of those things in many, many industries hinge on the reputation of a reliable product or the actual performance of a reliable product. If those are part and parcel to your business, then understanding how reliability happens in the product design process is what that book really addresses, and it gives you lots and lots of very detailed steps to actually create a reliable product that meets your objectives.

Speaker 1 22:01

Now can you share the name of the book again?

Speaker 2 22:03

It's called the Process of Reliability Engineering.

Speaker 1 22:06

And it's by Fred Schenkelberg and Carl Carlson. It's catchy title, eh, yes, Now you have your website, but if listeners wanted to contact you, would the About Us or Contact page on your website would that be the best place to go?

Speaker 2 22:22

Yeah, LinkedIn, the About page, my email and contact forms are all on there. I'm not hard to find, there's no doubt about it. And if, Diana, you want to list the email address on the show notes, that's fine. Yeah, I try not to be hard to find. I might not answer the phone if I don't recognize the number, but it's different.

Speaker 1 22:46

Well, that's probably because somebody wants to buy your car or sell you a warranty Clean my ducks in my house.

Speaker 2 22:53

duck worked in the house.

Speaker 1 22:55

But yeah, Fred, thanks for coming on the Quality During Design podcast.

Speaker 2 23:00

I'm honored to. Thanks for the invite.

Speaker 1 23:01

You always have good stories and experiences to share that drive home the point, and I always really enjoy listening to those. So I think what you've shared today will be a big benefit to the product designers, and I hope they think so too. Thanks for joining me.

Speaker 2 23:20

Very welcome, glad to be here and have a great rest of your day.

Speaker 1 23:25

Thanks for listening to this special episode of the Quality During Design podcast, which is part of our a chat with cross functional experts season. If your podcast player does use seasons, this interview series is part of season three of our podcast. Otherwise, on qualityduringdesigncom, at the podcast blog you can search for chat with cross functional experts and it'll come up with all the interview series that we've done so far for the podcast. This has been a production of Dini Enterprises and thanks for listening.