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

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

This episode is part 1 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 Product Design

Speaker 1 0:00

Welcome to the Quality During Design podcast. I'm Diana Dini. You're listening to part one of a two-part episode of an interview with Fred Schenkelberg. In this interview, we're talking about reliability engineering and their function in the product design process Not just what they do, but how product design engineers can interact with and get the best value from working with reliability engineers. 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 tell you a little bit more about Fred and what you can expect in this part one and the next part two of this interview Right after the brief introduction. 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 in how to apply quality during design to their processes. Listen in and then join us. Visit qualityduringdesigncom.

Speaker 1 1:30

I was very pleased that Fred agreed to join the Quality During Design podcast and let me interview him for this series. Fred is a reliability engineer and management consultant and he's also the founder of Ashendo Reliability. Fred's expertise is program development, accelerated life test design and analysis, reliability statistics, risk assessment, test planning and training. He's a graduate course lecture with the University of Maryland, the initial producer of the ASQ Reliability Division webinar program and a regular speaker at Rams, the Reliability and Maintainability Symposium. He also founded and maintains a website, AshendoReliabilitycom, which is a reliability engineering professional development hub. That's Ashendo Reliability, spelled ACCENDO.

Speaker 1 2:26

Fred joined me on the Quality During Design podcast to talk about reliability in ways that affect engineering decisions and also to share actionable steps to best work with reliability engineers. In this part one of our interview, we're really kicking off the interview itself, but also talking about the kind of issues that are seen during product development understanding the issues and why it's important and what actually is the problem. We also talk about how the design team may prioritize and make decisions and what level of detail is necessary for them to be able to make those decisions. In our part two of our interview, we talk more about these themes, but focused on the culture of how teams handle information and how reliability engineers can help a team do a triage to help understand problems that they're facing or to help them make trade-off decisions within their own designs.

Speaker 1 3:28

Besides being an experienced reliability engineer, Fred is also very involved in the promotion of reliability engineering methods, speaking about them and promoting communication and conversations involving reliability engineering. Before Fred and I started talking on the Speaking of Reliability podcast, I would use his website, Ashondo Reliability to help me with my reliability endeavors. I really enjoyed talking with Fred because he always has a story to tell around the point that he's trying to make. You'll be able to see yourself or imagine yourself in these kinds of situations and may even recognize some of them, and Fred's stories will inspire you to maybe think about reliability engineering in a different way, especially when it comes to product design engineering. Hey, Fred Schenkelberg is here to talk about reliability in ways that affect engineering decisions and share actionable steps to best work with reliability engineers. Fred, welcome to the Quality During Design podcast.

Speaker 2 4:37

Well, I'm happy to be here, Diana. Thanks for the invite.

Speaker 1 4:40

We talk a lot on podcasts and online through some of the other podcasts that you have running, like Speaking of Reliability, but now you're on the Quality During Design podcast, so I appreciate being able to interview you here for the product design engineers.

Speaker 2 4:59

Well, I'm happy to be here. It's reliability. Engineering is not worth much of anything unless somebody's actually making decisions. So design engineers do that in spades. They do it all day long. So it's the folks I'd like to talk to more often too. So I'm happy to be here.

Speaker 1 5:15

You've been involved in product design in the past, so what are the kind of things that you like about product design? Now you kind of start saying, well, without product design engineers, reliability engineers wouldn't have anything to do.

Speaker 2 5:28

But it's true. It is true, I mean. I start off with the opposite of it, though is in my career I first started as a manufacturing engineer and every now and then, a design engineer would walk onto the factory floor. We were all co-located, which was, in hindsight, a great privilege to have design and manufacturing and our production facility all in one building. And every now and then, one of these design folks that had clean hands and all this other stuff they'd show up and say, hey, we need to run this experiment, we need to do this, we need to do that.

Speaker 2 6:02

