Dealing with Field Data

Comments

1. Joel says

   November 15, 2022 at 10:45 AM

   Hi Frank,

   Love the topic and conversation. Thanks to both you and Carl for sharing your knowledge.

   You discussed how Design notes or Design guidelines can help with design-for-reliability at early stages of the development process. My question is, how did those notes get in front of the right person at the right time to help them make a good design decision? Were there application or part specific libraries that engineers were required to check before moving forward with a design decision? Were they documented in specifications or prints? How were those “golden nuggets” saved and presented so that the critical wisdom was guaranteed to be passed along?

   You gave the example of Phil who made sure cracked capacitor issues were addressed in his project, but this was really an example of a single person with a passion to make sure a specific problem was solved. I’m wondering if there are PROGRAMMATIC best practices here that you have seen used before?

   Thanks!

   Reply

   • Fred Schenkelberg says

     November 16, 2022 at 1:21 PM

     Hi Joel,

     Thanks for the note and questions –

     First, the lessons learned process called ‘Golden Nuggets’ is a process of finding suitable lessons that would benefit with routine reminders – and the interaction of a person with ‘veto’ power related to product launches – to meet with the person setting the project resouces and provding the tasks/schedule for the team. Here’s a bit more on it in an article https://lucas-accendo-site-speed.sprod01.rmkr.net/lessons-learned-via-golden-nuggets/

     On design notes/guidelines – this one is trickery as it often requires a culture that wants to use the notes/guidelines as the members acrsoss the team understand the value of getting reliability right, right from the start.

     In the best situations, I’ve seen routine training of all engineers and managers on DFR techniques, including guideline use. Along with wide spread distribution of notes/guideliens, along with meaningful technical support for any questions concerning the use of those guidelines, plus, and this one may be the most important, a local to the design team, a reliability champion (may or may not be a reliablility engineer) that encourages using guidelines and helps discuss applications and exceptions. The champion may be part of the design review team and encourage the use, etc.

     Another approach, depending on the culture, that sometimes works is if the project manager and/or director of engineering encourage, expect, and reinforce the required use of the DFR guidelines.

     When I was at HP we had electrical derating, thermal design, and environmental considerations/testing guidelines. In the best reliability performance teams these were dogged eared and routinely used by the development and design engineers. It was what they did, it was how they went about creating a design. In other organizations, the use of guidelines was still a work in progress with pockets that used them.

     The trick, I think, is to be sure to document the use and related benefits – find examples with your teams were this happens and make sure they get credit for their DFR work. The product will just work, and that doesn’t typically happen unless there is a widespread and routine use of DFR guidelines, IMHO. By just working, it may not be noticed what caused that to occur.

     cheers,

     Fred

     Reply