The views expressed in this article are strictly those of Max Wideman.
Published December 2010

Introduction | Book Structure
What We Liked | Downside | Summary


Sooner or later, every project manager is faced with a "failing project" - and even if they aren't, they may well go through that phase when they think they are. So this book should be pretty popular. As authors Ralph, Steven and Dennis state in their Preface to the book:

"Poor project results are all too common. We often hear about projects that are canceled, go over budget, are completed late, or deliver less functionality than promised. Customers are dissatisfied, users are disappointed, and project staff are frustrated and overworked. Program and project managers may even lose their jobs."[1]

Normally, we might observe: "and so they should". But on closer inspection we see that all three authors have extensive backgrounds in the information technology (IT) and systems sectors where, it seems, anything goes. Hence, we conclude that this book is specifically written for those working in the IT sector and who need guidance accordingly to achieve a successful project.[2]

In the past we have argued that too many authors glibly talk about project success and failure without even mentioning what they mean by either. Not in this book. Right up front in their Introduction on page 1 the authors advisedly state that:[3]

"A successful project can be defined as one that is completed within a set budget and schedule and that meets identified goals and objectives. But if project success can be defined in one sentence, why do so many projects fail?"

The authors then answer their own rhetorical question by listing the following eight items:[4]

  • Unachievable objectives
  • Unreasonable expectations
  • Inadequate planning
  • Unclear requirements and ineffective requirements practices
  • Ineffective communication
  • Insufficient resources (often resulting from poor estimation of the work required to conduct the project)
  • Ineffective project tracking capabilities
  • Poor quality and insufficient quality control

That seems to pretty well cover the map, but this is only the beginning because in Chapter 1 the authors offer a further list of ten items:[5]

  • Poorly defined requirements
  • Scope creep
  • Stakeholders have different expectations
  • Stakeholders have unrealistic expectations
  • There is no real need or demand for the product
  • There is a lack of user involvement in the project
  • Change management is lacking or ineffective
  • Poor quality control
  • Problems are caught too late
  • There is no project champion

Given the foregoing, the authors then set about providing a systematic approach to tackling the majority of each of these challenges.


1. Young, Ralph R.; Steven M. Brady; & Dennis C. Nagle, Jr., How to Save a Failing Project: Chaos to Control, Management Concepts, Inc., VA, 2009, p xxii
2. The authors dispute this observation. Their intention is that this book is written for any manager who wants to benefit from experience concerning how to achieve a successful project. In fact they state that "The information, guidance, and references in the book are applicable to any project, not just to projects in the Information Technology (IT) domain." by Email, 11/17/2010
3. Ibid, p1
4. Ibid
5. Ibid, pp12-13
Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page