An Interview with Don Reinertsen (2/2)
Obsessing About Best Practices and Doing it Right the
First Time Can Hurt You - Part 2PDBPR: 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."
PDBPR: 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."
PDBPR: 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."
PDBPR: 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."
PDBPR: 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."
PDBPR: 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."
PDBPR: 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."
This article originally appeared
in the December 1997 issue of PDBPR
 To join our
e-mail list and receive future updates on "Fast & Flexible" techniques, click here.
|
