Reliability Culture

How Leaders Build Organizations that Create Reliable Products

Adam P. Bahret

• Publisher: Wiley
• Year: 2021
• Print ISBN: 9781119612438
• eBook ISBN: 9781119612452
• Edition: 1
• Topic: Tecnologia e ingegneria
• Subtopic: Leadership

By outlining how reliability engineering practices fit within a product development program, the reader will have a better understanding of how roles and goals align with the program and how this applies to their specific role.

Reliability Culture: How Leaders Build Organizations that Create Reliable Products, will help readers develop a deep understanding of reliability, including what it really means for organizations, how to implement it in daily operations, and, most importantly, how to build a culture that is centered around reliability and can generate impressive profits. When senior leaders work toward reliability, product details often get lost in translation. This book will enable organizations to overcome this problem by showing leaders how their actions truly affect product development. They will be introduced to new methods that will immediately enable them to have carefully crafted product specifications translated into matching, highly reliable products. This book will also be a breath of fresh air for reliability engineers and managers; they will see their daily struggle identified and will learn new methods for advancing their passionate struggle. These new methods will be clearly explained, so readers can begin the important process of incorporating and promoting reliability in their organizations. Benefits of this book include:

• For the organizational leader, this book provides tools for aligning reliability objectives and methods with the companys business and brand goals
• For the reliability engineer, this book identifies and proposes solutions for integrating their discipline within the larger program objective and activities
• Engineers and leaders alike will benefit from detailed discussions of product negotiation, program assessment, culture change methods, and more
• All readers will understand the progression of product design methods over the previous decades, including how market acceptance is changing

Reliability Culture: How Leaders Build Organizations that Create Reliable Products is intended for a broad audience that includes organizational leaders, engineers of all disciplines, project managers, and business development partners. The book is aimed at outlining how reliability engineering practices fit with all program activities, so any team members will benefit.

1
The Product Development Challenge

Rather than looking at concepts in the abstract, let's get down and dirty. I want to share a story with you about how product development goes wrong. In uncovering these traps, we'll then be better set up to talk about fixes.

What follows, then, is a kind of case study that highlights problems. And it’s not based on a single company. Instead, the particulars are drawn from dozens of real life situations, which I've disguised.

Key Players

You and I work for Amalgamated Mechanical Incorporated. The company is hot about creating a new medical procedure robot. We're on the reliability team.

It's critical that our robot get out there quickly, because our #1 competitor is on the verge of introducing a similar product. To get a jump on them, our product needs to hit the market in 10 months’ time.

According to the program plan, the Accelerated Life Testing (ALT) for the robot's arm should start next week. As far as we know, we expect to receive the arm samples in three months. If the ALT testing begins in three months, however, there's little chance we'll have accurate predictions on how and when the product may wear once it hits the market.