My job was to do that create this prototype form. Basically, and nine times out of 10, they didn't work. They weren't doing what they were. They didn't do what was expected for our particular product. So I learned very quickly it's always the design's fault. If only they could create something that was really easy to manufacture and did all the functions and features, my job would be piece of cake, it'd be really easy, but they would create impossible tolerances and all kinds of other things, and we'd have to teach them that, no, you can't do that kind of thing.

Speaker 2 6:39

So my first intro to design engineers is that they don't really know what they're doing, and. But over the years I've realized that there's a whole lot of tradeoffs and that's where the decisions come in. Do I go with this vendor or that vendor? Do I use this material, that material? Do I do this? And they have cost pressure, they have quality and reliability stuff. They gotta do functions and features. They got a deadline. Oh and, by the way, they have no budget. You know kind of thing. It just it's amazing that products do get designed Is what my long term takeaway has been about designing a new product.

Speaker 1 7:15

Yeah, and that gives me a perspective too that you know when I do get a product that works really well, I really appreciate it because I understand all that stuff that went into making it. And I agree with you, it is difficult and there's a lot of things to consider.

Speaker 2 7:32

Yeah, I had. I was working on a with an electrical engineer. He was the lead design for the, essentially the motherboard of this product. He would not return calls, or you know, and pretty much tried to ghost me all the time. And I'd walk past his cubicle and his shoulders would slump and I'm like, what's the problem, ed? Why, why such a greeting? You know, I am Fred, I'm here to help and all you do is bring me problems and I don't need more problems. And I, oh, okay, well, what, what should I do about that?

Speaker 2 8:08

And he says, well, how about you help me solve some of these problems? You know, if it's not reliable enough, well, what do I do about it? You know, what's the particular issue that I can go do something about? I'm like, oh, I can do that. So instead of saying hey, this component's too close to here and the screw down will bend it and it'll break, and that's a reliability issue, I said, well, here's the keypouts, you know, here's the issues, here's the nature of that failure mechanism, here's why we can't put that part downstream of this really, really hot part. But and then I actually showed him the board after we ran it for about 10 minutes and it would melted the component downstream. You know he says, oh okay, now I get it, I can do something about that. But so I learned firsthand by an engineer that was pretty frustrated with me saying, well, what do I do about this kind of thing?

Speaker 1 9:01

So you were giving him information that something wasn't good, but he was just looking for a little extra information to be able to make a design decision with.

Speaker 2 9:11

Right. Well, think of it as and I've seen this in so many different companies they have a customer support or a call center type place. Right, a lot of them are, you know, honestly, trying to help the customer, and they have a deluge of calls or issues, and they are understaffed, and they don't. The people on the phone have a script oftentimes that they're working with. Sometimes you get somebody that understands the product and what the issue is and they're trying to troubleshoot it with you. The vast majority, though, is that customer called, said it wouldn't power up, and so they create a predo at the end of the month and they send it off to the design teams. With number one issue it doesn't power up. Well, electrical engineers looking at that go okay, there's only 400 ways that it could not power up. What do I go? Fix Everything. And so the disconnect is that, in dealing with the customer side and trying to make it whole for them, it's a whole different dialogue than, well, what can we go fix when you walk in whatever role you have, and you're saying, hey, this part's got too much variation, it's causing problems? That's a bit more specific, and that's something that we can go get data on, we can run experiments on, we can do DOE, we can do all kinds of stuff to look at what the options are to reduce the variability, reduce the variation that's causing issues. But if you just say, no, the tolerance are not right on that component, it's like, all right, what do I do with that? It doesn't power up. Okay, that's not useful, I can't do anything with that. So part of the role with anybody dealing with a design engineer is if it's an issue, why is it important? How many millions of dollars is this going to cost us if it doesn't get fixed? Because if it's a trivial problem, don't waste their time. But if it's a serious problem and it's going to double the warranty rate or do something like that, then say that this is why this is important, this is why I'm bringing it up. And then, what are the details of that? And you've heard me talk about it all the time.

