Project Requirements: A Guide to Best Practices

Ralph R. Young

• Publisher: Berrett-Koehler Publishers
• Year: 2006
• ISBN:
  9781523096282
• Edition: 1
• Topic: Business
• Subtopic: Investments & Securities
• Index: Business

Project Requirements: A Guide to Best Practices gives project managers tools they can assimilate and apply easily to improve project success rates, reduce development costs, reduce rework, and accelerate time to market. Based on experience and best practices, this valuable reference will help you:
• Clarify real requirements before you initiate project work
• Improve management of project requirements
• Save time and effort
• Manage to your schedule
• Improve the quality of deliverables
• Increase customer satisfaction and drive repeat business
Project Requirements: A Guide to Best Practices provides project managers with a direct, practical strategy to overcome requirements challenges and manage requirements successfully.

CHAPTER
1

Introduction

When all is said and done, project success comes down to project performance: cost, schedule, and quality. Adopting requirements-shaping practices can greatly improve your project’s probability of success. Additional investment in understanding user requirements early in the project, before you initiate other technical work, will reduce the amount of rework that must be performed. In fact, the reduced rework will pay for any additional costs associated with improving the requirements process!

Granted, this investment needs to be made early, and recouping it will take time. But proceeding without knowing what users really require is asking for problems and, rest assured, will incur added costs for rework. The project manager (PM) needs to address uncertainties using appropriate methods, techniques, and tools, including requirements-shaping PM practices, stakeholder modeling, prototyping, risk analysis, and careful analysis of assumptions.

The Impact of Requirements on Project Success—A Project Management Professional’s Perspective

Numerous surveys conducted during the past decade, including the most widely quoted information technology (IT) industry CHAOS research, have identified requirements issues as a major reason for project failure. PMs have repeatedly experienced this, as we encounter poor requirements processes (or the lack thereof) as a key project issue in our high-priority projects.

For example, based on years of experience in the project management profession, we PMs find requirements gathering to be a very time-consuming activity. In some projects, requirements gathering can take up 25 percent of the project’s life cycle. Yet this activity can be futile, if it doesn’t result in delivering a complete and accurate set of customer requirements. Many organizations continue to treat requirements gathering as an activity, not as a standardized organizational process. To be effective, requirements gathering has to be structured and conducted in collaboration with customers and in association with other requirements activities involving customers, such as requirements elicitation and requirements validation.

PMs can also point to numerous unsuccessful projects, challenged mainly by the project team’s inability to control scope creep. Although this is a very common problem in project development, many project-oriented organizations are unable to manage and control scope creep effectively. Scope changes, depending on when they are introduced to the project, can increase development work (and rework) tremendously. Although project changes, including scope changes, are inevitable, requirements processes in managing and controlling scope changes can help improve the likelihood of project success. Scope changes, along with already accepted requirements, should be reprioritized to contain the entire project scope and to deliver the project according to the predetermined project time line, as originally planned.

Another approach to effectively handling requirements changes is by introducing and institutionalizing a requirements change management process. This can be as simple as requiring change request forms (or change orders) for scope changes and setting up a change control board that is responsible for assessing the project impact of change requests: reviewing, approving, and rejecting change requests. Although it seems simple to implement, many organizations do not take this approach, because customers do not conform to completing change orders and consider the approach too bureaucratic.

PMs have found a number of requirements tools and techniques that are used in requirements processes in the IT industry to be very helpful in improving project success rates. These include requirements traceability matrixes, prototypes, and use cases.

With many PMs familiar with the practice of conducting lessons-learned sessions and applying lessons learned from previous projects to subsequent projects, we use lessons-learned practices in preventing the recurrence of requirements problems and issues. We track requirements issues in current projects and ensure that we address them (and prevent their recurrence) in subsequent projects by introducing and implementing appropriate requirements processes in project development. Guidelines on project management methodology, and project management tools and techniques from A Guide to the Project Management Body of Knowledge (PMBOK^® Guide) (Project Management Institute 2004) are very helpful in establishing and institutionalizing appropriate requirements processes.

In the current state of requirements management in the project management profession, PMs raise and highlight requirements issues as they arise. They attempt to use requirements processes to address the issues. If all PMs apply lessons learned to prevent the recurrence of requirements problems, many requirements issues can be identified and resolved during the early stages of project development or can even be eliminated during project development.

This is not all that simple, however, because many requirements processes require the customers’ involvement and participation, as well as their cooperation and collaboration. Some requirements processes present implementation challenges.

As project management communities in IT organizations focus on tackling the major causes of project failure and take steps to address these requirements issues, PMs are finding that the implementation of organizational requirements processes can and do contribute to project success.

Victoria Kumar, PMP

HOW THE PM WILL BENEFIT BY PAYING ATTENTION TO REQUIREMENTS

The Data and Analysis Center for Software (DACS), a U.S. Department of Defense Information Analysis Center, reports that more than 75 percent of large software projects suffer significant cost and schedule overruns or fail outright. Deficits in project requirements cause more than half of these failures and overruns. This is in part the result of the high complexity of the requirements task (by no means limited to technical complexity!). Finding ways to manage and reduce the complexity is an important step in reducing the risks of software development.

By paying attention to requirements, the PM will improve the likelihood that his or her project will be successful.

WHAT ARE REQUIREMENTS AND WHY ARE THEY IMPORTANT?

A requirement is a statement of a customer need—a statement that identifies a condition, capability, characteristic, or quality factor of a system that is necessary for the system to have value and utility to a user. User requirements specify the verified needs of the intended users of the system (regardless of whether the user chooses to exercise them in the provided system) and system requirements identify a condition, capability, characteristic, or quality factor of the planned system. The Capability Maturity Model Integration (CMMI^®), which is the current industry framework for process improvement, uses the term product requirements as a refinement of the user requirements into the developer’s language; the developer uses the product requirements to guide the design and building of the product (the system).

Requirements are important because they reflect the needs of the customer and users, and because they provide the basis for all the other technical work that is done on a project. Requirements are so important because they:

• Document a common understanding between customers/users and the contractor and provide a basis for work

• Define “what,” not “how”

• Ensure that an engineering project is completed within cost and schedule constraints to the customer’s satisfaction (managing the customers’ and users’ expectations is an important factor).

Figure 1-1 describes what drives requirements.

Understanding requirements is the cornerstone of effective project cost and schedule estimation. A clear understanding of and agreement on the requirements must be reached and committed to by the project and all stakeholders. A defined process for requirements development and requirements management should be established, documented, followed, and continuously improved. Nevertheless, requirements changes are inevitable and must be planned for, managed, and controlled.

Figure 1-1

What Drives Requirements?

Source: Adapted from an original work by Ivy Hooks. Used with permission.

By understanding “requirements basics,” you gain an increased understanding of the importance of requirements to project success.

WHY PAY ATTENTION TO REQUIREMENTS?

Requirements are the basis of all the technical work performed on projects. Major contributing factors to requirements problems include incorrect facts, omitted requirements, lack of user input, incomplete requirements, and changing requirements.

If we don’t handle requirements properly, we incur significant risk. In fact, investing more in your project’s documented requirements process can save at least half the cost of your project.

Other reasons to pay attention to requirements include:

• Requirements errors are the largest class of errors typically found in a project (41–56 percent of errors discovered [Hooks and Farry 2001]).

• Reducing requirements errors is the single most effective action developers can take to improve project outcomes....