I don't have time to manage requirements

my project is late already!

Richard Larson, PMP, Co-Principal, Watermark Learning, Inc.

Introduction

For those of us who have been given imposed deadlines that often seem arbitrary and unreasonable, managing requirements is one of the last things we want to do on a project. We worry about getting the product built and tested as best as we can. And we feel fortunate to gather any requirements at all. However the lack of a well-managed requirements process can lead to common project issues, such as scope creep, cost overruns, and products that are not used. Yet many project professionals skim over this important part of the project and rush to design and build the end product.

This paper provides an overview of requirements management, emphasizing the relationship between requirements management and project management. It describes the requirements framework and associated knowledge areas. In addition, it details the activities in requirements planning, describes components of a Requirements Management Plan, and explains how to negotiate for the use of requirements management tools, such as the Requirements Traceability Matrix to “get the project done on time.”

The Case Against Requirements Management

It is not uncommon to hear project professionals and team members rationalize about why requirements management is not necessary. We commonly hear these types of statements:

  • “I don't have time to manage their requirements. I'm feeling enough pressure to get the project done by the deadline, which has already been dictated.”
  • “Our business customers don't fully understand their requirements. I doubt if all the details will emerge until after we implement!”
  • “My clients are not available. I schedule meetings only to have them cancelled at the last minute. They don't have time. They're too busy to spend time in requirements meetings. And my clients, the good ones, are working on other projects, their day-to-day jobs, fighting fires, and their own issues.”
  • “Managing requirements, when they're just going to change, is a waste of time and resources. It creates a bureaucracy. It uses resources that could be more productive on other tasks, such as actually getting the project done!”

Requirements Management Overview

Project Management Institute (PMI) (2004, p. 111), International Institute of Business Analysis (IIBA) (2006, p. 9), and the Institute for Electrical and Electronics Engineers (IEEE) (1990, Standard 610) all define a requirement as a condition or capability needed to solve a problem or achieve an objective that must be met by a system or system component to satisfy a contract, standard, or specification.

Requirements management is an important part of the discipline of business analysis that includes the planning, monitoring, analyzing, communicating, and managing of those requirements. The output from requirements management is a Requirements Management Plan, which on large projects can be a formal set of documents with many subsidiary plans. Examples are a Requirements Communication Plan, Requirements Risk Plan, estimates and schedule for the requirements definition work effort, and many more. On smaller efforts it can be an informal roadmap. In either case, it is subsidiary to the overall project management plan.

If care isn't given to planning these activities, the entire project could go awry. Lack of requirements management is one of the biggest reasons why 60% of project defects are due to requirements and almost half of the project budget is spent reworking requirements defects (Software Engineering Institute (SEI's) Square Project updated 5/12/05).

Although we're going to focus on Requirements Planning in this paper, it is well to understand the requirements management framework, which is based on IIBA's Business Analysis Body of Knowledge (BABOK). Below is a summary of the knowledge areas in the framework.

Business Analysis Planning and Monitoring

This knowledge area addresses the set of activities that are included as part of planning the requirements definition phase or phases of a project. Although not all project life cycles include a formal phase for requirements definition, the activities that comprise requirements definition need to be taken into account, either formally or informally.

Below is an exhibit showing the relationship between the requirements management plan and example set of plans that are subsidiary to the integrated project management plan. As indicated, the requirements management plan is incorporated into the project management plan, and all the subsidiary requirements management plans are incorporated into the subsidiary plans within the overall project management plan. We will have a deeper look at requirements planning later in this paper.

The Requirements Management Plan in Relation to Project Management

Exhibit 1 – The Requirements Management Plan in Relation to Project Management

Enterprise Analysis

This knowledge area focuses on clarifying the business need, problem, or opportunity, defining the product scope, and developing a business case. Whether it belongs more to project management or requirements management is less important than understanding that the relationship between the Enterprise Analysis knowledge area and A Guide to the Project Management Body of Knowledge (PMBOK® Guide) is twofold:

  1. The focus of Enterprise Analysis is on the product, or solution to the business problem, rather than on the project.
  2. While Scope Management covers the scope of the entire project, Enterprise Analysis covers the scope of the product, service, or end result of the project.

Requirements Elicitation

This set of activities includes gathering stakeholder requirements and ensuring that their needs have been understood. Effective elicitation requires the ability to ask the right questions, listen to and synthesize responses, and record customer requirements. These skills are required for effective project management as well. Requirements elicitation is related to both the Scope and Communications Management knowledge areas of the PMBOK® Guide.

Requirements Analysis

This set of activities includes the progressive elaboration of requirements from highest level to lower levels of detail as more becomes known. Its purpose is to ensure that the business needs are truly understood. The requirements need to be elaborated in enough detail so that business clients are satisfied that their needs will be met and the development team can create the end product or service. This knowledge area also includes verification and validation, meaning confirmation that the product or service does, indeed, solve the stated business problem, and that the requirements will produce quality results. This knowledge area is associated with Scope and Quality Management as well.

Solution Assessment and Validation