Speaker 2 11:31

Diana is talking about failure mechanisms. Well, what actually is the problem If there's too much variation in this component? What fails? Why does that cause a problem and what's the nature of that failure? So do we need a different component that's tighter, or do we need a different tolerance, or do we need you know what are the options and then rely on the knowledge of those design engineers of saying, well, here's what's possible, because they're more versed in scheduled time, functionality and the design for acts, which is well beyond just reliability or quality. And then it's a trade-off, which is what they're paid to do. It's create a function on time in budget, which sounds easy, doesn't it?

Speaker 1 12:16

So it sounds like one of the major challenges in well, from the product design engineers standpoint, with what we've been talking about here, people are just coming up to them with problems, but they're not really well-defined problems, and they don't know what to do about it.

Speaker 2 12:33

Well, yeah, it's hard to prioritize it if you don't understand what's the nature of the issue. You know what's the root cause is something that we're always looking for. And if you just say, hey, that doesn't work, okay, what do I do with that? What's not working?

Speaker 1 12:50

And what generally happened is just nothing would be done about that Because there's other stuff going on. Right, that's right.

Speaker 2 12:58

There's plenty of other things. We know it's a problem and it's a high priority and we're gonna go focus on that. And part of it is you know, how does your design team prioritize and make decisions and what's the level of detail that's necessary to fit in that program. You know even a small team and I was working with one team that they met I think it was every three days, it was like sometimes twice a week and the design team, the project manager and a handful of other folks that were there said all right, here's the things we learned in the last two, three days that are issues which ones? You know it was basically a fracas prioritization meeting. It's where we said here's what we know doesn't work. Which ones can we work on? Which ones do we need more information? So some of the tasks were all right, bill, you're the lead electrical engineer. Here's the big issue for this week. See what you can do with that. And then other times is like we don't really understand what's causing this. All right, sarah, let's work on the root cause of this and see if we can replicate it and get some more information on it.

Speaker 2 14:04

And it was an ongoing, regular dialogue of do we know enough to do anything about this and do we know, is it important enough that we need to solve it?

Speaker 2 14:15

And it was a culture where, yeah, we're gonna learn stuff and we're gonna go fix it.

Speaker 2 14:21

You know when it's necessary to go fix it and there was resources available to go do that. So it was a lot of fun working in that group, versus the one that everybody was afraid to record anything in the trouble list, basically because you would be assigned to fix it. It independent of whether it was software, hardware, you know a supplier issue or whatever. If you brought it up, you were in charge of fixing it. So people just didn't bring anything up unless it was something that was their area of expertise. So the culture around how you deal with information and what's the acceptable level of detail around it so that you can prioritize it and actually take steps to solve it, is really, really important understanding that whole process and that whole system, and for not just reliability engineers. Anybody in the organization and apparently nobody ever taught the marketing department that because you know, three days before launch they come in and says oh no, no, no, no, no. We need to make it blue with this feature instead of that feature.

Speaker 1 15:30

Well then that just doesn't happen. Yeah, so that's a good point that you make about, because a lot of product design engineers are working on new product development, so there are things happening and there's a constant flow of information coming in. Hopefully, earlier marketing says I need this to be this blue color, but then, yeah, there's things happening with suppliers and in the test lab, so there's constantly new information and adjustments and root cause and else all that stuff going on. But then sometimes product design engineers are also responsible part of a team that's monitoring something that's already in the field, which I think is related to that fracas example you gave. Right. This is stuff that was in the field and there were things happening and the team had to prioritize and research what they were going to do about it.

Speaker 2 16:31

It's both there's the field response type stuff and then in some of that, having that the design team aware of what's happening in the field it's kind of their report card and how well the design went and how well they understood the market and the use conditions and so on. Yet it can take a lot of time away and there's a thousand units out there and that's more important than the one that we've got six months before we launch, kind of thing, because it's costing real money and warranty and so on. So some organizations separate that so that you only get to the design team in extreme circumstances, which breaks the link of the design team to how the customer is actually using the product or abusing the product in some cases and understanding all those needs and requirements and so on. There's a trade-off there. You don't want to spend all your time fixing the last product because it limits the time you have available to get the next one right. So it's a dilemma there.

