Our Blog Excerpts Savings Contact


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


iDH Sign-Up

Get Our e-News
Delivered by FeedBurner

Running Toward Risk

by Tom DeMarco and Timothy Lister

Adapted from Waltzing with Bears: Managing Risk on Software Projects. Reprinted by permission. All rights reserved. See below for copyright notice.

Running away from risk is a no-win proposition. Sometimes, you come across a project that looks positively risk-free. In the past, you may have looked at such an endeavor as a slam dunk and thanked your lucky stars to be given an easy project for a change. We've had the same reaction. What dummies we were. Projects with no real risks are losers. They are almost always devoid of benefit; that's why they weren't done years ago. Save yourself some time and energy and apply it to something worthwhile:

If a project has no risks . . . don't do it.

Risks and benefits always go hand in hand. The reason that a project is full of risk is that it leads you into uncharted waters. It stretches your capability, which means that if you pull it off successfully, it's going to drive your competition batty. The ultimate coup is to stretch your own capability to a point beyond the competition's ability to respond. This is what gives you competitive advantage and helps you build a distinct brand in the market.

Flight from Opportunity

Companies that run away from risk and focus on what they know they can do well are ceding the field to their adversaries. The 1990's gave us some charming examples of this. There were, broadly speaking, two major things going on in the nineties:

  • Companies were moving applications and databases from the old mainframe-and-terminal mode to client/server mode.

  • Companies were transforming themselves to interact directly with their customers and suppliers in new and previously unimagined ways: via the Internet and through integrated supply chains, auction mechanisms, and disintermediated transactions.

Unfortunately, there were lots of companies that dedicated themselves substantially to the first of these and ignored the second. Once you've done one client/server conversion, the rest are easy and mechanical. You could do them in your sleep. In fact, if you spent most of the nineties doing client/server conversions, you were asleep. You missed the action.

A case in point is Merrill Lynch. They looked long and hard at the so-called trend of on-line trading . . . and decided to ignore it. They crossed their fingers in the hope that the era of the full-service brokerage (with fat fees and brokers who could keep you endlessly on hold) would come back, that direct trading would be only a passing fad. What a forlorn hope. Today, the full-service brokerage is as much a thing of the past as the full-service gas station. And today, Merrill Lynch offers its customers on-line trading at a reduced fee. But it took them nearly a decade to catch on. They were the latest of the Late Adopters.

The Early Adopters were Fidelity, Schwab, and E-Trade. E-Trade and its look-alikes were new companies, created to exploit the change. So, if on-line trading had turned out to be only a passing fad, E-Trade would have gone belly-up with no loss beyond the capital the company had raised explicitly to put at risk. Fidelity and Schwab, on the other hand, were well-established companies with a lot to lose. In this sense, they were not so different from Merrill Lynch. But Fidelity and Schwab were willing to take the risks.

The IT people at Fidelity and Schwab had to be aware of the risks of the new venture. Here is our two-minute brainstorm list of the risks that would have been easily apparent to Fidelity and Schwab when they began to take on Web trading in the early nineties:

  • Building the system is completely beyond our capability; we'll have to learn protocols, languages, and approaches like HTML, Java, PERL, CGI, server-side logic, verification, secure web pages, and many new technologies that we can't even name today.

  • Supporting the system is completely beyond our present capability; we'll have to set up user help desks, audit trails, monitoring software, tutorials for use of the system—things that we've never done before.

  • The security risks of on-line trading are truly daunting; we will be attacked by hackers and crackers, by organized crime, and by our own customers and employees.

  • We may not be able to acquire the experience and talent we need to do any of this.

  • We may find that the business we do via the Web is just what we would have done with the same customers at higher fees if we hadn't built the Web trading system.

  • We may find that people try on-line trading and then go back to telephone trading, leaving us with a busted investment.

  • We may ease our existing customers into this new mode and then lose them to competitors that cater to these newly savvy traders.

Undoubtedly, Merrill Lynch was aware of the same risks. But Fidelity and Schwab decided to run directly toward those risks, while Merrill Lynch chose to run away from them. The result was that Fidelity and Schwab grew aggressively in the nineties while Merrill Lynch struggled to stay even.

What's Different About Today?

We are in the midst of a sea change that will probably cause turmoil for the rest of our lives. The world is suddenly much more tightly connected. There is an ever broader-band web of digital connection that touches all of us: Individuals are more connected to each other, to their companies, and to the service providers that they depend upon; companies are more connected to their clients and employees, to their markets, to their vendors, and to the government agencies that affect their work. And all of this is still evolving.

In this period of turmoil, a willingness to run risks is utterly essential. It matters a hell of a lot more than efficiency. Efficiency will make you, at best, an attractive takeover candidate—probably for a less-efficient competitor that has stolen a march on you through greater risk-taking.

AddThis Social Bookmark Button




COPYRIGHT NOTICE: This excerpt from Waltzing with Bears: Managing Risk on Software Projects [ISBN:0-932633-60-9] appears by permission of Dorset House Publishing. Copyright © 2003 by Tom DeMarco and Timothy Lister. All rights reserved. See http://www.dorsethouse.com/books/waltz.html. The material contained in this file may be shared for noncommercial purposes only, nonexclusively, provided that this Copyright Notice always appears with it. This material may not be combined with advertisements, online or in print, without explicit permission from Dorset House Publishing. For copies of the printed book or for permissions, contact Dorset House Publishing, 1-800-342-6657, 212-620-4053, 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