OBSESSING ABOUT "BEST PRACTICES" AND
"DOING IT RIGHT THE FIRST TIME"CAN HURT YOU

An Interview with Don Reinertsen

When it comes to conventional wisdom about how to improve product development processes, Donald Reinertsen has some surprising views. In fact, they challenge a too-easy acceptance of some of the key ideas promoted in this newsletter. It may be worth paying attention to him because Don has spent close to twenty years working with leading development organizations in the world and has done some of the best original thinking in this field. His 1983 work at McKinsey & Company, quantifying the value of development cycle time, helped pioneer the cycle-time reduction movement. He is the co-author (with Preston Smith) of the best-selling Developing Products in Half the Time (see BPR, 10/97). His just-released, Managing the Design Factory: A Product Developer’s Toolkit, explores ways to bring the discipline and rigor of World Class Manufacturing to product development. In a manner reminiscent of Deming, he has iconoclastic things to say about some of today’s favorite product development hobby horses:

BPR: In last month’s BPR, we interviewed Preston Smith about the new edition of Developing Products in Half the Time. From the sounds of it, you guys have produced a very up-to-date toolbox. What’s different about Managing the Design Factory?

DR: "Developing Products in Half the Time focuses on a vital problem: development speed. Its new edition is designed to keep it the best book on this subject. At the intellectual heart of that book is the notion that you must ground decisions about speed in the underlying economics of the development project. Managing the Design Factory extends this systematic, economics-based method to other development objectives besides speed. It takes each of the four fundamental economic objectives, (performance, unit cost, development expense, and development speed) and shows how you can anchor every management decision on the underlying economics of a product development program."

BPR: Why this book at this time?

DR: "In my experience, companies can get to a certain level of proficiency in product development by simply imitating practices of other companies that get good outcomes. It is a bit like trying to build a fast car by selecting the tires from one fast car, the engine from another. It’s not a bad approach to get a working system. However, ultimately you discover that individually-optimum components cannot be assembled into an optimum system. Then you return to fundamentals and engineer the system as a system.

"This is the key lesson of system design, one we’ve learned in both product design and manufacturing system design. For some curious reason it has not been transferred to development process design. Instead, we still incorrectly assume that we can create an optimum development process by assembling together a bunch of individual ‘best practices’.

"The new book tries to take a more deliberate approach to development process design. It views it as a system design problem and tries to highlight why we might make different choices in different situations. It is designed for people who are starting to discover the limitations of conventional approaches. It’s reassuring that the people reacting most strongly to the book in the early reviews are from companies like Hewlett-Packard, Motorola, and Sun Microsystems—those already at the leading edge of product development."

BPR: Why did you call it Managing the Design Factory?

DR: "An important idea developed in the book is that we are managing our development processes the way that we used to manage our factories 50 years ago. Just-in-Time (JIT) manufacturing reflects a true systems approach to the design of manufacturing processes. Unfortunately, little of the deeper learning of JIT has been transferred into our development process design. For example, most development processes have excessively large batch size, overspecialized sub-processes, massive inventory, and slow learning cycles. Since the factory is a key area in which we have transformed our thinking, I consider it an excellent role model for what we have the potential to do in product development.

"Nonetheless, there are some subtleties in transferring these World Class Manufacturing techniques into the product development arena. Product development is truly different than manufacturing in certain critical ways. For example, manufacturing is a repetitive process with relatively low variability. Product development is a non-repetitive process with high variability. This means we cannot bring rational management to product development by using the deterministic math that works so well in manufacturing. Instead, we must use the math of stochastic processes, such as queuing theory and information theory.

"What is important about this is that when you use the right math you reach strikingly different conclusions about how to manage the process. For example, deterministic math says your development process can be loaded to 100 percent utilization before you will experience delays. In contrast, queueing theory says you will experience massive delays in your projects if you try to load your organization close to 100 percent utilization."

BPR: What are the practical implications of this?

DR: "Queueing theory gives you a much more rigorous way to look at the issue of capacity utilization. For example, you discover that there is no possible way to avoid queues in product development without excess capacity in the process. Even the most brilliant forecasting and planning cannot prevent queues, as long as you insist on utilizing 100 percent of capacity.

"When you understand this, you see that idle time in development is not ‘waste’, but rather a tool that prevents your resources from being blocked 100 percent of the time. This gives you insight as to why a company like 3M builds 15 percent excess capacity into their development process. Do you really think they do it because they like ‘waste’? They say it helps make them more ‘innovative’.