Designing Circuit Boards

Speaker 2 17:34

So there's parts of that trade-off, so part of it is. I remember when this ad this guy I was working with was the electrical engineer, they had a new design and the mechanical engineer said, well, the only way we can mount this is in an edge connector and it's going to stand vertical on the side of the printhead. This is an inkjet printer and the printhead was massive. So when it went back and forth it would shake the whole system. I'm not an expert mechanical engineer yet I knew that if you bend a circuit board it makes really not good, sounds like things breaking. And I thought if you're going to put a diving board which was the circuit board and it's intended to take up that motion by bending, it is not going to last long. And so I bring this up the ad and the ad's an electrical engineer. He puts the stuff on the circuit board and wires the circuit. He's not in charge of where it goes. And so we went over and talked to the mechanical guys and they said, well, the tolerance stack up to get from here to there and everywhere else and stuff, and it's like 47 steps and it's not possible. Oh man, and they had the drawings, they had all this stuff and saying, well, we couldn't even locate a screw hole on this thing because of the stack up and so many parts and so many steps and so many alignment issues and stuff like that. And I said, you know, circuit board is going to break. And no, no, no, they're flexible for up to a point and we're going to only do this much. You know, it's only going to vibrate this much. Here's the simulation blah, blah, blah. And I'm still thinking to myself we're basically painting copper on these traces, so they're really, really thin. It only takes a few cycles and you're going to crack that and then it's not going to work.

Speaker 2 19:36

Well, that didn't convince anybody because they were looking at it. It's going to be a redesign of a whole bunch of mechanical parts to make it work. So it had to be really important. So it turns out that we had a high speed camera that just arrived. So we went into the lab and we took the skins off the product and we're looking at the circuit board and it stopped within a few seconds. We set it on just print, discontinuous print, and it just stopped. It just stopped printing. And we went back and looked at the high speed camera stuff and you could see this component. Just take a leap off the board and circling in the sky as it falls off and the board goes quiet. Everything stops.

Speaker 1 20:20

Well, at least you got the root cause right away.

Speaker 2 20:24

The issue is we knew that that was going to happen. Sotter and circuit boards are not meant to be bent at all, and on the production line we handled them with kid gloves. We hold it by the edges. We did all this stuff. We made sure all the fixtures and all the setting would not flex or bend these things, and here's a design that just is going to count on it. That it's going to bend, it's all right. And so all we did was we took that little clip, the video clip, and said here, watch this, you know. And the next day they had a solution. They were able to mount a bracket to stop the vibration and structure the whole thing so that it stiffened the entire product, so all the circuit boards would not get any bending moments on it.

Speaker 2 21:10

Yet at that point then, the credibility just went through the rough. I mentioned something and they're oh, we got to go check that out, which comes with the responsibilities. You don't mention everything just because it's fun. You mentioned the things that are really important and you've done the homework to say, yeah, this is useful or not useful. Now, on the other side, what happened in that organization is that the design engineers would say hey, fred, you need to be in this meeting because we want you to, because you're the expert at figuring out how it's not going to work.

Design Engineering and Reliability Collaboration

Speaker 2 21:46

Is this solution introducing a failure mechanism that's going to cause problems or in any concerns? So it became part of preventive and that was the way the team worked rather well, as they would think through and sometimes it was FMEAs and sometimes it wasn't, but they would think through well what could go wrong. And it reminds me of the, as a prologue, henry Petrosky's book called Design Paradigms. He says designers inherently design away from failure. If they're concerned about something, they're going to do some extra work to make sure it's got margin, it's got this or got that, so that it doesn't fail. It's not good for your resume if you design something that doesn't work. Where it becomes more complex is when the mechanism is slow to show up. It may take six months before it reveals itself and that's where the reliability folks that's where we tend to spend our time is the things that take our hidden defects.

