| 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!
| 
