How to Save a Failing Project

Ralph R. Young DBA, Steve M. Brady PMP, Dennis C. Nagle

• Publisher: Berrett-Koehler Publishers
• Year: 2009
• ISBN:
  9781567263404
• Edition: 1
• Topic: Betriebswirtschaft
• Subtopic: Projektmanagement

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

I Project Awareness
How to Recognize a
Failing Project

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

FIGURE 1-1: Software Project Outcomes, 1994–2004

From Software Estimation, by Steve McConnell. Reprinted with permission from Microsoft Corporation.

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

FIGURE 1-2: What Must Happen for Stakeholders to Consider a Project Successful?

• 

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