Speaker 1 22:48

I mean, that's something that reliability engineers can help the design engineers with is helping to identify where you may need to test to tease out those kind of failure.

Speaker 2 22:57

Well, I find that it goes back to remembering that design engineers make a lot of decisions and every decision impacts the quality and reliability of the product at the end of the day, and some make it better and some make it worse. If we choose the cheapest vendor for this component and they have a horrible track record of controlling their process and we get a bunch of bad components that are hard to inspect, that's a bad decision, based on cost, for example. Or, even better, as somebody comes in and says well, it's the same form, fit and function, it's just a drop-in replacement and it's half the cost. Let's think about that a little bit. But the design team is going to make a lot of decisions. In some they think through are we going to use plastic or are we going to use metal? What's the basic structure of this thing? What's the basic architecture of those things? And once that process continues to lock down different major decisions, then there's less and less room to trade off things, to margin things, to do other stuff. I can't imagine the discussions around an iPhone of, well, how thick are we going to make it versus how thick does it need to be. The amount of components that are stuffed into one of those things is amazing and it doesn't just happen because somebody said, well, maybe it does. At Apple they say I want it to be less than a quarter inch and just go invent it and make it happen. I don't know.

Speaker 2 24:33

But the idea is that the early big decisions often don't include reliability and quality and everybody else. They're locking down the big chunk so they can get into the details. Part of the role is that the design team needs to recognize which one has a reliability impact. In the more seasoned or experienced engineers I've worked with, they're already thinking through this stuff. Is this going to cause problems with cracking or is this going to cause problems with vibration? Is this going to be problems with this stress or that stress or how people use the product, or will this function survive so many cycles, things like that. Part of the role is not that we can go the reliability folks can go do some testing. It's one. Is that triage piece? Can we do simulations? Can we do, you know, look at previous products that use a similar architecture or similar materials or similar components? Can we? Because testing is expensive and it takes time. The real value is that early FMEA type stuff and the early risk identification type stuff and the early decisions is if I choose this component, what's the impact on reliability? At that point it's often very much the design engineers and the supporting folks that are around them saying, no, that's good, it's all engineering judgment, it's that's good. No, that could be a real problem.

Speaker 2 26:10

In one of those discussions I was working with a team and they were doing an attachment that used very dissimilar materials. I had recently seen one of these tables that showed if these two components are together, they're going to eat each other, no matter what versus. I've seen that too and I said you know, I'm not exactly sure yet. I think that's going to be a what do they call it? What type of corrosion? Galvanic corrosion. And they all look like me. I had three heads Like what's that? Because they had consistently worked with you know, here's the material set and it was already.

Speaker 2 26:51

That problem was basically out by design degree and they said, well it's, we've got this metal and we really need to connect it here. And they were just looking in an attachment problem, not a, you know material compatibility problem, because it just never crossed their mind in the last five, 10 years of product development and so it was somebody sitting there going. You know that might be an issue. Let's look it up and sure enough, it was like one of the worst, the third from the worst possible combination you can have. And there was no testing, there was no anything else. It was like they looked at it and they double checked their own sources and that's when we missed. You know. Thanks for bringing it up.

Speaker 2 27:38

But the idea is that in the realm of all the decisions the design engineer needs to make, there's going to be the ones that keep them up at night, that they're boxed into a difficult corner and there's trade-offs. Do I dampen the vibration or do I take out the heat, or do I do this or that or the other thing? And each decision has a bunch of trade-offs. Well, that's where the reliability engineer, knowing that that's the decision, can either bring their experience and trade-offs of the different underlying failure mechanisms or create that test or do a simulation or whatever. But it's geared to what do they need to decide? It doesn't really help if, at the end of the day, you say, oh, your product doesn't work, we did a bunch of testing and it's not going to work, it's not reliable enough, that's too late, it's going to get ignored, you're going to ship it anyway, kind of thing, unless it's really really bad.