"I would argue that this excess capacity has a dramatic effect on process queues and cycle time, and that finishing early is usually the difference between being the ‘innovator’ and being the ‘imitator’. Now, 3M may not understand queueing theory—they may just be doing what they observed works. But, queueing theory gives you the ability to assess what level of excess capacity is right for your own process—instead of assuming that 3M’s 15 percent is a universal truth."

BPR: You make the radical proposal that there are no best practices. What do you mean?

DR: "I am against the notion of ‘best practices’ because it implies that there is a single best way of doing anything. Embedded in the idea is the tacit assumption that following the ‘best practice’ always results in the ‘best outcome’. Since I have never met a really experienced manager who believed this was true, I am not sure I am really being very radical. I simply believe that all practices are ‘tools’ that are useful to achieve certain objectives in certain contexts.

"For example, consider sequential development versus concurrent development. Neither can truly be called a best practice. A concurrent process is very well-suited to achieve development speed. A sequential process is generally better at minimizing risk and controlling development expenses. Each is ‘best’ to achieve a certain objective. The same is true for functional organizations versus teams. A functional organization is an excellent tool to keep development expenses low. Teams are well-suited for rapid development, especially when they are adequately manned. Again, neither is a universal best practice.

"The great danger in labeling something a ‘best practice’ is that you cannot be against it. People stop thinking as soon as something is labeled as a ‘best’. Such mindless behavior is dangerous in a complex world. I am simply arguing for a more thoughtful approach to development process design."

BPR: Waste in the design process: where are the high-leverage opportunities for improvement? Where do I begin to do my homework?

DR: "‘Waste’ is another one of those emotionally charged words that suspend thought. Which of your readers would be in favor of ‘waste’? We all know the mantras. Waste is bad, efficiency is good. Fat is bad, lean is good. A seductive but stupid way to think about product development. The real problem is that most people focus narrowly on expenses when they think about waste.

"Let me give you a simple example. Let us say a medical products company wants to be ‘efficient’ in their product development and ‘eliminate waste’. They notice that their Regulatory Affairs team member prepares a submission package early in the design process, but redoes it when Engineering changes the design. Surely it is wasteful to do the same paperwork four times in the design process, when only one time is necessary for submission. Let us eliminate this ‘waste’ by involving the Regulatory Affairs person later in the design process, when the design will no longer change.

"What are the consequences? Regulatory is now on the critical path of the program, when previously most of their work took place off the critical path, so we pay the cost of time on the critical path. Furthermore, they are identifying design changes late in the development process when it costs 100 times more money to make the changes. The ‘efficiency’ of the regulatory affairs person is costing us many times its savings by its impact on costs and cycle time. The point is that we need to see development as a system and try to optimize overall outcomes. Therefore, the place to start is always by understanding the overall economics."

BPR: You’re big on making an economic case for everything. Isn’t this already the universal practice in business? Where’s the news in what you’re saying?

DR: "It is often far more dangerous to do something incorrectly than to omit it. If you omit it, there’s a chance you may notice the omission and correct it. If you do it incorrectly, but believe you are doing it right, there’s little chance you’ll scrutinize what you do. This is the essence of the problem with how people do economic analysis today. They typically leave out major factors like the cost of delay on the critical path, and they inevitably come to completely incorrect answers. Yet, they believe they already understand their economics.

"The very fact that people are willing to grasp onto ‘best practices’ illustrates how completely they have forgotten how to ask the question, ‘How do I make money by doing this?’ Instead, they are willing to adopt a practice, subjecting it to no economic scrutiny, solely on the basis that it is ‘best practice’. It appears that imitation has become more important than making money.

"If you don’t think this is true go to the typical development team and ask the team members to independently estimate the cost to shareholders of delaying their product introduction by three months. The answers will differ by at least an order of magnitude. This means that they are making vital decisions that affect the schedule and economics of the project while they are clueless about the economic consequences. And, even more seriously, it has not even occurred to their management that this might be a problem."

BPR: Many people seem hell-bent on looking to metrics for salvation. Yet it’s possible to measure your way into extinction. In the context of the well-disciplined design factory, what’s important to keep in mind about metrics?

DR: "Metrics are only a part of the control process, but a crucial one. To select the right metrics back up and ask: ‘Why are we trying to control the development process?’ I maintain that the sole purpose of control, and its companion, measurement, is to influence economic outcomes. We need to choose metrics based on the underlying economics of the process, which means different processes need to measure different things. I know a VP of Engineering who complained to me that his company let him make component decisions that cost millions of dollars a year with no oversight, but required him to get approval of his boss to remove a box of pencils from the storeroom. A great example of focusing control effort on a parameter that has trivial economic impact.

