About the Authors

Ralph Young, DBA, has focused his career on managing and improving technical efforts, projects, and organizations. He has led projects and teams in different venues, including local and federal government, management information systems, systems and software engineering, process improvement, systems integration, and organizational change management. He has authored four books that address aspects of requirements engineering: Effective Requirements Practices (which explains what to do on a project and in an organization); The Requirements Engineering Handbook (which addresses how to perform requirements engineering); Project Requirements: A Guide to Best Practices (which recommends a set of best practices and explains why project managers should invest in the requirements process); and, with Paul J. Solomon, PMP, Performance-Based Earned Value (which proposes changing industry practices regarding the use of earned value techniques on a project to a performance-based approach). Dr. Young believes that leadership and effective requirements development and management are key factors in achieving successful project outcomes. He holds a BA in economics from the University of New Hampshire and an MA in economics and a DBA from The George Washington University.

Steve Brady, MBA, PMP, is a senior project manager with more than 14 years of project management experience. His professional experience includes some 20 years in the information technology industry, providing project management, organizational process development, and strategic planning. As a project manager, Mr. Brady has led both custom software development and commercial off-the-shelf (COTS) product implementations. He is versed in every area of the development life cycle and has led projects for federal, state, and local governments. Throughout his career, Mr. Brady has developed and executed organizational processes in a number of firms, including Motorola, Northrop Grumman, and TASC Inc. He specializes in executing projects using mature processes and has five years of experience leading a Capability Maturity Model® Integration (CMMI) Level 5 project, the Software Engineering Institute’s highest maturity level. He holds a BS in management of information systems and an MBA from Wright State University.

Dennis Nagle, Jr., has spent more than 20 years as an engineer on many project teams, both as a programmer and also the principal software architect. Based on this experience, he brings the developer’s or performer’s point of view to the project management process. Mr. Nagle is certified in the Personal Software Process (PSP) as defined by the Software Engineering Institute at Carnegie Mellon University. He received a Northrop Grumman Achievement Award for his significant contribution toward his business unit’s receiving a Capability Maturity Model® Integration (CMMI) Level 5 rating. Mr. Nagle believes that managing stakeholder expectations and creating accurate estimates based on historical data are crucial for successful projects. He holds a BS in computer science from Virginia Tech and an MS in computer science from Wright State University.

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

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

 The Impact on Business

The customer is likely to have less cash flow and lower productivity and effectiveness in areas affected by the anticipated project. The project developer likely is struggling with increased expenses and losses after adding people to the project in an effort to turn it around.

 Blame

Various groups of stakeholders will attempt to determine who is responsible for the failure. There are probably several reasons why the project failed, but no one will want to take responsibility for any of them.

 Unwanted Publicity

Both the customer and the developer may receive unwanted, unfavorable publicity that is likely to damage their reputations and negatively affect their future business activities.

 In Brief

Projects can fail for a number of reasons, including poorly defined requirements, scope creep, stakeholders’ contradictory or unrealistic expectations, lack of demand for the product being made, lack of user involvement in the project, poor or nonexistent change management, poor quality control, and failure to catch problems until it is too late. The underlying problem in all of these situations is the lack of an effective plan or failure to continually update the plan as the project is executed. Typical metrics are not effective because these measures are lagging indicators that do not draw attention to problems until it is too late to solve them easily.

Stakeholder groups have different perspectives, and different stakeholders use differing criteria to evaluate the success of a project. The PM must understand the needs of these groups and must tailor communications to each group to address its expectations. The failure to maintain communications or manage expectations can result in a failed project. When a project fails, there is a huge mess left to clean up. Customers’ needs will go unmet, project team members’ reputations may be damaged, and the project developer may struggle financially and be subject to negative publicity.

In later chapters, you’ll learn that effective planning involves more than developing a schedule and budget and monitoring them using typical metrics. Effective planning also requires identifying the products to be provided and estimating the resources needed to develop them.

 Suggested Reading and Resources

Notes

1. Steve McConnell, Software Estimation: Demystifying the Black Art (Redmond, WA: Microsoft Press, 2006).

2. Ibid., 27.

3. Capers Jones, “Software Project Management Practices: Failure Versus Success.” CrossTalk: The Journal of Defense Software Engineering 17 (October 2004): 5–9.

4. A project champion is an advocate of the project who is very familiar with customer requirements and who provides an active and vocal role in the development effort. The project champion defends the project when necessary, for example, from the project sponsor (the person or organization prioritizing funding for the project) and from critics of the project.

5. See Ralph R. Young, The Requirements Engineering Handbook (Boston: Artech House, 2004): 65–67, for a discussion of how to identify project stakeholders. For a more extensive treatment, go to www.scenarioplus.org.uk/download_stakeholders.html; the “Onion” Model of Stakeholders may be of use.

6. See Ralph R. Young, Project Requirements: A Guide to Best Practices (Vienna, VA: Management Concepts, 2006): Appendix C, for a project vision and scope document template.

7. See Ralph R. Young, Effective Requirements Practices (Boston: Addison-Wesley, 2001): 58–91, for a detailed discussion of how to evolve stated requirements into real requirements.

8. Ibid.

9. Honesty is one of the most powerful tools a PM can have. See Steven Gaffney, Just Be Honest: Authentic Communication Strategies That Get Results and Last a Lifetime (Arlington, VA: JMG Publishing, 2002). This book describes why honesty is the easiest and most effective way to communicate. Honesty will provide immediate and dramatic results with anyone, regardless of their background, needs, personality, or personal agenda. See also www.honestcommunication.com for more valuable resources to help improve communications and establish genuine relationships, trust, and support with colleagues.

10. See Karl E. Wiegers, “See You In Court,” Software Development Magazine 11.1 (January 2003), for a discussion of several practices that might help you balance and maintain the needs and expectations of all stakeholders.

11. Rob Sabourin (rsabourin@amibug.com) offers an economical inspections training and implementation approach.