Computingfailure.com:
War Stories from the Electronic Revolution

Foreword

by Tom DeMarco

I know this sounds weird, but success in our business is inextricably tied up with failure. The days of achieving anything important without risk-taking are over forever. Today you need to positively flirt with failure in order to achieve meaningful success. The projects that are really worth doing lie at the hairy, scary edge of feasibility. Your intimate understanding of the potential failures that may await you is surely your most potent weapon for avoiding them. You need to become an expert on failure.

But focusing on failure is something that goes against the grain. Our cultures guide us to think only of success, to concentrate on winning, not losing. That all sounds good, sounds positive. The Plan For Success mentality sounds great, but it makes risk management almost impossible. And risk management is your most effective tool in a risk-intensive world. To do real risk management, you have to develop a deep understanding of the factors that have undone those who have gone before you, understand how these factors acted and what measures proved insufficient to contain them. If such factors proved fatal to your predecessors, they may prove equally fatal to you.

Maybe you're willing to accept this idea with no more said, but (never a master of understatement) I have chosen to hammer it home anyway with a grisly word-picture: If you find yourself proceeding over a battlefield that is littered with fresh corpses and you don't know what killed them, you are in trouble. You better be thinking furiously, What did they learn at the end that I may still have to learn in the near future?

This is exactlythesituation most software project managers find themselves in. They need to learn quickly about failure. Of course, the classic way to learn about failure is to make all the mistakes yourself and guide different projects to a great selection of awful conclusions. If you had already done that, you would now be a relative expert on the failures that characterize these projects. Your reputation would be in the dumpster, but your understanding of risks would be excellent. However, the cost you would have paid for the experience is too high. The trick is to gain a useful understanding of project failure mechanisms without actually failing yourself.

That's where Bob Glass's long and careful study of project failure mechanisms comes in. Over the past decade, Bob has been a keen observer of our industry and has turned his particular attention to the patterns that characterize failed endeavors. In ComputingFailure.com, he sets out for you a series of failure scenarios anchored in real and recent fact. Read them and profit from them. It is your understanding of these past scenarios that can help you build a future scenario for your project that has a chance of leading to success.

Tom DeMarco
The Atlantic Systems Guild
Camden, Maine