"I argue that there are sets of metrics that are directed at each of the four key economic objectives; we can systematically choose process and project metrics that actually are relevant. The measurement-to-extinction problem only occurs in two cases: when you focus your measurement effort on economically irrelevant parameters, and when you treat measurement as an end in itself instead of as a component of a closed-loop control system. What you do after you measure is as important as what you measure."

BPR: In Chapter 4 you make a statement that is sure to raise some eyebrows. You state that doing things right the first time may be the wrong approach. Why do you say this?

DR: "We already know how to do it right the first time: take no new risks. As long as we always use a proven approach we have no risk of failure. But does this really produce winning designs? Unfortunately, we have to change the design to improve it. This requires risks. ‘Do it right the first time’ implies that driving the probability of failure to zero will optimize economics. But this is not true. We make the most money when we take ‘rational’ risks. When the likely upside is larger than the likely downside. It is rational to bet a penny for a 50% chance of making a dollar—even though the risk of failure is high.

"Now let’s apply this to the design process. We frequently have a chance to try a new approach that has substantial possible benefits. If the benefits are high enough we want people to do this. In fact, if we never try anything new in our designs we will have 100% chance of ultimately having a working design that we can’t make money on. There is another way to view this problem, using information theory, that shows you that if you get your designs to work perfectly the first time, you have eliminated all information generation from your design process. In other words, you have created the perfect non-learning organization."

BPR: Use the right tools, you say. But isn’t this like "best practices" — no one right set of tools?

DR: "I like to use the tool analogy because most people instantly recognize that a screwdriver is a good tool for driving screws but a poor one for hammering nails. There is a right tool to use to accomplish a particular job in a particular setting. It would be silly to talk about the concept of a universal ‘best’ tool without asking the question, ‘To do what?’. Again, the danger in best practices is the notion that there is one best way to do things that would be best in all situations for all companies.

"Of course, to move beyond best practices we need some way to assess a situation to determine which tools are best in that situation. The tool we use to do this is the economic analysis described in Chapter 2 of the book. From this economic analysis you can determine what needs to be optimized about your project or process, which leads you to specific practices that can optimize those things."

BPR: In your book you invite readers to focus on organizational fit. Why?

DR: "Organization design is intimately entangled with process design. The book describes three basic organizational approaches: functional organizations, autonomous teams, and hybrid organizations and identifies when each is most appropriate. One is not always better. In general, functional organizations are good for expense control, autonomous teams for speed, and hybrid organizations for controlling product cost and performance. The real art of organizational design does not lie in how you draw the lines on the organization chart, but in the processes and communications links that you design to fill the ‘white space’. I have seen many beautiful-looking organization charts that didn’t work because management concluded they were organized because they had an organization chart."

BPR: Can you say a bit more about product team autonomy?

DR: "Autonomous teams will result in fast development, particularly when they’re resourced with everything they need to succeed. In reality, this rarely happens. Furthermore, the increase in speed may come at the expense of sub-optimizing other objectives, like performance, unit cost, and expenses. You need to decide which factor has the greatest economic importance before you can select an approach.

I recall the story of a Japanese video camera team that was totally autonomous. It did an amazingly fast development but produced a camera that could only be used by a right-handed person. Although they were fast, they clearly lost out by not being able to access organizational knowledge outside the team.

"For autonomy the devil is in the details. You rarely see situations where autonomy is an undifferentiated team property. Instead, what you see is a microstructure of activities; some delegated to the team, and some are retained outside of the team. Even the most autonomous team will usually not be given authority to choose their own CAD system. This has too many cross-project implications. Even the least autonomous team will be given authority to set task sequences for their project.

"I find it much more useful to talk specifically about which authorities you will or will not give to the team rather than to make broad pronouncements about autonomy and empowerment. There is simply very little information content in the statement that the team is autonomous, because it tells you very little about the detail of how decisions will get made. The book identifies about forty key decision areas in which you must choose whether the team or someone outside the team should have authority."

BPR: You say that many companies don’t manage risk effectively in their development programs. Why?

DR: "Most companies act as if you can take any risk you want as long as you are successful. As I mentioned earlier, the basic defect in the way most people manage risk is that they think our objective is to minimize risk. Risk is viewed as bad. An economist would take a different perspective. Any decision to take a risk is a bet on an uncertain future. The rationality of that bet depends on what the upside is, what the downside is, and the chance of winning.

"We only want people to stop placing stupid bets. The problem today is that most companies have very poor processes to make these decisions. The book suggests structuring these decisions as economic tradeoffs." PD

If you would like to share your ideas with others and get useful advice, visit our bulletin board service, the Roundtable.

For hot news and important information effecting your job, come here often. For more information, subscribe to our newsletter to gain competitive insights you won't find elsewhere.