This knowledge area describes how well the solution, or end product, solves the stated business problem and meets the approved requirements. This knowledge area includes activities related to making sure the end product matches the stated requirements and is closely related to Quality Management.

Requirements Management and Communication

This set of activities involves the packaging of requirements to provide the level of documentation agreed upon in the Requirements Communication Plan, taking into account the various audience preferences for format, level of detail, and frequency of communication. It also covers the handling of conflicts and issues. Finally, this knowledge area describes managing changes to the product and version. Because changes have to be managed across requirements definition, it relates not only to Communications Management, but also to Integration Management.

Below is a matrix summarizing the interrelationship between the knowledge areas for Requirements Management, as shown in the BABOK, and project management, as framed in the PMBOK® Guide.

Integrating Requirements Management and Project Management

Exhibit 2 – Integrating Requirements Management and Project Management

Getting to the Right Amount of Requirements Management

Choosing an appropriate requirements management process is critical. It is important to find the balance between the extremes of a burdensome process and no process at all. All levels of rigor can be appropriate, depending on the project and the organization where the process is followed. On some projects, following a great deal of rigor is required; on others little is. Ambler, a proponent of the Agile approach, discussed the importance of “just-in-time JIT requirements elicitation” (2007). Davis discussed his “Just Enough” approach (2004). Some of us remember the pre-process and pre-methodology chaos of the 1970s. It was not uncommon for developers to sit down by themselves or at best with a single “user” to hammer out features of a new piece of software. Those of us who lived through that time remember some of the issues of the “user” who articulated his or her own needs, but who didn't represent all the stakeholders. Or management who pitted one developer against another to try to get the software developed sooner, or the developers who dictated to the business what was in and what was out of scope.

Nevertheless, too much rigor can become overly burdensome. Here are some pitfalls to avoid:

  • Misaligning the amount of rigor required with the size of the project. One example of misalignment is having inappropriate levels of approval, such as requiring a formal Change Control Board for a small, wellunderstood, low-impact, and well-accepted change.
  • Developing a requirements management plan that takes more time to create than developing the product.
  • Requiring the creation of a requirements management plan “because that's the process we follow here.”
  • Handling all projects with the same degree of requirements management.

The “right” amount of requirements management occurs when there is enough rigor to:

  • Reduce business and product risks.
  • Communicate effectively with all stakeholders. Communications becomes more complex with more stakeholders, so formalizing the communications on larger, more complex projects is usually appropriate.
  • Help ensure that a quality product is delivered at the end of the project.

To this end, some applications of requirements management may need more emphasis than others. For example, one of the authors was the project manager on a new retail application where the risk included the possibility of having incorrect prices on all the items in all the retail store locations. The project team spent several months planning traceability, testing, implementation, risks, communications, and other aspects of requirements management, and we implemented a three-year project within days of the projected date. However, she also managed a project that she thought was “small,” ignoring requirements management completely. The team spent several months in “stabilization,” which was a nice term for cleaning up the mess that had been created.

A Further Look at Requirements Planning

Now that we have looked at the framework for requirements management, how it fits into the project management framework, and discussed the right amount to apply to projects, let's delve deeper into requirements planning.

The Requirements Management Plan

Planning the requirements definition work effort is part of the overall effort to plan the project, and the resulting Requirements Management Plan becomes part of the Project Management Plan. Exhibit 3 shows a list with some of the key planning activities, the sub-processes associated with each, and the final deliverables that are produced. As stated earlier, these deliverables are rolled into the requirements management plan, which in turn, is a subsidiary plan within the overall project management plan.

Requirements Planning Activities and Deliverables Requirements Planning Activities and Deliverables

Exhibit 3 – Requirements Planning Activities and Deliverables

It is helpful to remember that each of these activities and sub-processes should be considered and performed, although not with the same amount of formality. For example, identifying project roles can take place in a formal, facilitated session with cross-functional representation, or it can occur when the project professional informally touches base with a limited number of stakeholders. Likewise, the deliverables may be permanent and stored in a repository, or they can be temporary, a by-product of an informal conversation. In the latter example, the deliverable may be produced on a whiteboard and erased at the end of the discussion.

Clarifying Roles

One of the first tasks in Requirements Planning is completing stakeholder analysis, during which time it is important to clarify the project professional's role and associated responsibilities. Consider the following:

  • The difference between the function of managing the project and that of managing the requirements/ requirements phase(s). Although the same person can certainly manage both functions, they are different and the associated roles are also different. Skills required and characteristics of effective performance differ for each role, so giving thought to each during stakeholder analysis is important. For example, it is even more important for the project manager than the business analyst to have human resource management skills, and it is even more important for the latter to be an expert facilitator.
  • The consultative nature of the project professional's role. In establishing roles and responsibilities it is important to view the project professional as a consultant who makes recommendations, rather than either as an owner or as an order-taker. One of the required skills is the ability to influence without authority. A responsibilities assignment matrix, such as a RACI, can help with this clarification.
  • The importance of distinguishing between requirements management and product ownership is also critical. We need to remember that managing requirements does not mean owning them. When clients are not available, it is rarely in the best interest of the project to continue without executive and business client support. Since it is the sponsor who has a business problem needing a solution, the sponsor needs to assign people who can define in a timely manner what the sponsor wants. The project professional can have input and can certainly make recommendations, but the final decisions and acceptance of the requirements need to rest with sponsors. Therefore it is necessary to clarify the sponsor's role as the ultimate owner, even if the sponsor has chosen to designate a day-to-day project owner.
  • Finally, project professionals need to keep asking why the stated business problem is worth solving and to explain why it's in the sponsor's best interest to provide available resources who can define the requirements that will solve the business problem.

