The Silver Bullet
| In 1987, along with most of the rest of the software industry, I read Fred Brooks' famous article No Silver Bullet (1987). (For those of you who don't know “ it must be my age because there was a time when everyone knew who he was “ Fred Brooks is the doyen of software project managers, the author of that most famous of project management tracts, The Mythical Man-Month .) Brooks' point was simple: despite all the advances in hardware and software technology, there seemed to have been no corresponding " development in either technology or management technique " [my italics] that would enable IT people to bring projects in on time, within budget and deliver what was required. Brooks said it and the world agreed, not because it was Brooks, though I'm sure that helped, but more because that seemed to correspond to our experience as well. Brooks saying it merely put the seal of approval on it. So where am I coming from? In calling this book The Silver Bullet, have I discovered the elusive breakthrough ? Failing that, have I taken leave of my senses? Or more serious still, am I starting to believe my own marketing material?? Most important of all, do I actually have The Silver Bullet? Well, the answer is yes and no. No, in the sense that I don't have a development in technology or management technique, some nifty new algorithm, or management technique extracted from the writings of an obscure 12th century philosopher. Sorry to disappoint you on this score. But you see, I think Brooks and all the rest of us have been barking up the wrong tree. We were looking for a development. Because computers and software were new, the thinking went, we needed some new thing to manage them. For some reason, it never occurred to us that old things might work. Perhaps you might allow me to digress here for a moment, because I believe I know how this thinking originated. People of my generation “ people who remember mainframes and punched cards and the term data processing “ will remember what it was like in those early days (I am thinking of the late sixties/early seventies). I remember the Computer Center when I was still at college: the air-conditioned room, the machine with flashing lights, and the busy acolytes who tended it “ sharp-suited IBM systems engineers or the more casually dressed, but no less boffin-like, Computer Center personnel. Sometimes the machine went down or a new operating system release had to be installed, and when we students asked how long it would take, we were told "We don't know. It'll take as long as it takes." We computer science students longed to join the ranks of the boffins. To learn the new technology. To tend the machine. To be able to say to those who didn't understand the new technology: "We don't know. It'll take as long as it takes." And so the myth was born. La Grande Illusion, I call it. La Grande Illusion maintains that IT (and especially software) projects are difficult, if not impossible , to estimate. Largely as a result of this, IT projects enjoy the notorious track record that they do. La Grande Illusion is a fundamental article of faith of the software industry. It's reasoning goes like this: "Software entities are more complex for their size than perhaps any other human construct." (The quote is from our old friend Brooks again (Brooks, 1975)). Therefore, all bets are off where estimating software is concerned . Things that would make sense in other areas don't make sense in software. Thus software people will do things like:
And they will do all of these things without batting an eyelid “ all because of the basic article of faith of the software industry which says that software projects are difficult if not impossible to estimate. (Where else would you find such a career: technically challenging, relatively highly paid, and where, ultimately, we can shrug and say, "Hey, how could we have known, things take as long as they take"?) A whole industry has risen up about this article of faith. In Europe, even as we speak, there are research programs exploring the outer reaches of the problem. I have numerous books “ one is nearly 800 pages long, an immense work of scholarship “ that propose ways of dealing with it. Around the world, millions, if not billions of research dollars are being spent in the search for the development Brooks spoke about “ a way to accurately estimate software projects. And all of this, I believe, is barking up the wrong tree. Because the answer was there waiting for us all the time. Attempts “ successful to some extent “ have been made to compare the building of software to the construction industry. I think, however, a much better comparison is to compare the creation of software to the making of a film. Both take a written vision “a script in the case of a film, a specification in the case of software “ and convert it into images on a medium ( frames on celluloid or bits on disk or tape). Now the film industry contains noteworthy examples “ Revolution , Heaven's Gate , Waterworld , to name but a few “ of films that have gone ballistically over budget and schedule. But these days, films are shot in a businesslike and highly predictable way to meet specified budget, schedule and quality targets. And what is the key to this? The key is the pre-production phase. In the book, My Indecision is Final , Jake Eberts (Eberts and Ilott, 1990) describes Sir Richard Attenborough's pre-production phase for the film, Gandhi :
If you replaced the 125 people with the size of your particular software team, and replaced the phrase "film will be shooting" with "software will be under development," then, essentially , you have the Silver Bullet. And this Silver Bullet didn't come from any development “ it came from well-tried techniques that have evolved over the hundred or so years of the film industry, which in turn have come from projects in other disciplines and areas of technology. This then is the Silver Bullet. The premise of this book is simple. If you do the things I've described in this book on your projects, then your projects will always be successful. No ifs, ands, buts, maybes, provideds, or anything else. This book is about a method called Structured Project Management. Structured project management is the result of over 25 years of research into why some projects succeed and others fall. While structured project management isn't tied to any particular kind of project, this book focuses a lot on IT and software projects, areas notorious for failures. Software people will find that structured project management bears the same relationship to conventional project management that:
that is, it replaces a process which is highly individualistic, with a process that is standard, repeatable, predictable and consistent. We are often asked if structured project management is a "methodology" “ software people love the notion of a methodology “ and the answer is yes and no. In their wonderful book, People Ware, Tom De Marco and Timothy Lister (1987) define two versions of the word methodology: "methodology" and "Methodology." Methodology with a big "M" is defined as "a general systems theory of how a whole class of thought- intensive work ought to be conducted . It comes in the form of a fat ('a linear foot or more of shelf space') book that specifies in detail exactly what steps to take at any time, regardless of who's doing the work, regardless of where or when." If your question is whether structured project management is such a methodology, the answer is definitely not. Methodology with a small "m" is a different fish. Methodology with a small "m" is defined as a "basic approach one takes to getting a job done. It doesn't reside in a fat book, but rather in the heads of the people carrying out the work." Structured project management is a methodology with a small "m." Though we will deal primarily with software projects in this book, structured project management states that any human endeavor or venture can be treated as a project, and the book could then be used by anybody responsible for leading such endeavors or ventures . Three types of readers are envisaged:
The book is divided into five parts. Parts 1 and 2 present the Ten Steps of structured project management. Parts 1 and 2 show you how to run any project successfully. Most of us don't have the luxury of being able to concentrate all of our efforts on a single project. Most of us are involved in many projects simultaneously , and so Part 3 shows how to run multiple concurrent projects. You will see as the book unfolds that most project disasters can be predicted long before they happen. The Ten Steps prove that you pretty much make or break a project during the planning phase. To enable you to assess project plans quickly and effectively, we have come up with an approach, based on the Ten Steps, which enables you to do this. This is described in Part 4. Part 5, called The rest of the wherewithal, presents a series of chapters on subjects of which the project manager needs to be aware. Many of the subjects are those covered in other management books or on training programs. There are chapters on:
Finally, there are a number of appendices which are referred to in the text. With many organizations now moving away from traditional management structures (hierarchical, matrix, etc.) to project-based approaches, it is hoped that this book will become seminal in advancing research in this critical area. The emphasis throughout the book is on:
|
EAN: 2147483647
Pages: 176