Pub. Date:
Berrett-Koehler Publishers
How to Save a Failing Project: Chaos to Control

How to Save a Failing Project: Chaos to Control


View All Available Formats & Editions
Current price is , Original price is $57.95. You
Select a Purchase Option (New Edition)
  • purchase options
  • purchase options


How to Save a Failing Project: Chaos to Control

You CAN Turn Around A Failing Project! Poor project results are all too common and result in dissatisfied customers, users, and project staff. With countless people, goals, objectives, expectations, budgets, schedules, deliverables, and deadlines to consider, it can be difficult to keep projects in focus and on track. How to Save a Failing Project: Chaos to Control arms project managers with the tools and techniques needed to address these project challenges. The authors provide guidance to develop a project plan, establish a schedule for execution, identify project tracking mechanisms, and implement turnaround methods to avoid failure and regain control. With this valuable resource you will be able to: • Identify key factors leading to failure • Learn how to recover a failing project and minimize future risk • Better analyze your project by defining proper business objectives and goals • Gain insight on industry best practices for planning

Product Details

ISBN-13: 9781567262391
Publisher: Berrett-Koehler Publishers
Publication date: 05/01/2009
Edition description: New Edition
Pages: 264
Product dimensions: 6.06(w) x 9.06(h) x 0.54(d)

About the Author

Ralph R. Young, DBA, has led projects in local government, management information systems, systems and software engineering, process improvement, and systems integration. He is the author of four books that address aspects of requirements engineering. Dr. Young is a graduate of the University of New Hampshire and holds an MA in economics and a DBA from The George Washington University.
Steve M. Brady, PMP, has worked extensively in the information technology industry, providing project management, organizational process development, business analysis, and strategic planning services. Mr. Brady holds a BS in management of information systems and an MBA from Wright State University.
Dennis C. Nagle, Jr., has spent more than 20 years as an engineer on project teams, both as a programmer and also as the principal software architect. He is certified in the personal software process (PSP) as defined by the Software Engineering Institute at Carnegie Mellon University. Mr. Nagle holds a BS in Computer Science from Virginia Tech and an MS in Computer Science from Wright State University.

Read an Excerpt

How to Save a Failing Project

Chaos to Control

By Ralph R. Young, Steven M. Brady, Dennis C. Nagle Jr.

Management Concepts Press

Copyright © 2009 Management Concepts, Inc.
All rights reserved.
ISBN: 978-1-56726-239-1


Why Projects Fail

The data on project success rates are alarming. According to the Standish Group's CHAOS Report, based on biennial surveys of software project outcomes, about 75 percent of all software projects are delivered late or fail. The data also show that since 2002, the rate of successful project completion has dropped significantly.

Delayed projects are not problematic simply because they are late. On a late project, significant planned functionality is often discarded in an effort to stay on schedule and keep costs down. So the average schedule overrun of about 120 percent and average cost overrun of 100 percent shown in Figure 1-1 are significantly understated. Completing projects often takes more than twice as long and costs twice as much as we estimate! How can it be that we haven't made progress in delivering software on time or under budget? In 1981, Barry Boehm provided a seven-step approach to estimating software projects in Software Engineering Economics. Yet most projects today do not use even this level of discipline in preparing estimates.

Steve McConnell, author of Software Estimation: Demystifying the Black Art, writes, "The industry data show that the software industry has an underestimation problem. Before we can make our estimates more accurate, we need to start making the estimates bigger. That is the key challenge for many organizations." Industry expert Capers Jones writes that the root cause of project failure is poor project management, not technical issues or the competence and ability of technical personnel.

The failure to adequately plan using useful and effective measures is the root cause of project failure. This book will enable you to save a failing project. Even better, it will enable you to manage projects while reducing the risk of failure.

Key Factors Leading to Failure

While many factors lead to the failure of a project, in the authors' experience, a few specific, easily recognizable factors signal serious problems that jeopardize project success:

* 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.

Poorly Defined Requirements

Execution of the project is begun prematurely, before requirements are defined, analyzed, and agreed upon. The team then performs a great deal of technical work that lacks a focused vision of the real needs, objectives, and work products.

Scope Creep

New requirements and changes to requirements are accepted without any control or management of the requirements. This scope creep occurs on all projects and is one of the major reasons that projects get out of control. (Chapter 12 provides several suggestions for controlling scope creep.)

Stakeholders Have Different Expectations

A stakeholder is anyone who has an interest in the success or failure of a project. A critical basic foundation for successful project planning and execution is that all (or at least as many as possible) of the stakeholders need to be identified at the outset, and their objectives and expectations must be stated, refined, and clarified.

Project stakeholders may include the customer, end users, customer management, developer's PM, developer's management team, corporate stockholders, project team members, subcontractors, and the contracts office.

Writing a vision and scope document is an effective way to facilitate the process of identifying, refining, and clarifying stakeholder needs and expectations. This document should provide a vision for the project that is broad enough for all stakeholders to embrace, and it should clarify a reasonable scope (what is to be included or excluded). You'll learn more about the vision and scope document in Chapter 12.