Speaker 2 28:37

So, keeping in mind that the end result is a result of many, many decisions, and some decisions impact reliability more than others, and so part of it is working with the design team to understand which of those decisions are the pivotal ones that are going to impact reliability for the good or for the worse, if it's made incorrectly. And what information do you need? And sometimes it's like oh, here's a materials compatibility book that talks about galvanic corrosion and that's all they need and they change the design. Sometimes it's this is a brand new widget from us. We're not really sure how it will fail. Ah, okay, let's do Hull. We've got 600 ways this can fail. We don't know which one's most important. All right, let's do an FMBA and sort that out.

Speaker 2 29:31

So reliability engineers that impose a suite of tasks or impose that we're going to do X, y and Z every single time are not serving the design team very well. They're checking the box, they're just doing stuff. It's the dialogue between the design team and the reliability folks is. You know, hey, fred, I'm working on this part of the design and I need to understand is this more reliable or not more reliable, because it's a trade-off either way, but which one's going to be suitable from a reliability point of view? And it's like it's a two cent difference in the final cost. But is it worth the extra two cents to get another six months of reliability out of it or not? I'm like, okay, I can answer that question, I think, and we'll go off and use the appropriate methods to inform that decision, as opposed to at the end of the project the day before launch we go. You know it doesn't work. It needs an extra six months of life. You should have asked me about this earlier.

Speaker 1 30:43

And that's what I hear a lot of reliability engineers especially say and it doesn't matter what industry they work in.

Speaker 1 30:51

Some of them worked for NASA, Some are medical devices, there's been other in consumer products. They say I really wish they had involved me earlier instead of waiting for the test at the end and I guess, kind of wrapping back to your first story, where you're the reliability engineer telling the engineer, hey, this isn't working and he said I don't know what to do with that, whereas if you got together earlier and asked for help with the reliability engineer for some of those tradeoff decisions, like you said, we're having a problem figuring out which direction to go.

Speaker 2 31:38

Asking a reliability engineer to help figure it out, to gather the information you need to make a good decision, is a great use of that partnership and that's what I'm hearing you say, yeah, yeah, summarize very well, and it's the reliability engineer that goes in and says, all right, I know what to do, we'll do a test with that. I need 600 prototypes. It's not helpful. We only have a budget for 20 prototypes and kind of thing. It's well, what can I do to help create the information that you're looking for? And it's a two-way street.

Speaker 2 32:14

The design team has to recognize that they need better information for some of the major decisions and they have reliability engineers and quality engineers and procurement folks and all kinds of folks that are there to help them make better decisions. And I think approaching it that way it's not that, oh, when we're done with the design, we'll do reliability. It doesn't work that way, guys. You're doing reliability with every decision you're making and if you're not considering the ramifications of it because you don't have enough information, well, that's the best use of the staff. The reliability folks can help you either understand the pros and cons of one choice or another or get the information to create it, to inform that decision.

Speaker 2 33:10

It's not the only driver for a decision and I think good reliability folks understand that it's part of the process of trade-off, because if the solution is that you got a gold plate, everything, and it's too expensive. Nobody will buy it. Well, is that really a good solution? And so I think the starting earlier is because that's where the major decisions are made about the architecture and the structure, and it creates boundaries of what's possible later. So starting early is great, yet it's more about the culture and how the reliability team and your folks are assisting informed decisions, and then, as you get better at that, you get invited earlier and earlier in programs because you're actually helpful, which is not a thing you hear about reliability engineers too often, unfortunately.

Speaker 1 34:16

That's the end of part one of my interview with Fred Schenkelberg. Join us next time where we extend our interview into talking more about reliability engineers, design engineers and the culture that they work in together. This has been a production of Dini Enterprises. Thanks for listening.