For all practical purposes, even if we provide that test‐based prediction for the arm's wear‐out failure rate a few months before release, it will be of little value. There's no alarm big enough to sound that would delay release, based on premature wear‐out. Even if we discovered that the product wore out, not in the promised five years of normal use but in one solitary year, the leaders would still release on schedule. (After all, they'd reason, we have to beat the competition to market.)

It's been said before by our VP: “We'll release it now and get a fix out there quickly. We already have a punch list for version 2.0.”

In many ways, the project has been designed to fail. For me, it feels like trying to stop a freight train that's built up a head of steam. Stepping in front of it creates a mess, and the train still pulls into the station on time.

Half the program's reliability testing was to provide input for program decisions:

• “How confident are we that the arm will reach its life‐and‐reliability goals?”
• “What's the robot's end‐of‐life failure mode?”
• “Should we create a preventative maintenance cycle or shorten the robot's promised life to customers?”

This is critical information in a product development program and we don't have it yet.

Why does it always go this way? It's actually made me think about changing disciplines to something other than “reliability engineering”. Why have a career focus that doesn't improve products and is often just a check‐the‐box nicety?

The product did indeed release on time. The reliability growth (RG) testing showed low statistical confidence in the goal reliability. This is the most critical assembly and we don't believe it will work as it should, and we're going to release it anyway. This is crazy! The ALT testing was never finished, because there was a design change and we didn't receive new arms to test. So we don't know when it'll wear out. How scary is that?

These arms could start failing in large numbers in the customers' hands, because of a predictable wear‐out failure mode. Statistically, the majority of the population will fail at this point, with a nice bell curve outlining the full population. More than half of the Failure Mode and Effects Analysis (FMEA) high‐risk actions weren't addressed. Some of these actions had “user harm” in the severity ranking.

We released on time. About four months after product release, the field failure rate began to spike. Two specific failure types were dominant. The linear X axis bearing and a plunger that penetrates a consumable. Both see high cycles in use, and both were known to be high risk due to changes in the most recent design.

These spiking field failures were the main topic in every Friday steering meeting and hallway conversation. If someone had information, the CEO wanted to hear it. If there were no updates on the root causes and fixes, he yelled about wanting to know what everyone was doing all day.

For a reliability manager, the entire process was depressing. No real value was delivered from our team's work. As a matter of fact, we were usually seen as a nuisance – almost as if we were an outside regulatory organization, but without authority. Something akin to a kid on a Big Wheels pulling over highway motorists and issuing traffic tickets in crayon.

Now that there are high field‐failure rates, people are murmuring, “Well, there's no single person to blame for all these failures… but… aren't you the reliability team? Why did you let this happen?”

As I said, I find myself thinking of abandoning the discipline I love, because it can feel pointless.

Taking a step back, I thought about the program's reliability experience from all the other roles involved. The project managers received bonuses for releasing the product on time. The R&D engineers were promoted and assigned to top‐notch programs because of the features they developed. This was all celebrated at a fancy hotel with an offsite party and a band.

OK, that all happened at release. But what happened when the robotic arm assembly began to fail early in life? Surely, that was the moment of reckoning, wasn't it?

This is the team's experience when the failure rate spiked four months after release: they were called together as a “Tiger Team.” This means they were borrowed from their new programs, because they were supposedly the only people who could save us: our “heroes!”

During this recovery phase, the Tiger Team got regular facetime with the CEO. Facetime with the CEO is a key element in someday climbing into upper management. Many of us would take a CEO face‐to‐face over a 20% raise. For the Tiger Team, this experience was pure gold.

Then, when the field issues were solved and the company was saved, there was a celebration with a festive banner and a big ice‐cream cake.

As the legendary management leader Edwards Deming said: “One gets a good rating for fighting a fire. The result is visible; can be quantified. If you do it right the first time, you are invisible. You satisfied the requirements. That is your job. Mess it up, and correct it later, you become a hero” [1].

So, in summary, they were rewarded for casting reliability aside to enable meeting only one goal associated with their role: time to market, new features, or cost point. They were then rewarded again for fixing the field problems they themselves created.

Remarkably, the team was doubly incentivized to deliver a product that was unreliable. How could this be? Why did the program's executives engineer things this way? After all, it hurt them most.

But if I'm making it seem like everyone involved in this failed program was rewarded, I'm confusing the issue. People were indeed punished. Who? Those who really wanted to create a product that was reliable. What happens to those people? The next story shows that they have one of two paths.

Follow the Carrot or Get Out of the Race

The leadership of a large 90‐year‐old company asked me to evaluate their culture. In my report, I included a story. It had passion, reward, and, most importantly, punishment – all the elements of a Greek tragedy. So I wrote the story and got a response better than I'd ever hoped for. Here's the story:

I began my investigation with the question: “Why is reliability missing from most engineers' work, even though we promote it so assertively as a core value?”

Walking around the company's halls, I saw posters that underlined how seriously they took quality and reliability. These posters bore slogans like “Our customers count on us for reliable products” and “Our product reliability is YOUR legacy.”

The hierarchy even jammed the word “reliability” as many times as they could into all their speeches. For instance, at the annual R&D off‐site the CEO delivered an 11‐minute talk, and used “reliability” eight times. That's almost one “reliability” per minute. I'd already been there long enough to understand the hypocrisy. That's why I was counting.

The company liked to hand out reliability awards. But these awards were largely empty. They rarely included bonus money or anything that resembled actual career growth.

It was easy to see management's true motivation. The late quality guru Philip Crosby said, “An organization is a reflection of its management team.” There's no hiding what the boss truly values. Where this is most obvious is with things like sizable bonuses or meaningful promotions.

At this company, I saw engineers and developers rewarded when their product was on budget and on schedule. There's nothing wrong with handing out rewards for these accomplishments. Unfortunately, these were the only things for which the engineers and developers were rewarded. More notable accomplishments – like excelling at the full set of program objectives – were ignored.

To the team, upper management's reward‐incentivized message was clear: “This is what we really value.” The next level of management down had no choice, then, but to prioritize these same on‐budget, on‐schedule metrics above all others.

The written report I would later send to the organization's hierarchy had only two characters, Engineer #1 and Engineer #2. (Those weren't their real names. If they had been, it would have shown some amazing foresight by their parents.) These characters were a composite of the actual engineers on that team.

They differed from each other in a very important way. While they were both good engineers:

• Engineer #1 focused on budget and schedule, because she wanted the bonus and was ambitious enough to crave a promotion. She was attuned to what her management team valued, so she behaved accordingly.
• Engineer #2 followed her inna...

Table of contents

• Cover
• Table of Contents
• Title Page
• Copyright Page
• Series Editor’s Foreword by Dr. Andre Kleyner
• Acknowledgements
• Introduction
• 1 The Product Development Challenge
• 2 Balancing Business Goals and Reliability
• 3 Directed Product Development Culture
• 4 Awakening
• 5 Goals and Intentions
• 6 New Roles
• 7 Program Assessment
• 8 Reliability Culture Tools
• 9 Guiding the Program in Motion
• 10 Risk Analysis Guided Project Management
• 11 The Reliability Program
• 12 Sustained Culture
• Index
• End User License Agreement