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,...