Accendo Reliability

Your Reliability Engineering Professional Development Site

You are here: Home / Podcast Episodes / SOR 374 Reliability Security Blankets

by 6 Comments

SOR 374 Reliability Security Blankets

Reliability Security Blankets

Abstract

Chris and Adam discuss ‘reliability security blankets.’ What are these? These are things that people or organizations do to give the illusion of ‘achieving something to do with reliability’ primarily to make them ‘feel’ better. Reliability security blankets tend to have little positive benefit. When we are focused on a feeling of ‘reliability goodness’ we quickly try to find the easiest way to get that feeling. Which leads us to standard or outdated methods, non-critical thinking, or (worst case) tests that are structured to ensure a system or product passes. Resources are sucked away from good reliability activities to create these reliability security blankets. If you think this applies to your organization, listen to this podcast.

Key Points

Join Chris and Adam as they discuss one of the main issues that organizations that deliver products or systems – ‘reliability security blankets.’ Many engineers and organizations do things primarily to make them ‘feel’ better about doing it. This is a significant problem when it comes to reliability. Reliability is difficult to measure, so we can easily allow ineffective activities to give us this ‘feeling’ we crave. But if we keep solving the problems we want to solve, the problems that need to be solved never get addressed. And they will become apparent soon enough.

Topics include:

  • regulations and regulatory bodies that are not able to keep up with quickly emerging technology but whose comprehensive set of compliance activities result in designers and manufacturers stop thinking about making a reliable system.
  • customer driven organizations tend to be the ones that race to find failure where bureaucratic organizations tend to avoid even talking about failure as they focus on meating bureaucratic development milestones.
  • compliance replaces critical thinking.
  • testing to pass and not to learn means that reliability never improves, but we think it does.
  • the customer is the arbiter, with many engineers not understanding this, arguing whether a failure from a customer’s perspective was an actual failure as if there is a courtroom debate.
  • FMECAs and other activities can be fantastic enablers or exhausting anchors as good ones are an enduring guide to design, while bad ones are resource intensive ‘white elephants’ that taint ongoing perceptions of its relevance.
  • bringing the team back that created the problem in the first place, which is almost rewarding incompetence the meant they didn’t initially create a reliable system.

Enjoy an episode of Speaking of Reliability. Where you can join friends as they discuss reliability topics. Join us as we discuss topics ranging from design for reliability techniques, to field data analysis approaches.

SOR 374 Reliability Security BlanketsChristopher Jackson
  • Social:
  • Link:
  • Embed:
Download Audio RSS

Show Notes

 

Comments

  1. Loved this episode.
    Bringing in SMEs to perform effective FMECAs is the punchline.
    Need a change in organizational reliability culture to avoid coming in a complete circle with the same team performing reliability enhancement tasks when not enough time and resources were allocated in the first place.

    Regards,
    Jay

    Reply

  2. Thanks Jay!

    Much appreciated. I would be interested if you (or others) would be interested in expanding this discussion topic further. If yes, please let us know!

    Chris

    Reply

    • Sure. My two cents below:
      I come from the avionics industry – IFEC to be specific. We design and put equipment on airplanes for big players in the airline industry.
      The thing I most relate to is meeting reliability requirements is looked at more from a compliance standpoint rather than improving design. Management realizes the cost of not being “reliable enough” after they start seeing field failures that impact the service revenue and company’s bottom line and reputation. By that time, it is too late to make changes to the current design. All you can do is put out fires and apologize. By the time the next design cycle comes around, those “lessons learned” are forgotten and we’re back to square one. There is a disconnect between development and service engineering.
      Since we are not “safety critical” equipment on the airplane, money and resources are not invested in achieving reliability from the beginning. Which brings us back to my initial comment of involving the same team to “fix” problems that could have been avoided in the first place.

      If it seems like I’m blowing off steam, thanks for listening. I’m fairly new to the corporate world and am not sure if there are other folks that find themselves in a similar situation more times than they would want to.

      Jay

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *