Our Blog Excerpts Savings Contact


Dorset House Publishing
High-Quality Books on Software Engineering and Management.  Since 1984.
dorsethouse.com > features


iDH Sign-Up

Get Our e-News
Delivered by FeedBurner

The Dorset House Quarterly Interviews

Tom DeMarco and Timothy Lister
Authors of Waltzing with Bears: Managing Risk on Software Projects

ISBN: 978-0-932633-60-6  
©2003  208 pages   softcover  
$27.95 (plus shipping)

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!

AddThis Social Bookmark Button





COPYRIGHT NOTICE: The material contained in this file may be copied or distributed freely, provided that the material is copied or distributed in its entirety, including this Copyright Notice. This material is Copyright © 2002 by Dorset House Publishing Co., Inc. No use may be made of the material without acknowledgment of its source: Dorset House Publishing Co., http://www.dorsethouse.com, info@dorsethouse.com, New: 3143 Broadway, Suite 2B, New York, NY 10027 USA. Additional rights limitations apply, as presented in the Legal Disclaimer posted at http://www.dorsethouse.com/legal.html.






New:3143 Broadway, Suite 2B  New York, New York 10027  USA
1-800-DH-BOOKS or 212-620-4053, fax 212-727-1044

Copyright © 1996-2008 by Dorset House Publishing Co., Inc. All rights reserved.
Home | Blog | Savings | Stores | Features | Titles | Authors | Subjects | Orders | About | Contact | Legal