94,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Wissenschaft und neue Technologien
- Serie: Wiley Series in Quality and Reliability Engineering
- Sprache: Englisch
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 company s 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.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 382
Veröffentlichungsjahr: 2021
Ähnliche
Table of Contents
Cover
Title Page
Copyright Page
Series Editor’s Foreword by Dr. Andre Kleyner
Acknowledgements
Introduction
1 The Product Development Challenge
Key Players
Follow the Carrot or Get Out of the Race
It’s Not That I'm Lazy, It's That I Just Don't Care
Product‐specification Profiles
Product Drivers
Bounding Factors
Reliability Discipline
References
2 Balancing Business Goals and Reliability
Return on Investment
Program Accounting
Rule of 10s
Design for Reliability
Reliability Engineer's Responsibility to Connect to the Business Case
Role of the Reliability Professional
Summary
References
3 Directed Product Development Culture
The Past, Present, and Future of Reliability Engineering
Reliability Is No Longer a Luxury
Understand the Intent
Levels of Awareness
Summary
References
4 Awakening
Stage 1
Stage 2
Stage 3
Stage 4
The Ownership Chart
Communicating Clearly
Summary
5 Goals and Intentions
Testing Intent
Transferring Ownership
What Transferred Ownership Looks Like
Guided by All the Goals All the Time
Summary
References
6 New Roles
Role of Change Agents
Reliability Czar
Role of Facilitators
Role of Reliability Professionals
Summary
7 Program Assessment
Measurements
Using Reliability Testing as Program Guidance
Reliability Maturity Assessments
Summary
References
8 Reliability Culture Tools
Advancing Culture
Reliability Bounding
Strategy Bounding
Bounding ROI
Anchoring
Focus Rotation
Working in Freedom and with Ownership
Summary
9 Guiding the Program in Motion
Guidance Bounding
Guidance Bounding ROI
Using Bounding
Program Risk Effects Analysis
Summary
10 Risk Analysis Guided Project Management
Failure Mode Effects Analysis Methodology
Design Failure Mode Effects Analysis
Reliability Design Risk Summary
Process Failure Mode Effects Analysis
Use Failure Mode Effects Analysis
Failure Reporting and Corrective Action System
Root Cause Analysis
Brainstorming
Summary
References
11 The Reliability Program
Reliability Program Plan
Common Reliability Program Plan Pitfalls
Major Elements of a Reliability Program Plan
Summary
12 Sustained Culture
Lasting Change
The Seven‐stage Process
Summary
Index
End User License Agreement
List of Illustrations
Chapter 1
Figure 1.1 Grandfather's tools vs my tools.
Figure 1.2 Reliability timeline.
Chapter 2
Figure 2.1 Reliability ROI.
Figure 2.2 The rule of 10s.
Figure 2.3 Traditional design process.
Figure 2.4 Improved design process.
Figure 2.5 Comparing design processes.
Chapter 4
Figure 4.1 Ownership chart.
Figure 4.2 Accountability notation.
Figure 4.3 Accountability chart.
Chapter 6
Figure 6.1 Reliability czar.
Figure 6.2 Shirt and phone ranked factors.
Chapter 7
Figure 7.1 Reliability bathtub curve.
Figure 7.2 Stress strain overlap.
Figure 7.3 Increasing margin.
Figure 7.4 Bathtub curve.
Figure 7.5 Real bathtub curve.
Figure 7.6 Critical bathtub curve elements.
Figure 7.7 Maturity matrix (part 1 of 2).
Figure 7.8 Maturity matrix (part 2 of 2).
Chapter 8
Figure 8.1 Bounding return and investment tables.
Figure 8.2 RG Bounding table.
Figure 8.3 Tools Bounding tables.
Chapter 9
Figure 9.1 PREA tables.
Figure 9.2 PREA balance equation.
Figure 9.3 Warranty table.
Figure 9.4 Sales table.
Figure 9.5 Features table.
Figure 9.6 Time to market table.
Figure 9.7 Wear‐out percentage.
Figure 9.8 Piezo tables.
Figure 9.9 Piezo balance equation.
Chapter 11
Figure 11.1 Uptime stack.
Figure 11.2 DFMEA table.
Figure 11.3 Allocation model structure.
Figure 11.4 Allocation model.
Figure 11.5 Test type by improve and measure ratio.
Figure 11.6 HALT testing stepped stress.
Figure 11.7 Stress margins.
Figure 11.8 Wear‐out distribution.
Figure 11.9 Tashiro chart.
Figure 11.10 Reliability growth plot.
Guide
Cover
Table of Contents
Begin Reading
Pages
ii
iii
iv
xi
xii
xiii
xv
xvi
xvii
xviii
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
17
18
19
20
21
22
23
24
25
26
27
28
29
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
171
172
173
174
175
Wiley Series in Quality & Reliability Engineeringe
Dr. Andre KleynerSeries Editor
The Wiley Series in Quality & Reliability Engineering aims to provide a solid educational foundation for both practitioners and researchers in the Q&R field and to expand the reader’s knowledge base to include the latest developments in this field. The series will provide a lasting and positive contribution to the teaching and practice of engineering. The series coverage will contain, but is not exclusive to,
Statistical methods
Physics of failure
Reliability modeling
Functional safety
Six‐sigma methods
Lead‐free electronics
Warranty analysis/management
Risk and safety analysis
Wiley Series in Quality & Reliability Engineering
Reliability Culture: How Leaders can Create Organizations that Create Reliable Productsby Adam P. BahretMarch 2021
Design for Maintainabilityby Louis J. Gullo, Jack DixonFebruary 2021
Design for Excellence in Electronics ManufacturingCheryl Tulkoff, Greg CaswellJanuary 2021
Lead‐free Soldering Process Development and Reliabilityby Jasbir Bath (Editor)September 2020
Automotive System Safety: Critical Considerations for Engineering and Effective ManagementJoseph D. MillerFebruary 2020
Prognostics and Health Management: A Practical Approach to Improving SystemReliability Using Condition‐Based Databy Douglas Goodman, James P. Hofmeister, Ferenc SzidarovszkyApril 2019
Improving Product Reliability and Software Quality: Strategies, Tools, Processand Implementation, 2nd EditionMark A. Levin, Ted T. Kalal, Jonathan RodinApril 2019
Practical Applications of Bayesian ReliabilityYan Liu, Athula I. AbeyratneApril 2019
Dynamic System Reliability: Modeling and Analysis of Dynamic and Dependent BehaviorsLiudong Xing, Gregory Levitin, Chaonan WangMarch 2019
Reliability Engineering and ServicesTongdan JinMarch 2019
Design for Safetyby Louis J. Gullo, Jack DixonFebruary 2018
Thermodynamic Degradation Science: Physics of Failure, Accelerated Testing,Fatigue and Reliability by Alec Feinberg October 2016
Next Generation HALT and HASS: Robust Design of Electronics and Systemsby Kirk A. Gray, John J. PaschkewitzMay 2016
Reliability and Risk Models: Setting Reliability Requirements, 2nd Editionby Michael TodinovNovember 2015
Applied Reliability Engineering and Risk Analysis: Probabilistic Models and Statistical Inferenceby Ilia B. Frenkel, Alex Karagrigoriou, Anatoly Lisnianski, Andre V. KleynerSeptember 2013
Design for Reliabilityby Dev G. Raheja (Editor), Louis J. Gullo (Editor) July 2012
Effective FMEAs: Achieving Safe, Reliable, and Economical Products and Processes Using Failure Modesand Effects Analysis by Carl CarlsonApril 2012
Failure Analysis: A Practical Guide for Manufacturers of Electronic Components and Systemsby Marius Bazu, Titu BajenescuApril 2011
Reliability Technology: Principles and Practice of Failure Prevention in Electronic Systemsby Norman PascoeApril 2011
Improving Product Reliability: Strategies and Implementationby Mark A. Levin, Ted T. KalalMarch 2003
Test Engineering: A Concise Guide to Cost‐Effective Design, Development and Manufactureby Patrick O’ConnorApril 2001
Integrated Circuit Failure Analysis: A Guide to Preparation Techniquesby Friedrich Beck January 1998
Measurement and Calibration Requirements for Quality Assurance to ISO 9000by Alan S. MorrisOctober 1997
Electronic Component Reliability: Fundamentals, Modelling, Evaluation, and Assuranceby Finn Jensen1995
Reliability Culture
How Leaders Build Organizations that Create Reliable Products
Adam P. Bahret
This edition first published 2021© 2021 John Wiley & Sons Ltd
All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, except as permitted by law. Advice on how to obtain permission to reuse material from this title is available at http://www.wiley.com/go/permissions.
The right of Adam P. Bahret to be identified as the author of this work has been asserted in accordance with law.
Registered OfficesJohn Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, USAJohn Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West Sussex, PO19 8SQ, UK
Editorial OfficeThe Atrium, Southern Gate, Chichester, West Sussex, PO19 8SQ, UK
For details of our global editorial offices, customer services, and more information about Wiley products visit us at www.wiley.com.
Wiley also publishes its books in a variety of electronic formats and by print‐on‐demand. Some content that appears in standard print versions of this book may not be available in other formats.
Limit of Liability/Disclaimer of WarrantyIn view of ongoing research, equipment modifications, changes in governmental regulations, and the constant flow of information relating to the use of experimental reagents, equipment, and devices, the reader is urged to review and evaluate the information provided in the package insert or instructions for each chemical, piece of equipment, reagent, or device for, among other things, any changes in the instructions or indication of usage and for added warnings and precautions. While the publisher and authors have used their best efforts in preparing this work, they make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives, written sales materials or promotional statements for this work. The fact that an organization, website, or product is referred to in this work as a citation and/or potential source of further information does not mean that the publisher and authors endorse the information or services the organization, website, or product may provide or recommendations it may make. This work is sold with the understanding that the publisher is not engaged in rendering professional services. The advice and strategies contained herein may not be suitable for your situation. You should consult with a specialist where appropriate. Further, readers should be aware that websites listed in this work may have changed or disappeared between when this work was written and when it is read. Neither the publisher nor authors shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.
Library of Congress Cataloging‐in‐Publication Data
Names: Bahret, Adam P., 1973– author. Title: Reliability culture : how leaders can create organizations that create reliable products / Adam P. Bahret, Apex Ridge Reliability, Massachusetts, USA. Description: Hoboken, NJ, USA : Wiley, 2021. | Series: Quality and reliability engineering series | Includes bibliographical references and index. Identifiers: LCCN 2020032930 (print) | LCCN 2020032931 (ebook) | ISBN 9781119612438 (cloth) | ISBN 9781119612445 (adobe pdf) | ISBN 9781119612452 (epub) Subjects: LCSH: Quality control. | Reliability (Engineering) | Corporate culture. | Leadership. Classification: LCC TS156 B335 2021 (print) | LCC TS156 (ebook) | DDC 620/.00452–dc23 LC record available at https://lccn.loc.gov/2020032930LC ebook record available at https://lccn.loc.gov/2020032931
Cover Design: Ana FaustinoCover Image: drawn by Adam Bahret
Series Editor’s Foreword by Dr. Andre Kleyner
The Wiley Series in Quality & Reliability Engineering was launched 25 years ago and has since grown into a valuable resource of theoretical and practical knowledge in the field of quality and reliability engineering, continuously evolving and expanding to include the latest developments in these disciplines.
With each year engineering systems are becoming more and more complex with added functions, capabilities, and longer expected service lives; however, the reliability requirements remain the same or even grow more stringent due to the rising expectations on the part of the product end user. With the new generation of transportation systems, such as autonomous vehicles, the expectations have grown even further. It will require the highest degree of reliability to convince people to entrust their lives into the hands of a driverless vehicle. Only with new visions, methods, and approaches to product development will this become a reality.
The book you are about to read is written by an expert in the field of product development and reliability and provides the methodology, guidance, and suggestions on how an organization should evolve to make a transition to the next level of maturity in regards to reliability‐focused culture. It is my pleasure to introduce the author, Adam Bahret, a reliability consultant, who during his professional career wore a number of engineering and management hats, giving him the perfect opportunity to see the “big picture” of how product reliability is handled in various organizations. He has built upon this experience to produce a recipe of how to develop a reliability‐focused corporate culture and emphasizes the important role management and leadership plays in this process. It is important that product reliability becomes the objective of the whole organization and not just an afterthought of a design process. Even though the ultimate goal of any organization is to deliver a fully functional, reliable product to the hands of the consumer, the intermediate goals and objectives may vary between the different parts of the organization, and it is the role of the leadership to align these objectives to achieve this ultimate goal.
However, despite its obvious importance, quality and reliability education is paradoxically lacking in today’s engineering curriculum. Very few engineering schools offer degree programs or even a sufficient variety of courses in quality and reliability methods. The reason for this is hard to explain. Perhaps engineering schools prefer educating their students on how the systems work, but not how they fail? Therefore, the majority of reliability professionals receive their training from colleagues, professional seminars, and technical publications. This book is another step in closing this educational gap and providing additional learning opportunities for a wide range of readers with the emphasis on decision‐makers.
We are confident that this book, as well as this entire series, will continue Wiley’s tradition of excellence in technical publishing and provide a lasting and positive contribution to the teaching and practice of reliability and quality engineering.
Acknowledgements
I would like to thank my wife, Beth, and daughters, Katie and Natalie, for being so supportive during the creation of this book. I know many authors thank their family. I suspect many do it from guilt of having used so much family time to work on the book. But in my case, it was not just that. They really helped me when I was frustrated or needed feedback and a sounding board. It's love if someone listens to reliability engineering content and isn't in the field. So thank you for so much, love.
My sister, Abigail, was a great virtual coffee pot colleague. We live on separate coasts but would meet for coffee online and commiserate about writing. She is a script writer and I'm an engineer pretending to be a writer. She knew all the tips and tricks for getting through the hard times. You're the best, kid sister.
My good friend and writing coach Mark Levy. Mark, you are a great friend and I am absolutely sure no executive in the world will read this book unless you have put your magic into it. The best way to describe our edit is to simply say, “That is the first time this manuscript was in English, and not Engineer.” You really saved this from being a book that couldn't communicate what it wanted to say.
I would like to also thank all of my colleagues and customers. I am extremely grateful to the executive leaders that allowed me to experiment and develop the techniques covered in this book with their teams and organizations. Your willingness to explore made this possible.
Introduction
When it comes to product development, most technology companies understand the importance of reliability. In particular, the engineering teams usually have everything they need to design a reliable product, including the right testing tools and analysis methods.
At times, though, there can be problems: a product doesn't ship on time or, if it ships on time, it fails in the field. Usually, and perhaps surprisingly, these problems aren't caused by engineering. The engineers have done what they're supposed to do, given the circumstances.
The problems come from higher up. They're generated by the organization's hierarchy. That is, the leaders caused the product breakdowns through their leadership decisions. Or, more precisely, they caused problems through bad communication of their decisions, and sometimes simply by making the wrong decisions.
For instance, when it comes to talking to their product team, a leader might give each role on the team a very different goal. They might tell the project manager that their goal is a launch at the end of Q1… and the R&D engineer's goal is a particular new killer feature… and reliability's goal is a reliability of 99.99%.
What happens then? Conflict! The project becomes a scramble.
Instead of the team collaborating on the overall product, they're competing with one another in narrow, limited ways. Each part of the team needs to achieve their particular goal at the expense of the other program goals. (After all, it's personal. Each member thinks, “I've got to win. My job is on the line!”)
The result is a product launch that's ridiculously unbalanced. The product may hit the market on time, but the important new feature fails in the customer's hands.
What's more, the company has lost the opportunity to have a product that, originally, had promise, and the leaders have lost the opportunity to become the owners of a successful product program.
What I've done, then, is to try to right these wrongs.
I've written this book specifically for senior leaders. It's for those of you who want to achieve the goals of a highly reliable product, released on time, with the best new features. It'll show you how to build a culture that can generate impressive, product‐based profits – while that culture is simultaneously centered on reliability. (If that sounds paradoxical or impossible, read on!)
When it comes to creating and releasing products that are innovative, popular, and financially successful, there's an odd belief out there. Leaders think that when it comes to weighing factors – such as cost point, time to market, and product features – there have to be harsh compromises. Fortunately, that's not true.
Often, the reliability advancements that will help you produce a home‐run product are “free.’” In other words, if you more effectively connect the engineering tools being used in the program with your company's business goals, the reliability initiative will pay for itself. No additional costs or length. Hence, “free” in investment and profitable in return.
Before we go further, I'd like to tell you why this work is so important to me.
Consider the following scenario: imagine you're responsible for developing not just any product but one with life‐and‐death consequences. Let's say your product is a surgical device that cannot be allowed to fail. No way, no how. Failure means human death.
Yet what happens? The product development program shortcuts the reliability process, knowingly. On top of that, every announced schedule compression and budget cut strikes the reliability team first.
The consequences of such behavior are obvious, foolhardy, and painful. I mean, the FDA has walked in and shut down the operation before. History it seems is about to repeat itself. But why? Why are we headed into this horrible situation again?
In real life, I've experienced similar scenarios many, many times before, from nearly every side. As a design engineer… a reliability engineer… a reliability manager… and a leader who built entire reliability departments from scratch.
I've also seen it throughout the years as an independent reliability engineering consultant working on numerous projects in parallel in multiple industries.
We so often do things that just don't get good results. But we do them in that same way over and over again. The reason? We don't know why what we're doing isn't working, so we don't know how to do it differently. Change, however, is possible. We can understand why we're messing up, and we can learn to do things not just differently but correctly.
In this book I'll show you the “whys” behind common reliability mistakes, and I'll also show you a better way. Or even many better ways.
I created most of the tools and techniques you'll read about here, but they didn't come from inspiration. As my wife will tell you, I'm not some genius. Instead, I created them simply by having walked more miles in more types of shoes than most. I also keep my eyes open, tend to obsess, and am tenacious. These factors have yielded solutions that pack a formidable punch.
As a reliability consultant, I have the unique position of being a “trusted advisor,” not only to an organization's management but to its executive leadership, too. Many of these leaders have been willing to give me latitude on the methods and strategies that have yielded great results. I'm appreciative for their willingness to go on these adventures with me.
What you'll find in this book are simply the methods I've seen work to ensure the product you develop is the product you planned.
“Reliability culture” is a study on how strong reliability and profitable business connect. More specifically, it will teach you how reliability plays a role in product success in the field.
The culture required to develop the Mars Rover's robotic assembly is very different than the culture needed to develop a toy robot for this year's holiday push.
When the Mars rover program began, the design team determined that each one of the vehicle's DC motors must have a reliability of 99.99999%. Why that extreme? Because if those motors made it to Mars and even one failed, the entire $2.1 billion mission would be a washout.
From a reliability standpoint, what that meant was that every single design decision the team made had to be done with the reliability of those motors in mind. Nothing could compromise those motors – not scheduling, not budget, not extra features.
That toy robot, on the other hand, better make it to the store shelves by third week of November or sales will be cut in half. If the reliability isn't perfect, so what? Most kids will have forgotten about the toy by Easter.
Until now, the reliability engineering discipline has been heavily focused on improving design processes. The problem is that design processes are only half the story.
The methods in this book come from having the ability to take a step back and connect the pieces. In reading how they work, you'll be able to sit down with your team and discuss the ones that will create the product you intended, are in line with your brand, and gain the company its greatest market share.
This is the beginning of an exploration into a new type of product development process. One that will allow your products to meet their full potential.
Let's look at the book's flow, so you’ll know where we're headed.
Chapter 1, The Product Development Challenge, is an overview of common program difficulties. These include budget and schedule compressions that force leaders to cut necessary program steps. Such omissions leave management to make decisions blindly. The major factors that typically drive program decisions are outlined in detail. These product factors and how they interact with the program are critical for a successful project execution.
Chapter 2, Balancing Business Goals and Reliability, is about a major conflict: the fight between long‐term and short‐term business gains. The relationship between the modern business model and the reliability toolset is complex. Modern business methods want returns that happen fast, while reliability methods go for strong performance over the long term. See the conflict? These two don't match in strategy or execution. What can we do? Is there a way to bring the short‐term and long‐term thinking together, and make the result work for everyone? There is. You do it by cutting out some gut decisions and replacing them with decisions made quantitatively.
Chapter 3, Directed Product Development Culture, is about what drives organizational behavior. By exploring culture both inside and outside of an industry, we can dissect how it works and how it can be changed effectively. Just as important as change, is ensuring that the change takes root, so it can't be displaced by the “normalizing” forces of the daily operation.
Chapter 4, Awakening: The Stages to Mature Product Development, is about identifying where ownership and accountability lay for specific functions. The chapter discusses language and how teams communicate. By identifying the intent of language and opening the paths to direct communication tremendous jumps in effectiveness can occur immediately.
Chapter 5, Goals and Intentions, identifies the real reasons we do what we do. Without knowing why we are doing the program activities we are, we can't clearly connect value. Many activities have clear justification for the significant investment they require when we start a program, but the reasons get a big foggy as we progress through a program. Little can be achieved without goals. Even with defined goals, they can still fail to direct us if they are not well documented and in an accessible format.
Chapter 6, New Roles, outlines three necessary roles for a product development program. These roles, “reliability czar,” “facilitators,” and “change agents” are necessary if the correct accountabilities and paths of information flow are going to exist. These roles are not necessarily new hires for a department but an additional “hat” existing team members can wear at given times.
Chapter 7, Program Assessment, is about methods for evaluating your product development program's performance. By defining and measuring key success factors, we create a closed feedback loop to manage our program actions.
Chapter 8, Reliability Culture Tools, introduces the fundamental tools that ensure your product reliability culture is connected to the business's goals. Methods like “Bounding” and “Focus Rotation” are described in terms that allow the reader to implement them immediately.
Chapter 9, Guiding the Program in Motion, provides an overview of tools that can assist with keeping a well‐directed program on track. “Guidance Bounding,” “return on investment (ROI),” and “Program Risk Effects Analysis” enable the “closed Loop feedback” process necessary to apply regular and small course corrections so a smooth program gaining maximum return on investment occurs.
Chapter 10, Risk Analysis Guided Project Management, provides an overview of risk analysis tools and handling failure data. The different flavors of Failure Mode Effects Analysis (FMEAs) are reviewed with an emphasis on how they integrate into programs. Controlling failure data and root cause methods is fundamental to ensuring all the “free” knowledge floating around both in‐house and the field are used to the greatest extent.
Chapter 11, The Reliability Program, discusses the strategies and implementation tactics you'll be using with your reliability tools. It'll guide you through the product and business factors that shape the reliability initiative. The major elements of a complete program plan are covered.
Chapter 12, Sustained Culture, is all about how to make your new reliability changes permanent. Change is good. Lasting change is how we win.
1The 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 innate passion and decided to invest in reliability. Through careful analysis, she learned that her product had a reliability issue that could be resolved in four weeks. Of course, that would push back the product's release date by a month and cost $150 000 but she knew the fix would later save the organization $2 million.
From Engineer #2's perspective, when all was said and done her proposed fix would save $1.85 million, and she should have been rewarded for her thoughtful solution. But you already know where I'm going with this, and so did the leadership team reviewing her suggestion.
The problem with big companies, especially those with impersonal management teams sitting far away from engineering, is that the boss's directive of on budget and on schedule seems frighteningly rigid by the time it reaches the worker bees. The human resources department already has performance appraisal processes drawn up, based on budget and schedule. And because the directive came from so high up, there's not much scope for change at the lower levels.
So Engineer #1, who played ball with the leadership when the program was originally scoped, wins the bonus and a good performance appraisal. And they set an example for the rest of the workforce. They've become a symbol of good behavior.
What also happened, however, is that leadership told Engineer #2 (and everyone else watching) that this reliability stuff is unnecessary, even if it saves the company $1.85 million.
Engineer #2 will now disappear. If she's really good and prioritizes her professional happiness, she will simply leave and go to another company. If her value system doesn't align with the leadership's value system, and she has options elsewhere (and all the very best engineers do), she'll just disappear. That, or she'll simply turn into Engineer #1.
Anyway, that's what I put into my report (hey, they had paid me up front). These leaders, I wrote, had created a culture “allergic to reliability.” If I were forced to be an employee at this company, I'd drop product reliability goals as a way of ensuring I received a paycheck.
The leadership had filled the company with people like Engineer #1, and all the opportunities to save $1.85 million were never taken.
Engineer #1 got promoted, but profits decreased and times grew tougher. And the organization is now conditioned to fixate on cost and schedule. It reinforces things that don't work even more. The culture gets worse. The talent leaves. Frustration reigns supreme.
It’s Not That I'm Lazy, It's That I Just Don't Care
When the program initially started, the company's leadership talked about reliability as if it were life or death. They demanded “zero failures!” because “today, online reviews appear in seconds, and the market knows whether a product is good or bad instantly.”
In the product‐specification document, we set specific reliability goals. After hearing the leaders' demands, you'd think any reliability request would be answered with a blank check and permission to jump to the head of the resource allocation line.
Did everyone know they were going to abandon all of these high‐minded reliability ideals? Boy, I hope not. That level of deception would be heartbreaking. I'm just going to assume they were as surprised as me when the reliability focus got derailed. But, really, let's be honest: I'm not that surprised.
Having said that, I still feel hopeful that the idea of reliability can take root within an organization. The reason I feel optimistic is that I believe everyone wants to build a product they can be proud of. No one wants to create a product that fails. If we take action that creates a product that's only moderately reliable, it must be due to pressure or objectives that aren't thought through. When teams have had an opportunity to create products with genuinely high reliability, while still achieving the other product goals, I'm certain you'll find nothing but enthusiasm.
That all workers want to create high‐quality products was first discussed in Douglas McGregor's 1960 book The Human Side of Enterprise [2].
McGregor challenged the universally accepted principle that “workers don't want to work,” which he called “Theory X.” McGregor said that all workers want to do work that is meaningful and high quality. He called this “Theory Y.”
We see symptoms that appear to support the lazy “Theory X” worker. But what commonly occurs are workers being pushed into work that they don't feel is meaningful. They're disconnected from the work's value, so of course there's little incentive to do a good job. This, combined with their not having input in how their role is executed, turns them into cogs in a wheel who only react to short‐term positive or negative incentivization.
I believe reliability suffers from this same phenomena. When development teams are asked to do reliability activities in the product development process, they're disconnected from the actual value delivered. So they don't understand how reliability helps them achieve the results they want to achieve.
Sure, it's not as easy as showing them a diagram where A connects to B. It requires that they participate in the selection of the tool to be used. They have to believe that what they're doing is going to have an impact. If they understand how the tools work and select one they believe will have an impact, then they'll have created “a way forward.” That's very motivating.
The three steps to making this connection between what they want to accomplish and the methods to get there are to educate, assign goals, and transfer control. The Design for Reliability (DfR) requires that the full team understand reliability. Reliability can't be designed in if the designers don't understand the practices to measure and improve reliability in all phases of a product's life.
Previous to more expansive reliability education programs, the only reliability input that occurred in the program was from reliability engineers. This will never work if the objective is to have reliability designed in.
If you have kids then you know this dance. When you ask a five‐year‐old if they have to go to the bathroom, because you see them dancing a bit, they say, “No.” This is even though they are about to lose control of their bladder. Sixty seconds later they will ask you to take them to the bathroom. OK, I get it: now it's your idea. Humans want to do things on their own terms from the moment they are born.
One of many issues with reliability engineers solely driving reliability is that the reliability engineer has to stand over the designer's shoulder and force themselves on the design process. Have you ever willingly accepted the input of someone standing over you? Me neither. The other option (usually what occurs) is to have the designers finish the design and then hand it to reliability to “make it reliable.” There was an era that produced some evidence that this approach worked, and it's still referred to by old crusty reliability engineers today.
When computing electronics was new, in the 1950s and 1960s, there were a set of common best practices to making it reliable. If a reliability engineer took a new electrical design and then put these practices to the design, it would in fact be more reliable. But this is more akin to a copy editor cleaning up grammar and sentence structure for an author. That interaction isn't going to work with the development of new technology today. Not if you are going to be competitive.