Figure 1-2 delineates each type of stakeholder's expectations with regard to project success.

Managing these expectations is essential. Different stakeholder groups will have different needs and expectations. For example, customers may consider these factors when evaluating a project:

* Timely completion

* Completion within budget

* Project meets the agreed-upon requirements

* Whether a team/partnership approach was used to plan and execute the project.

Users may have a somewhat different perspective — they also are likely to be interested in timely completion of the project, but they may be more focused on the functional requirements and features of the delivered products, system, or software development effort than they are on completion within the allocated or planned budget.

It's important to realize that there may be several subcategories of users, and each subcategory may be primarily interested in a somewhat different set of functional capabilities. This is a major reason that the requirements elicitation methods and techniques you choose must provide a mechanism for prioritizing the requirements and helping each subcategory of users understand the vision, needs, and objectives of the other subcategory groups. (Requirements elicitation is the process of determining the real requirements. Real requirements are a subset of the stated requirements that are verifiable and prioritize needs for a particular system or capability.)

The project developer/supplier is perhaps most interested in the team or partnership approach that is used to execute the project and in making a profit.

Project team members may be most concerned about their quality of life (read: they want to work minimal overtime). They want to do fulfilling work that is challenging and that offers technical growth and professional development, and they seek appreciation and recognition.

Subcontractors may be primarily interested in being paid well for their expertise and experience. And finally, the customer's and developer's contracts officers may be most focused on ensuring that the terms and conditions of the contract are met by the other party.

Project weaknesses or problems can cause stakeholder groups to have dissenting opinions. These problems can include:

* Failure to write a vision and scope document, to circulate it to the various stakeholder groups, and to reach agreement on what the project will accomplish.

* Failure to identify the stated requirements (the requirements provided by a customer at the beginning of a development effort) of the stakeholder groups and to work with them to reach some consensus on the real requirements for the project.

* Failure to put in place an effective mechanism to control changes to requirements and limit new requirements, which will inevitably be discovered as the project proceeds.

* Failure to perform effective requirements analysis to gain insight into what is really required to deliver the desired work products and results. Requirements analysis is a structured, organized method of determining the product attributes that will satisfy a customer need.

* Failure to build in quality during the performance of the project. Quality products can be defined as those meeting real customer needs. How can your project team ensure quality?

* Perform peer reviews and inspections of the work products. This is one of the most effective ways to discover problems, errors, defects, and omitted requirements. We have observed that peer reviews can detect approximately 75 percent of the defects in the reviewed product.

* Ensure testability of each requirement at the beginning of the effort. This will save money and time during testing.

* Always use a defect prevention process, regardless of the process maturity level of the project (the degree to which defined, documented, trained, and understood processes are used).

It's important to realize that the "success" or "failure" of a project is based on each particular stakeholder's perspective. Therefore, the effective program or project manager must tailor her or his communications to each stakeholder audience, keeping each group's needs in mind. Moreover, the PM must make a concerted, continual effort to keep each stakeholder group informed, engaged, and actively supporting the project.

Keep in mind that you may have negative stakeholders — those who hope (openly or secretly) that your program or project fails. Someone who fears having to learn new ways of performing work when your project replaces an old system might be a negative stakeholder. The PM must be sensitive to the possibility of negative stakeholders and ready to develop strategies to overcome resistance.

Stakeholders Have Unrealistic Expectations

Very often, customers and users have unrealistic expectations of what a project, system, or software development effort will do or address. Unless the project team clearly defines and communicates the results it anticipates, these stakeholders may assume that the project will fulfill all of their needs — even those that are unreasonable. You might try to appease stakeholders who have such expectations by sharing with them a plan to release products and updated versions of those products over a reasonable period of time.

There Is No Real Need or Demand for the Product

Developing a product for which there is no need or demand is a surefire way to lose money and render a project unsuccessful. The English Channel Tunnel, also known as the Chunnel, is one mega-project that is considered a failure. The Chunnel is a 31-mile rail tunnel connecting England and northern France beneath the English Channel. The developers thought that people would be willing to pay anything to be able to make a quicker trip between the two countries. In reality, however, many travelers prefer taking the ferry for the scenery and relaxation. The Chunnel is an economic failure due to lack of customer demand.

There Is a Lack of User Involvement in the Project

Projects that involve users extensively throughout the project life cycle are more successful. Figure 1-3 shows how the PM can involve users throughout the project.

Change Management Is Lacking or Ineffective

When developing products, it's essential to provide configuration control, or careful tracking of the work products, versions, and releases, so that everyone has access to the current material. It is all too easy for projects to spiral out of control because of ineffective change management.

Poor Quality Control

All work products must be subject to quality control through peer reviews and effective quality assurance procedures. Quality work products meet requirements and are free of defects. Having defect-removal processes in place is not enough. A quality assurance team must conduct process audits and analyze data to verify that these processes are being followed. Chapter 13 discusses quality control techniques in greater detail.

Problems Are Caught Too Late

