Failure often teaches more than success. This book shows what went wrong in 16 of the worst software disasters of recent years -- and shows how to prevent your own software disasters.Software failure expert Robert Glass reviews the major software disasters of the past decade, including both widely-publicized and less well-known fiascoes. He identifies six characteristics of impending failure, including elements rarely discussed in other software engineering texts, such as the overdependence on new technology and the failure to adequately consider performance issues. Among the failures Glass discusses are: the FAA's Air Traffic Control System; American Airlines' Confirm; and Bank of America's MasterNet. Most important, Glass presents specific lessons to be learned from each of these failures, so your software project won't show up on the nightly news.All software project managers, IS senior management, developers, and other software professionals.

Preface I've always been interested in computing projects that failed. There seems to be a much more indelible lesson to be learned from failures than from successes. Some of you readers may know that I once wrote a column for a leading computing newspaper under an assumed name, and the content of the column was fictionalized failure stories. (I wrote it under an assumed name and fictionalized the stories, because I suspected that my employer at the time wouldn't appreciate my washing its dirty linen in public!) Those columns eventually became a book (The Universal Elixir and Other Computing Projects That Failed) and then grew to fill another (The Second Coming: More Computing Projects That Failed). They also became the basis for talks I frequently presented at chapters of my computing professional society, the ACM. Buoyed by that success, I did it again (Computing Catastrophes, true stories of mainframe computing projects and companies that failed) and again (Computing Shakeout, true stories of microcomputer projects and companies that failed). I was on a roll. Failure was my fate! But the last of those books was (self-) published in 1987, over a decade ago. It wasn't that I lost interest in failure; it was simply getting harder to find good failure stories! The frequency of early-day failures, and the shakeouts in the mainframe and microcomputer industries, had largely ended. Computing had become an almost boringly-successful field. Some would, of course, take issue with that statement. Those who cry "software crisis" promote the belief that the software field is full of failure, with far too few successes in between. But that's not how I see it. In spite of the time I've spent finding and publishing failure stories, I believe that software is the dramatic success story of our age, the spark that ignites the Computing Era. There have been failures, of course; but what makes them interesting is partly that there aren't that many of them. It's what journalists and software people call "exception reporting"we tend to focus on the things that go wrong, because they're more interesting or important than the run-of-the-mill things that go right. Well, I'm at it again! I've been gathering stories about software runaways for about 10 years now, and I have enough of them to put together yet another book. This book contains stories about the Denver Airport Baggage Handling System, the FAA Air Traffic Control System, the Internal Revenue Service Modernization effort, and a baker's dozen or so other examples of software projects that got way out of control, most of them crashing and burning (usually figuratively rather than literally!). Once a failure nut, always a failure nut! One of the things I do as I accumulate stories for a book is to analyze the lessons they teach us. It's a good way to create an outline for the book, for one thing, and it's also a way to make sure that there's value added for the reader; these are not only fun stories to read, but the lessons make the reading a learning experience. What I'd like to do in this preface is highlight for you some of the learning experiences from the material that follows. I think there are some particularly interesting things happening in our field, as reflected in these failures, and they don't always agree with what our textbooks and our research papers, and our newspapers and our televisions, are telling us. First, let's get the predictable out of the way. Here are some things I discovered that match what our traditional sources of information tell us: Most of the runaway projects are (or were) huge. It is well known in the field that huge projects are much more troublesome than smaller ones. These stories support that finding. Most runaway projects result from a multiplicity of causes. There may or may not be one dominant cause, but there are always several problems