Negotiating the Dates

In all likelihood there will be stakeholders who want to complete the requirements definition planning more quickly than seems reasonable. Because requirements definition is not always perceived as value-added, some stakeholders will attempt to shorten the process. Here's an approach to follow: negotiate not the deadline, but the deliverables. Trying to change the projected date is fruitless without negotiating the scope, which is comprised of the deliverables that will be produced. If the sponsor wants to bargain to reduce the requirements definition time, here are some tips to try:

  1. Make sure your sponsor is aware of the requirements process and/or methodology and why it was chosen. This implies that thought has been given to that requirements approach and that it was chosen with care. For example, a sponsor may have heard of “agile” projects and may want to dictate that your project be done “agilely.” Emphasize the benefits of the chosen approach.
  2. Show the sponsor the deliverable work breakdown structure, which serves as a “picture” of the scope of requirements definition work. Explain why each deliverable is important to the project outcome. Give the sponsor a choice of removing deliverable(s), but for each one the sponsor wants removed, explain the risks and impacts of discarding it. You can also recommend which deliverables to remove. The sponsor will appreciate your understanding of the impacts and your ability to present alternatives and the associated benefits and risks.
  3. Be prepared to quickly re-estimate the effort with the removal of deliverables. You will lose credibility if the planning process drags on with iterations of estimating, reviewing, and changing, without solid agreement.
  4. Be sure to be prepared when meeting with the sponsor. Talk to key stakeholders before the sponsor meeting to understand which deliverables really are negotiable, and which are essential to the end product being delivered. Work with the key stakeholders to obtain as close to a consensus as possible, so that you can present your recommendation neutrally, thus truly representing the client perspective.
  5. Be sure that you absolutely understand the business problem that the sponsor is trying to solve. Any deliverables that do not help in solving the problem should be removed from the WBS. In addition, explain how managing requirements can actually save time. Explain how using requirements management tools, such as the traceability matrix, can save time because it ensures that there is a clear link between a requirement and the business problem being solved. By tracing requirements, we not only help ensure that every requirement adds value and that every approved requirement will actually be produced, but also that scope creep is less likely to occur.

If during requirements planning new deliverables are uncovered, or changes to deliverables are desired, it will be necessary to modify the WBS, create new tasks, re-estimate the amount of time it will take to produce the new or changed deliverable, and discuss what changes in the schedule are required. Negotiating with the sponsor, as described above, is important whenever there is a change. Sponsors typically want to know what every new requirement will cost, so be prepared with estimates when discussing them.

Final Words

Requirements management, whether done formally or informally, is a vital aspect of project management. Without the requirements management plan, the overall project management plan is incomplete. Taking the time to plan and manage requirements will lead to a better end product and increases the chances of having satisfied stakeholders.

In addition, if we revert to requirements not being managed, we can expect to see the cost of projects and defect repair, as well as scope creep, continue to increase. However, if we spend too much time on requirements management, we are at risk of creating a burdensome process that will delay the project. It is important, then, to apply an appropriate amount of requirements management rigor to our projects to ensure that we have:

  • Thought about the approach we will take
  • Identified the requirements definition deliverables
  • Developed a requirements schedule
  • Planned for requirements communications and risks
  • Clarified important roles and responsibilities
  • Communicated our plan to our sponsor, ensuring an understanding of the requirements management plan and its importance.

This care will help all stakeholders in planning their time and encourages their active participation in the project.

References

Ambler, S. (last updated March 3, 2007). Agile modeling. Retrieved on January 7, 2008, from http://www.agilemodeling.com/essays/changeManagement.htm and http://www.agilemodeling.com/essays/examiningBRUF.htm

Davis, A. (2004). Just enough requirements management, part 1. Retrieved on January 7, 2008, from http://conferences.codegear.com/article/32301

Institute for Electrical and Electronics Engineers. (1990). Standard 610.

International Institute of Business Analysis. (2006). A guide to the business analysis body of knowledge, version 1.6. Retrieved from http://download.theiiba.org/files/BOKV16.pdf

Project Management Institute. (2004). A guide to the project management body of knowledge (PMBOK® guide). (2004 ed.). Newtown Square, PA: Project Management Institute.

Software Engineering Institute (SEI's) Square Project updated 5/12/05.

© 2008, Elizabeth Larson and Richard Larson
Originally published as a part of 2008 PMI Global Congress Proceedings – EMEA St. Julian's Malta

Advertisement

Advertisement

Related Content

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.