PREFACE TO THE FIRST EDITION

In 1979 I bought Tom De Marco's book (1978) Structured Analysis and System Specification . At the time, I had been working for about three years as a programmer, but had ambitions to be a systems analyst. Those in the know, while applauding my ambition , made it clear that not everyone was cut out to be a systems analyst. It was highly likely that I might not have the "right stuff" “ that particular combination of personality, intellect and way of looking at things that characterized the systems analyst. In short, the thinking went, systems analysis was very much an art, and in the same way that not everybody was born to be a great pianist, not everybody could be a systems analyst.

After reading De Marco's book, it would not be an exaggeration to say that the scales had fallen from my eyes. Or to put it more bluntly, I was gobsmacked! The great mystery of systems analysis was laid bare. It wasn't an art “ not much anyway “ it was a method, an approach, a technique. While it would be a wild oversimplification to say that anyone could do it, it certainly wasn't sorcery or genius. The book presented a method and if you carried out the method you were doing systems analysis. Systems analysis has long since ceased to have any mystique about it, so now we software practitioners have had to find another black art, another mystery with which to clothe ourselves . That black art is project management, and you only have to look at the success statistics for projects to see why the world at large might perceive it to be so. The premise of this book is that project management is no more a black art than systems analysis is. Project management too can be described by a method, and that is what this book is primarily about. De Marco's book had a seven-step method; this one has a ten-step method. The method is derived from studying other projects, why some succeed and others fail.

The argument is simple: if you do enough of the things on your project that have made other projects successful, the chances are yours will be too; and, conversely, if you engage in practices which have been used on failed projects, then God help you.

Parts 1 and 2 of the book contain the Ten Steps Method, and are intended to be read sequentially. Other than that, you can dip in as you please . While the book uses the software industry to illustrate many of its ideas, the Ten Steps Method isn't unique to software. It can be applied to any venture, in any discipline; and is equally applicable to business or personal projects. Indeed, one person who attended one of my company's courses said that it changed his life. While it may not do that for you, I can pretty much guarantee you will learn new things from it.

Project management is concerned with bringing about change, about making things happen. In a world where we are in need of much change “ and this is true of my own small country as much as anywhere “ it is the project managers who will make the visions come true. Bad project management results in a colossal waste of the world's resources. There is enough of that going on, and we should be trying not to add to it.

But more than anything else, project management is fun. Software people tend to think that all the fun has gone out of their lives when they are promoted from "doing technical work" to "managing people." Nothing could be further from the truth. For infinite variety, constant challenge, unpredictability , adrenalin-burn and ultimate sense of achievement, project management is hard to beat; and if this book succeeds in transferring some of that enthusiasm to you it will have been worth the struggle it took to write it.

Many people “ customers, students, colleagues, peers, bosses, both current and former “ contributed , consciously and sometimes unwittingly, to this book. Rather than changing the names to protect the innocent I have chosen to omit all names. However, two groups of people deserve particular mention. One is those who read and commented on drafts of the book. The other is those who attended courses on the content while the material was still in its formative years and growing from the "EOTP Methodology" through "ETP" to its current simple name of Structured Project Management. There are some people and organizations that I would like to name : Telecom Ireland Software (TIS) gave me permission to use some of the examples in the text, for which I am very grateful. In addition, Tom Moylan and Eugene Smyth, both of TIS, gave me the opportunity to apply and thereby refine many of the ideas in the book.

Beaumont Hospital were kind enough to allow me to use an example, which one of their staff, Cathy Keany, put together.

Whether they know it or not, Ray Welland of the University of Glasgow and Pat O'Reilly of Siemens Nixdorf both encouraged me at points where I had begun to despair about the material ever seeing the light of day. Often it is small incidents that change lives, and conversations which these people may have forgotten, were crucial in the evolution of the material as well as steadying my will to continue.

As she knows , Viki Williams of Prentice Hall will have a permanent place in my heart for having given me my first break. Viki still owes me & pound ;2 from the time we first met, but it's OK Viki “ buy me a pint next time you're in Ireland!

Myles Dunne put the finished product together, ironing the crumpled pages, drying the soggier ones, etc. and takes credit for its final appearance.

Bernadette McHugh put up with (relative) poverty and all that it entails, while this was being written. Thanks Bernie for staying with it “ and me! Fortitudinam vincimus .

Hugh O'Connell and some (furry) friends of his were right there with me when I wrote much of the book, as is evidenced from old drafts that have muddy paw-prints or coloured scribblings on them. Thanks guys “ you may not have made it easier, but it was more fun!

Ireland, January 1993