Many project management books and articles recommend a set of measures (often called metrics) to help keep track of the work being performed on a project. Standard project metrics include headcount (the number of people assigned to the project), cost, quality, customer satisfaction, and schedule variance, to name just a few. The major problem with these metrics is that they are all lagging indicators — that is, they provide insight into what has already happened. As a result, a problem can become quite big before we even realize that we have a problem — and then we must figure out how to address it and implement the solution.

A related problem that often compounds the situation is that managers often want to hear only good news. If the project environment does not encourage trust, honesty, and open communication, the project staff may not report problems, issues, or negative metrics. Management, then, does not learn about problems (potential or real) early enough to help the team handle them.

Arbitrary targets set by upper management are yet another problem. Senior managers often think that missing a target is unacceptable. It should be no surprise, then, that teams often report only what senior management expects to hear — that the targets have been met, even if they actually have not.

The result of our reliance on lagging indicators and of indulging these management expectations is that underlying problems and difficulties are not discovered or reported during the project performance period, when they could be fixed. Rather, we suddenly discover that the task, phase, or project is a gigantic failure at the end. We seem to prefer to hear very bad news at the end of a project rather than in smaller doses earlier on, when problems actually crop up.

The End Results of a Failed Project

Truly successful projects meet the needs of all stakeholders. When one stakeholder is unhappy, the project has failed that stakeholder to some extent. If enough stakeholders are unhappy for a long period of time, the project most likely will be terminated, and all stakeholders will be severely affected. It's very important to balance the needs and expectations of all stakeholders in order to execute a truly successful project.

Remember that a project's success or failure is based on stakeholders' perceptions. Take, for example, a project that produced an exceptional, high-quality product on time and within budget. The customer is ecstatic, and the company made a profit. But the team members worked 80 hours a week for months to complete the tasks. At the end of the project, they were exhausted, and some decided to leave the company. Was this really a successful project?

Truly successful projects meet the needs of all stakeholders. When one stakeholder is unhappy, the project has failed that stakeholder to some extent. If enough stakeholders are unhappy for a long period of time, management will most likely terminate the project. It's very important for the PM to balance the needs and expectations of all stakeholders to execute a truly successful project.

After all of the hopes, effort, expense, pressure to perform, missed deadlines, and disappointment, what happens when a project fails? How does a failed project affect stakeholders?

The Customer's Point of View

The customer finally realizes that the project team cannot or will not provide quality products and does not use any products that were delivered. The customer's needs remain unmet, and the customer must continue to make do with existing capabilities.

The Effect on Team Members

Members of the failed project team are likely to have worked a lot of extra hours. They feel exhausted, stressed, and empty, having worked for months only to fail in their mission. Colleagues from other parts of their organization may lose respect for them and not want to be associated with them. Team members may worry that they've ruined their reputations within the organization and might start looking for employment elsewhere. When key members of the project team depart, others are likely to become even more discouraged.


Excerpted from How to Save a Failing Project by Ralph R. Young, Steven M. Brady, Dennis C. Nagle Jr.. Copyright © 2009 Management Concepts, Inc.. Excerpted by permission of Management Concepts Press.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

Table of Contents


PART I Project awareness: How to Recognize a Failing Project,
CHAPTER 1 why Projects Fail,
CHAPTER 2 Is Your Project Out of Control?,
Part II Project Planning: How to Recover a Failing Project,
CHAPTER 3 Analyzing Your Project,
CHAPTER 4 why create a Plan?,
CHAPTER 5 creating the Plan,
CHAPTER 6 Building a Team,
CHAPTER 7 Identifying the Products,
CHAPTER 8 Identifying the work,
CHAPTER 9 Establishing a Schedule,
PART III Project Execution: How to Minimize the Risk of Future Failure,
CHAPTER 10 Executing the Plan,
CHAPTER 11 Managing External and Internal Expectations,
CHAPTER 12 Managing Scope,
CHAPTER 13 Managing Quality,
CHAPTER 14 Optimizing the Plan,
FINAL THOUGHTS A Recommended Approach for Project Success,

Customer Reviews

Most Helpful Customer Reviews

See All Customer Reviews

How to Save a Failing Project: Chaos to Control 4 out of 5 based on 0 ratings. 1 reviews.
RolfDobelli More than 1 year ago
Project managers Ralph R. Young and Steven M. Brady and engineer Dennis C. Nagle Jr. promise that business project failures are often fixable, whether the problems arise from flaws in planning, process development or communication. They note that companies often can repair broken projects by replanning them in greater detail, and they tell managers how to do that, one small step at a time, by replacing milestones in a project plan with a larger number of “inch stones,” or objectives that involve short-duration tasks. The authors, using a clear expository style that only occasionally succumbs to jargon, explain that the human touch is also a crucial factor in project success or failure. For example, they say managers should encourage their team members to discuss errors openly so they focus on improvement, not blame. Although the book clearly applies to software development projects, getAbstract also recommends it to readers in other industries because the content is helpful and relevant for many other types of projects.