Foreword

I have had the pleasure of knowing Ralph Young for many years now. He and his co-authors, Steve Brady and Dennis Nagle, are especially well qualified to write about one of the key practical issues in systems and software development: how to manage a successful project.

Fundamentally, systems engineering is simple: you find out what the client wants; you work out how to meet that need; and you implement the resulting specifications. The project management component is equally straightforward: you plan according to the client’s need, and you monitor and control the implementation of the plan. The authors of this admirably clear and practical book present well-established techniques for managing a successful project. These techniques do not amount to rocket science, though they are as suitable for developing satellite launchers as for any other complex hardware or software.

The authors note in the Introduction the prevalence of project failures repeated year after year. Critical project management tools and techniques are not sinking in, despite the wide array of available resources. People go on believing that they can buck the trend—that the rules do not apply to them. There is something joyously human in the self-confidence and optimism of engineers and project managers alike: this time we can make it! Can we fix it? Yes we can! Energy and enthusiasm are admirable and necessary to successful projects—but factors such as poorly defined requirements, creeping scope, conflicting and unmanaged expectations, and a lack of control can bring disaster to any project. The authors wisely emphasize these key points right up front in this book.

Success depends on teamwork: on a common purpose, on agreed-upon goals, and on people in different roles working effectively together. Many engineering textbooks barely mention project management; many project management books barely consider engineering. Young and his team are as comfortable quoting software and systems engineers as they are project management gurus. They draw pragmatically on six sigma, requirements engineering, software estimation, systems engineering, peer review, software inspection, earned value, and many other concepts and techniques.

How to Save a Failing Project takes an honest look at some of the uncomfortable topics in project management we all know but prefer not to speak about, such as the signs—both overt and subtle—that a project is out of control.

The book also shows how to save troubled projects by applying leadership, planning, communication, and effective processes, and by building and maintaining a good team of people, using metrics, learning from mistakes, and taking action to implement those lessons. These components are well documented and are easily learned. Applying metrics, for example, can help project managers predict with mathematical precision how many defects will occur during a project, allowing them to plan for those defects.

If you’re reading this book in a time of project crisis, be reassured that this book offers a wealth of project experience and calm, practical, step-by-step guidance. The authors have seen many projects in crisis, and they have turned many of them around. I hope very much that you will come to appreciate their wisdom and value the crucial importance of good requirements—and requirements analysts—in establishing and planning projects properly.

If you’re reading this book in between projects, Part III offers guidance on how to improve your chances for project success the next time around. Again, the techniques offered are not quantum mechanics, but simple things like defining many small milestones can make both project progress and deviations from the plan easy to identify.

We need to be reminded how central and critical the basics of requirements work—discovering stakeholders’ goals and expectations, identifying and agreeing on scope, evolving the real requirements, and prioritizing, tracing, and managing changes to requirements—are to project success. These are not minor technical matters to leave to junior engineers in a quiet backwater of your project. These things determine the project’s success or failure more directly than anything else.

Ian Alexander
February 2009
www.scenarioplus.org.uk