|
DHQ: More than ten years passed before
you released the second edition of Peopleware,
adding eight chapters and making it larger by one
third. But your new book, Waltzing with Bears,
took much less time. How did you do it?
TRL: Well, it's true that Waltzing
with Bears is coming out relatively soon after
the second edition of Peopleware, but we
knew we wanted to write a book on risk management
about seven years ago. I guess we suffer through
long gestation periods for our books. We need
to read about our topic, lecture about it, talk
to people in our industry about it, and most of
all see it in action in organizations in order
to be ready to write.
TDM: There is something else here, too:
People have a lot of trouble with the concept
of risk. It's abstract, inherently counterintuitive,
and often something that you'd prefer not to think
about. The subject was just a lot harder than
anything we'd had to present before. Ironically,
it's not all that difficult to do risk management,
but it is hard to talk and write about it in a
way that makes sense and doesn't cause people's
eyes to roll up into their heads.
DHQ: The book's title,
Waltzing with Bears, is rather intriguing.
TDM: The title comes from Dr. Seuss (a
source of wisdom for all managers), specifically
from The Cat in the Hat Songbook.
TRL: Tom and I were lecturing on risk
management, and when we lecture, we like to play
some music before each session, to get everyone
back in their seats. Tom had a CD with a recording
of "Waltzing with Bears." I loved it.
In the song, there's an uncle who sneaks out of
the house on Friday nights to go waltzing with
bears—the idea charmed me. The uncle is taking
risks to do something he values, and waltzing
with bears in itself is risky. Software efforts
are full of risks, and we jump into them in order
to deliver something satisfying and valuable.
When we finally got down to the task of naming
our book, we wanted a title with some zip to it.
I remembered "Waltzing with Bears,"
and Tom thought it was a perfect match.
DHQ: One of the key points you make in
Waltzing is that a lack of risk in a project indicates
a lack of any real potential benefit. Why do you
think so many organizations refuse to accept this?
TRL: I think of it the other way; most
organizations refuse to recognize that their projects
are full of risk. They so desperately want to
feel that they are in complete control of their
projects that they never can ask themselves what
can go wrong. Nowadays, all projects that can
deliver value are full of risk, and that is one
of the dominant reasons why we tend to run over-schedule
and over-budget. The projects have not taken into
account the risks that may turn into problems.
TDM: For me, the villain here is Management
By Objectives. MBO makes a big deal about getting
successes on the board, having them recorded and
chalked up against your name. The idea that some
"successes" are worth pennies while
others are worth millions of dollars is way too
tough a nuance for MBO managers. In an MBO company,
a project with a high likelihood of success and
zero benefits looks like a godsend.
DHQ: How can managers begin to cultivate
a culture of risk-taking and risk mitigation in
their organizations?
TDM: By making risk-taking an explicit
part of the organizational goal set.
TRL: By dealing with risk from the start.
By posting the risk list for all to see. By demanding
that there be a contingency fund for the project
that is greater than $0.00. By making it clear
that the risks are inherent and are not the result
of some inadequacy.
DHQ: In Waltzing, you say that
"Risk management is not the same as worrying
about your project." What is it, then?
TDM: The lovely quote that "risk
management is not the same as worrying about your
project" comes from Tim. The first time I
heard him say it, I whooped. There is something
just so right about that, so familiar. Managers
who are deeply worried about their projects just
assume that they therefore ought to get full credit
for doing risk management, even though they haven't
got a clue what it entails.
TRL: Risk management is about the assessment
of problems in their potential state, before they
materialize. It is then the determination whether
to pay money at the risk state to lower that risk's
probability and/or impact, or whether to wait
and deal with it if it becomes an actual problem.
Risk management is about leveraging problems by
deciding whether to deal with them before they
occur.
DHQ: You use the example of online trading
to illustrate the benefits of risk-taking. What
other new technologies or services would companies
be remiss to pass up merely because of the risks
involved?
TRL: You can't answer this in the abstract
because how much risk you should be willing to
take has to do with how much reward (value) you'll
gain if you succeed. So, one company might get
huge benefit out of looking at a newer technology
like instant messaging, while another may be smart
to let that technology stabilize before committing
to it.
TDM: Tim's answer here is technically
correct, but we can point to a few areas of technical
advance that most companies should be exploring
aggressively right now. As Tim says, the advantage
they're likely to be able to realize from them
will vary from case to case. But here are a few
new fields that you'd be crazy to run away from:
Web services, telepresence, multiprocessing (networks
of linked plain-vanilla computers focused on a
single task, such as the architecture implemented
by Google to implement its search engine), and
e-commerce. These are the technologies that will
remake the next decade. E-commerce got a bad name
at the end of the bubble, but those companies
that got an early jump on it are today in the
cat-bird seat.
DHQ: As you point out in Waltzing,
a team that presents a product early could find
itself accused of gaming the schedule. Why is this?
TRL: Here's our hypothesis. We have never
gotten very good at estimating because our patrons
have never really valued it. We have had projects
that "had to be done, no matter what, by
such-and-such date." When we have been in
these situations, the deadline was a goal, not
an estimate. The only way to break out of this
is to break out the project goals from the project
estimates. Both are useful; they are never the
same.
TDM: I'm a bit more optimistic than Tim.
I think we have finally gotten good at estimating.
The software industry has. However, the basic
skills of good estimating are not uniform across
the field. The companies that have done their
homework (metrics, estimating teams, informed
management) are miles ahead of the rest.
DHQ: Thank you!
|
