11/18/10
How to Save a Failing Project: Chaos to Control
By Authors Ralph R. Young, Steven M. Brady, & Dennis C. Nagle, Jr.
(A book review by R. Max Wideman)
The views expressed in this article are strictly those of Max Wideman.
Published December 2010
Introduction
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
AEW Services, Vancouver, BC 2010
Email: [email protected]
How to Save a Failing Project: Chaos to Control
Page 2 of 8
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.
Book Structure
Aside from the Introduction and Final Thoughts, this book is essentially arranged in three parts
representing the major phases of Planning and Execution in the typical project life span. Each chapter
concludes with a summary titled "In Brief" and "Suggested Reading and Resources" plus any chapter
(end) "Notes".
The book's contents are as follows:
Foreword
Preface
Acknowledgements
Introduction
Part I Project Awareness
1. Why Projects Fail
2. Is your Project Out of Control
Part II Project Planning: How to Recover a Failing Project
3. Analyzing Your Project
4. Why Create a Plan
5. Creating the Plan
6. Building a Team
7. Identifying the Products
8. Identifying the Work
9. Establishing the Schedule
Part III Project Execution: How to Minimize the Risk of Future Failure
10. Executing the Plan
11. Managing External and Internal Expectations
12. Managing Scope
13. Managing Quality
14. Optimizing the Plan
Final Thoughts A Recommended Approach for Project Success
Acronyms
Glossary
References
As can be seen from these contents, the number of chapters in Part II Project Planning is the largest,
suggesting therefore that planning is the most important part of any project. And so it should be. If you
don't know how to get to where you are going, the chances of arriving are slim indeed. In fact, the
presumption throughout the book is that your project is already failing, which is consistent with the
book's title.
AEW Services, Vancouver, BC 2010
Email: [email protected]
How to Save a Failing Project: Chaos to Control
Page 3 of 8
What we liked
All of the chapters are quite brief and very much to the point. They provide clear descriptions of the
problems and the steps to take to fix them, or avoid them in the first place. These are easy to follow
through the use of extensive bullet-form entries.
So, having established all the reasons why projects fail, the question is: How do you know your project
is out of control? Good question. In the Introduction, the authors identify these telltale symptoms:6
Missed milestones and deliverables
Differing opinions of the project's goals and objectives
Exceeded budgets
Missed schedules
Dependence on heroes
Customer dissatisfaction and disapproval
Frustrated staff, and
Concerns voiced by various and many stakeholders.
While this list may not be comprehensive, at least it gives you a good idea of what to look for. In our
own experience we have had to extricate projects that have effectively come to a complete standstill at
which point, executive management finally took notice.
But as if that is not enough, the authors also point to Other Subtle Signs of Trouble:7
Requests from customers to make changes to requirements
Staff attrition
Tension during meetings
Surprises
Lack of trust
Lack of honest feedback
Lack of management support
Consistently operating in 'crisis mode'
Finger-pointing
Defects in delivered work products
Frequent rework
Declaring incomplete work products 'done'
Poor assumptions
Project risks aren't mitigated
Ineffective meetings
Delayed decisions
Counterproductive responses to bad news
Sound familiar? Each of these is described in greater details.
We rather liked Chapter 3, Analyzing Your Project. As the authors state:8
"Planning should be based on the business objectives that must be met and the functional
goals of the completed project. If project teams want to succeed, they must focus on
project planning, then on process and procedure development. PMs often believe that
such effort is unnecessary, but in our experience, the failure to develop (or adapt from
others' experience and existing documents) processes, procedures, and checklists is a root
cause of project problems."
AEW Services, Vancouver, BC 2010
Email: [email protected]
How to Save a Failing Project: Chaos to Control
Page 4 of 8
While later they observe about The Plan Components:9
"As we worked with the project's stakeholders, it became clear that many thought that a
Microsoft Project schedule equaled or provided a project plan. This is a common
misconception. We realized that we needed to educate the team about what a plan
contains, each component's purpose, and how long a good plan would take to develop."
[Emphasis added.]
The authors then go on to describe seven key components of a good plan. Of these, we were gratified to
see that they list Product Breakdown Structure (PBS) and Work Breakdown Structure (WBS) as two
separate items, and explain why they are distinctive and necessary. For example:10
"If a project team does not identify all of the products it must build, it cannot account for
all the associated work or accurately estimate the effort, time, and resources required to
execute the project effectively. If the plan does not address all of the needed resources or
allow enough time to get the job done, then the project automatically starts behind
schedule and over budget."
How often have you seen "secondary" products like time-consuming team meetings and administration
quietly ignored as though they didn't exist or were not a part of the project? And then you find the
"management" time charges and costs coming home to roost later on, see Figure 1. Clearly, in planning
and estimating it is not sufficient to consider only the technical delivery work.
Figure 1: Distinguishing between Management and Technical work11
Later the authors observe that:12
"Even if you have prior experience, creating a plan can be very challenging. It's critical to
obtain stakeholder acceptance during the planning process. Without stakeholder support,
it becomes difficult, if not impossible, to execute the plan . . . Developing a plan should
be considered a mini-project with its own schedule and resources."
As might be expected, the chapters on Managing Scope and Quality are all about managing the
technology. Here, the authors have pearls of wisdom of general application. For example:
The average project invests three percent of total costs in the project-long requirements process,
but data from NASA show much better results are achieved when eight to 14 percent of total
project costs are invested in the requirements process.13
Customers and users provide what we call stated requirements, the requirements given at the
AEW Services, Vancouver, BC 2010
Email: [email protected]
How to Save a Failing Project: Chaos to Control
Page 5 of 8
beginning of a system- or software-development effort. Of course, the stated requirements are
never the real requirements.14
The earlier a defect or error is discovered, the easier it is to fix; the less impact it will have on
other work products and the project as a whole; [and] the less it will cost, and time it will take, to
get back on track.15
Downside
In reading through the book we did feel that it is more suited to project management practitioners
working in the information technology and similar domains. While the information and advice for this
area of project management application comes across as most valuable and sound, it may not be
appreciated by those working in other areas such as construction and infrastructure.
We also got the impression that the reader is assumed to be in the position of a service supplier working
under contract. For example, see What Must Happen for Stakeholders to Consider a Project Successful,
Figure 2.16 If this is true, then from the owner or sponsor's point of view, their project is already well
down the line in the execution phase.17 The effect of this difference is that in the former the extent and
quality of information on which the project is based should be much more reliable and hence amenable
to the application of the tools and techniques described in the book.
Figure 2: What Must Happen for Stakeholders to Consider a Project Successful18
In the latter, however, the quality of the data is much less certain. This is not to say that the need for
thorough planning is any less important. On the contrary, such planning needs to be properly revisited as
better data becomes available to avoid the misconceptions, confusion, and miss-communications that
otherwise build as the project proceeds into the execution phase. The authors emphasize this point by
discussing "Fact-based Management"19 and later, instead of milestones they talk about "Planning Using
Inch Stones".20
AEW Services, Vancouver, BC 2010
Email: [email protected]
How to Save a Failing Project: Chaos to Control
Page 6 of 8
For the owner/sponsor, we believe that it is vital to emphasize the need for a project owner's Business
Case to justify the project in the first place. This sets the stage for the project to follow a logical Total
Project Life Span such as that shown in Figure 3.21
Figure 3: The generic Total Project Life Span
Returning to the issue of how stakeholders consider a project successful, Figure 2, the problem is that
certain key stakeholders, such as the owner, sponsor, users and observers generally do not view success
in the same way. They look at the resulting product and ask the question: "Did it work and did it make
money?" In other words, did the product produce the intended benefits? If not, the project was not a
success. In short, we suggest that Figure 2 would be more inclusive if it included a final column
covering the Benefits Realization phase of the product life cycle.
To their credit, the authors cite a case in which the project produced "an exceptionally, high-quality
product on time and within budget . . . and the company made a profit". However, they suggest that
some could still consider this project to be a failure on the grounds of excessive overtime that resulted in
an exhausted team. Our experience is that overtime is often invoked because of the amount-at-stake by
the end of the project and the team may be exhausted but nevertheless happy to be done successfully.
Finally, the authors list Scope Creep as one of the Key Factors Leading to Failure "and is one of the
major reasons that projects get out of control."22". While this is unfortunately true, we don't go along
with their assertion that: "This scope creep occurs on all projects . . ."23 We suggest that scope creep, as
defined in the glossary, should not occur on projects that have properly implemented management
controls. This has been the case for many of the projects we have worked on. However, your experience
may be different depending on the type of project and your definition of "scope creep".
Summary
For those working, or contemplating working in the project fields of information technology, systems,
and administrative or change projects, and the like, this book provides valuable guidance.
AEW Services, Vancouver, BC 2010
Email: [email protected]
How to Save a Failing Project: Chaos to Control
Page 7 of 8
24
As the authors put it:
"How to Save a Failing Project: Chaos to Control 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.
Use and continuously update the project plan as you execute the project
Recognize signs that the project is deviating from the approach needed for
successful completion
Develop metrics that provide insight into the health of your project
Identify and implement steps to get your project back on track
Prevent missteps that can lead to project failure
Position your team for project success
So, if you fear that your project is failing, or is likely to do so with the symptoms we have listed, this is
the book for you. It is most valuable whether for "Saving a Failing Project", or preventing it from
becoming one in the first place.
R. Max Wideman
Fellow, PMI
References
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
6
Ibid, p2
7
Ibid, p31-33
8
Ibid, p46
9
Ibid, p54
10
Ibid, p91
11
Ibid, p111
12
Ibid, p74
13
Ibid, p153
14
Ibid, p154
15
Ibid, p176
16
Ibid, Figure 1-2, p14. See in particular first two columns in last two rows.
17
The authors state that this is not their intent.
18
The authors agree that this is a very important figure. They do not agree that benefits realization, did it work,
did it make money, did it produce the intended benefits, are beyond the control of the categories of stakeholders
that are listed.
19
Ibid, p57
AEW Services, Vancouver, BC 2010
Email: [email protected]
How to Save a Failing Project: Chaos to Control
Page 8 of 8
20
Ibid, p71. "Inch Stones"? We like to think of them as "Inch Pebbles"!
In the authors view, the verbiage provided here is not very insightful. In fact, they think that Figure 3 should be
omitted from the discussion since it does not provide useful information. Instead, they would prefer to see
additional positive comments about areas addressed in the book.
22
Ibid, p13
23
Ibid. The authors define scope creep as "The acceptance of new requirements and changes to requirements
without any control or management" Glossary p216
24
Ibid, back cover
21
AEW Services, Vancouver, BC 2010
Email: [email protected]
