Book Review: How to Save a Failing Project:
Chaos to Control

Ralph R. Young, Steven M. Brady, Dennis C. Nagle
Management Concepts, 2009

ISBN 1567262391 (paper)

Buy it from Amazon.com (commission paid)
Buy it from Amazon.co.uk (commission paid)

Other Reviews

Other Books by Ralph Young

From the rear cover: "[This book] provides the knowledge, insight, and tools you need to recognize a project in trouble, determine what to do about it, and transform it into a success. You'll also discover methods, techniques, and tools to keep a project from getting into trouble in the first place."

I have had a hand in this book, having reviewed it during production and written the Foreword, so I will keep my description plain and factual, other than to say that the book is well thought out, plain and direct, and that it should be just the right thing for you if your project is getting into difficulties.

This is a compact book of some 200 pages. It is well organized with a brief introduction to critical project processes, and a good glossary, bibliography and index.

Part I covers Project Awareness: How to Recognize a Failing Project.

Part II naturally covers Project Planning: How to Recover a Failing Project.

Part III then looks at Project Execution: How to Minimize the Risk of Future Failure.

A final chapter describes a recommended approach for project success.

Part I begins by looking at why projects fail. The reasons should look familiar: poor requirements, scope creep, conflicting stakeholder expectations, no real need, lack of user involvement, weak change management, poor quality control, problems caught late. The effects, too, with the blame game and all the rest, are clear enough. Perhaps, as with the signs of alcoholism, the challenge is not what the signs are, but admitting their presence.

Chapter 2 therefore asks quite simply "Is your project out of control?", stepping through the telltale signs: missed milestones, disagreed purpose of project, dependence on "heroes", customer disapproval, employee frustration and "other subtle signs of trouble". If just reading this makes you wince, well, you need to read the book, and you need to get something done about your project.

Part II begins with Analyzing your Project: why is your project failing, what should you do, and how should you go about it. Planning, requirements development and management, peer reviews, defect prevention, metrics: the topics should not be a surprise, but if you are not used to it, the medicine may taste strong. These things are known to work; and, truth be told, nothing else can do the job.

After that, chapters look in turn at why you need to create a plan; how to create the plan; building a team; identifying the products (with a Product Breakdown Structure); identifying the work; establishing a schedule.

Part III looks at executing the plan (with mini-schedules and frequent re-planning); managing expectations inside and outside your organization; managing project scope; managing product quality; and finally optimizing your plan.

Along the way, the authors share a wealth of personal experience, and introduce a wide range of project management (and project engineering) techniques. It is striking how large a part requirements play in all this: far from being an engineering or software matter, requirements discovery and management have a crucial role in ensuring that projects run properly.

As you would hope from a book that is designed to be used in critical situations, this book is short and crisp; accurate and to the point; and it provides excellent leads to other books and tools for when you need to go in deeper, "in slower time", when the crisis has passed.

I hope very much that you manage to save your project. Young, Brady and Nagle are extremely experienced project professionals, and they do everything they can in this book to share their skill with you.

(c) Ian Alexander 2009

Foreword

I have had the pleasure of knowing Ralph Young for many years now. He and his co-authors, Steven Brady and Dennis Nagle are especially well-qualified to write about one of the key practical issues in systems and software development – how to make projects work.

I was struck by the authors’ frank admission in the Introduction that they found it ‘disheartening’ to read analyses of projects that had failed: for the failure analyses are repeated year after year, like the project failures. The lessons are not being learned.

Fundamentally, systems engineering is simple. You find out what is wanted; you work out how to meet that need; and you implement those specifications. The project management side is equally straightforward: you plan according to the engineering need; and you monitor and control the implementation of the plan. There are, as the authors of this admirably clear and practical book show, well-established techniques for running a successful project. They are not ‘rocket science’, though they will do very well for developing satellite launchers, along with any other complex hardware and software.

And yet. And yet. 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 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 like poorly-defined requirements, constantly creeping scope, conflicting and unmanaged expectations, and lack of control can bring disaster to any project. The authors wisely emphasise these key points right up front in this book.

Success depends, then, on teamwork: on a common purpose, on agreed goals, on people in different roles working effectively together. Many engineering textbooks barely mention management; many management books barely consider engineering. Worse, different schools of thought scarcely give each other the time of day, when in fact they are dealing with complementary aspects of the same problem: making a project work. Young and his team are equally at home quoting software and systems engineers as management gurus. They can draw pragmatically on Six Sigma, on Requirements Engineering, on Software Estimation, on Systems Engineering, on Peer Review, on Software Inspection, on Earned Value and many others. This is good and right, and hugely necessary.

How to Save a Failing Project takes an honest look at things we all know, but prefer not to speak about: uncomfortable things like blame, and the signs that a project is out of control, both overt and subtle. Then, the book turns to the positive side: recovery.

“Projects usually can be saved. The characteristics of successful projects are components of the strategy that can be used to save a failing project.”

The bad news then: there is no magic bullet.

The good news: you already know the basic things you have to do to save your project: leadership; planning; communication; effective process; getting good people; using metrics; learning from mistakes.

The better news: these things can be learnt, and are well documented. Metrics, for example, can be applied with mathematical precision – you can predict how many defects will occur, and you can plan for them.

You may well be reading this book in a time of crisis for your project. Be reassured, then, that you have in your hands a huge wealth of project experience, accompanied by calm, practical, step-by-step guidance. The authors have seen many projects in the same state as yours, and they have turned many of them around. I hope very much that you will come to appreciate their wisdom, and to value the crucial importance of good requirements – and especially of good requirement analysts – in setting up and planning your projects in the way they should go.

For quieter moments, part III of the book looks at how to improve your chances next time around. Again, the techniques for sticking to a plan are not quantum mechanics, but simple things like defining many small milestones – Johanna Rothman calls them “inch-pebbles” – to make both progress and deviations easy to identify. The authors illustrate this with literal inches: the story of how an overweight person managed to achieve and exceed a dramatic weight-loss target – 100 pounds in one year – by setting herself small weekly targets for healthy meals and exercise sessions. The message is human:

“Imagine how daunting this plan must have seemed at the beginning of the year!”

Of course the same lesson applies to projects: translate the large and far-off into the small, near, and attainable.

It is salutary to be reminded how central, how critical to project success are the bread-and-butter issues of requirements work: discovering stakeholders’ goals and expectations, identifying and agreeing scope, prioritizing the requirements, tracing them, managing changes. These are not minor technical matters to be left to junior engineers in a quiet backwater of your project. These things determine project outcome – success or failure – more strongly than anything else.

Ian Alexander

You may also like:

Books by Ralph Young:

Books by other authors: