I still don't have time to manage requirements: My project is later than ever

Abstract

Many of us know that poor requirements management is a major source of failed projects. PMI's Pulse of the Profession^® (2014) found that 37% of all organizations reported inaccurate requirements as the primary reason for project failure. We know that if we do not get the requirements right, we will not get our projects right. But, how do we tell our sponsors that managing requirements is more than a box on our Work Breakdown Structure (WBS) and a line item on our list of activities? For those of us who have been given imposed deadlines that often seem arbitrary and unreasonable, managing requirements is the last thing on our minds. When the stress of trying to complete projects with tight deadlines seems overwhelming, it is more important than ever to ensure that we deliver a usable product. This paper addresses the need for requirements management, even when we think we do not have time. It explains what requirements management is and why it is essential to project success, provides tips on using time-saving techniques that actually reduce project time, and describes how to influence your business stakeholders about the need for requirements management.

Why We Need to Manage Requirements

According to PMI's Pulse of the Profession^® (2014) study, poor requirements management is the second most common reason for project failure. In addition, 87% of organizations surveyed recognized that improvement is needed. Nevertheless, as important as requirements management is, the study also found that:

• Only 49% of organizations have the resources in place to do requirements management properly.
• Only one-third of organizations’ leaders value requirements management as a critical competency.
• Only 47% of organizations have a formal process to validate requirements.
• 51% of project and program dollars are wasted due to poor requirements management.
• 47% of unmet project goals were due to poor requirements management.

Common Misconceptions

There are many misconceptions about requirements management, which explains in part the reluctance by some organizations to formalize it. To some, the term “requirements management” conjures up images of an overly-burdensome set of processes and templates, as well as a mountain of paperwork. It is not surprising that the industry is filled with common misconceptions. Here are just a few:

1. “I'm on an agile project so I don't need to manage requirements.” We often hear that requirements management is only for more traditional projects but not on agile projects. Requirements need to be managed, regardless of the type of project, and usually are on most successful projects. Even if we object to the term “management,” lots of it takes place on agile projects. We manage the product backlog (requirements) by prioritizing and reprioritizing the list of requirements (user stories). We plan releases and iterations. We monitor and control through daily standups, burn-down, and burn-up charts. We manage changes through the use of time boxing and by adding new requirements (user stories) that surface to the product backlog. Quality is planned when we add acceptance criteria to the requirements (user stories), and quality processes are completed through product demos and retrospectives. Many requirements management processes are built into agile methods.
2. “Changes on agile projects are not managed.” Indeed, changes are managed on agile projects. Rather than being handled haphazardly and arbitrarily, requests for change are written up as user stories, put on the product backlog, and prioritized by the business in the role of the product owner.
3. “Requirements management just adds overhead to my project.” In fact, when requirements are managed projects are less chaotic, more gets accomplished with less cost, and the end product tends to be more useable. Techniques such as traceability and version control reduce risk, keep the team focused, and save time by preventing scope creep and avoids having to rewrite artifacts that have been inadvertently destroyed.
4. “Business analysis is about gathering and documenting requirements. How hard can that be?” Many project managers mistakenly believe that business analysis is easy and can be done quickly. As we will see in the tables below, business analysis and requirements management are complex, and many project managers are surprised at the extent of the work involved.
5. Gathering requirements is easy. All we need to ask are the ‘W’ questions: “who, what, when, where, and why.” However, elicitation requires finding out the real needs behind the stated wants. It requires knowing what questions to ask, listening to responses, synthesizing a great deal of information from a variety of stakeholders, and asking more questions. It is like detective work. Stakeholders rarely provide their requirements in a straightforward manner, so it is up to the business analyst to determine which questions to ask and confirm what they have heard. Using another example, if a general contractor who builds houses asked only those “W” questions, the real requirements for the completed house would never surface, and the homeowners would be decidedly unhappy.

Requirements Management Overview--So Much to Manage!

Project management

Project management focuses on the project.

A Guide to the Project Management Body of Knowledge (PMBOK^® Guide) – Fifth edition. describes project management as “The application of knowledge, skills, tools and techniques to project activities to meet project requirements” (PMI, 2013, p. 5). This definition, though, raises questions about whether requirements management is part of project management or a separate discipline. In this paper we will show how each is distinct yet interconnected, and we cannot be successful unless both practices are completed effectively. Well-managed projects operate within the constraints of scope, time, and cost, referred to as project baselines or approved starting points. These baseline constraints help the project manager identify changes and keep the project on track.

Why is it hard to manage projects?

Rarely do projects go as planned. A myriad of issues and conflicts usually arise. Business stakeholders disagree on what they want, technical resources argue over which design is best, project schedules are delayed, and often the testing team does not have enough time for thorough testing. Other teams working on different products or different parts of the same product can destroy what was already completed, and unauthorized functionality, known as scope creep, slides almost unawares into the project causing conflict about whether it was part of the original scope. Even the most robust risk register and mitigation plan cannot prevent those events that can derail the project.

Requirements Management and Traceability

Requirements management focuses on the product, service, or end result of the project and is defined as “the discipline of planning, monitoring, analyzing, communicating, and controlling requirements.” (PMI, 2014).

Project management typically focuses on the project: creating baselines and managing project constraints, communicating and resolving project issues, and getting the required resources to work on project activities. Business analysis typically focuses on the end product (solution) while requirements management focuses on activities related to building the end product.

The PMBOK^® Guide describes requirements activities, as the process “of determining, documenting, and managing stakeholder needs to meet project objectives” (PMI, 2013). In other words, while the project manager needs to deliver the end product, the business analyst needs to ensure it is usable and meets stakeholder needs when it is delivered to those stakeholders.

Well-managed requirements are documented and traced. Traceability is a structured way to keep track of requirements. According to the IEEE SWEBOK (2014), “a requirement should be traceable backward to the requirements and stakeholders that motivated it ... and forward into the requirements and design entities that satisfy it.” (pp. 1–14). Although some practitioners view traceability as unneeded bureaucracy, it is the premier requirements management technique. It actually saves time. Without traceability, scope creep is usually rampant, surprises are common, defects are the norm, and the resulting rework often extends the project schedule and increases the budget. Exhibit 1 provides a tip from A Practitioner's Guide to Requirements Management (Larson &Larson, 2013, p. ):

Exhibit 1: Traceability tip

Traceability is beneficial. It helps ensure that every requirement:

• Adds value. By tracing each requirement to its origin it ensures that each requirement is helping to solve “the business need for which the project was undertaken.” (Larson & Larson, 2013, p. 44)
• Belongs in the approved scope. Tracing to the source helps ensure that no extraneous requirements sneak into the project contributing to scope creep.
• Is actually delivered. Tracing each developed artifact to the approved requirements helps ensure that what was approved in the beginning of the project was actually delivered when the product was implemented.

Why is it hard to manage requirements?

Requirements elicitation is rarely straight-forward. Stakeholders bring us their solutions which may or may not solve their business problems. Sometimes stakeholders think they know what they want but have not thought of the myriad impacts to the business processes, to the organizational culture, or to the existing technology. Sometimes they understand their needs but have difficulty articulating their requirements.

There are a variety of techniques which help us ask the right questions, but these techniques need to be learned and practiced. For example, business process modeling, data modeling, use case modeling, and prototyping provide a structure for asking the right questions. These techniques help the business stakeholders understand the current state and help visualize their future state. However, the business analyst must learn these models and the appropriate modeling conventions. They must also learn how to apply the models appropriately, how to take the stakeholder responses and represent them graphically in the models. Rarely can a project professional with little experience master this complexity. Once mastered, however, eliciting and modeling requirements iteratively provides a fool-proof way to get those hidden requirements, which often derail our projects.

Comparing project management and requirements management

There are many similarities and differences between managing the project and managing requirements, as outlined in Exhibit 2.

Exhibit 2: Comparison of project management and requirements management

The requirements management plan

The requirements management plan (RMP) is a key document or set of documents on larger projects for both project management and requirements management. As noted in the table above, it is one of the subsidiary documents in the project management plan (PMI, 2013, p. 89) and guides all of the requirements activities. The RMP puts structure around our business analysis effort and provides guidance for our work. The RMP helps answer a number of questions, including:

1. What business analysis work products will we produce (e.g., user stories, prototypes, use cases, acceptance criteria)?
2. What activities are required to produce these work products, and how long will it take?
3. How are we going to trace requirements, baseline requirements, or manage changes to the requirements?
4. What kind of documentation is needed? How formal do we need to be? How long do we need to keep it?
5. How are we going to identify stakeholders to define requirements or complete the testing?
6. How are we going to communicate with the product-related stakeholders?
7. How are we going to track our requirements activities against plan?

Exhibit 3 shows the complexity of subsidiary plans in both the project management plan and the requirements management plan (Larson & Larson, 2013, p. 37). Its intent is to show the relationship between the RMP and some of its subsidiary plans, and the project management plan and some of its subsidiary plans, rather than a complete mapping of all the subsidiary plans.

Exhibit 3: Complexity of the subsidiary plans

A comparison of requirements management and business analysis

Although sometimes used synonymously in casual conversation, there is a difference between business analysis and requirements management. Like project management, requirements management “is a discipline or practice. It uses inputs and outputs, tools, and techniques, processes and activities, but just for activities relating the end product. “Requirements management includes the planning, monitoring, analyzing, communicating, and managing of those requirements.” (Larson & Larson, 2013, p. 36). Requirements management activities fall within the boundaries of a project; that is, we manage the requirements of the end product that is produced as a result of a project.

Business analysis is defined as “the application of knowledge, skills, tools, and techniques to determine problems and identify business needs; to identify and recommend viable solutions for meeting those needs; to elicit, document, and manage stakeholder requirements to meet business and project objectives and to facilitate the project team with the successful implementation of the product service, or end result of the project or program.” (PMI, 2014, Introduction). Unlike requirements management, business analysis extends beyond the project. It begins before project initiation with a needs assessment for a program, a portfolio, for an entire organization or any of the business stakeholders and comparing those benefits to the cost of developing, operating, and maintaining the end product, the business its parts, such as a division, business unit, etc. The needs assessment often includes a feasibility study to determine if it is worthwhile for the organization to undertake a specific initiative. A high-level benefits analysis identifies the feasibility and reveals whether or not to move forward. This recommendation is based on such things as whether or not the desired initiative makes financial sense and if it will be accepted and supported by the organization once implemented. If the organization undertakes the initiative, a project is initiated by a sponsor and a project manager is assigned.

Another part of business analysis outside the project boundaries includes the evaluation of the end product after implementation. The business analyst compares the end product against the approved requirements to determine if what was approved was actually delivered. As well, the business analyst coordinates the evaluation of the product to see if it achieved the stated benefits. Since the benefits are best articulated by the business stakeholders, the role of the business analyst is to ensure that the evaluation takes place, rather than to own the benefits themselves.

A major difference between requirements management and business analysis is that the former is concerned with the delivery of a product that is useable within the project constraints of time, cost, and scope. Business analysis, on the other hand, is concerned with understanding how the solution will change the way the organization functions; that is, how the organization will be affected by the change. It is concerned with assessing how extensive the change will be and minimizing the impact of the change by helping the organization understand the change and its effect on current business processes and systems.

Exhibit 4 highlights the similarities and differences between requirements management and business analysis.

Exhibit 4: Comparison of requirements management and business analysis

Managing Changes

Impact analysis

When change requests are received for any changes to the product requirements, they must be evaluated to determine the impact on the product, as well as the impact to the project and to the organization. Here are some high-level steps that help manage changes:

1. Start with the traceability matrix to determine how the request solves the business problem and helps the organization meet its goals. If the change does not help solve a problem or meet an objective, it does not belong in the project. Use the traceability matrix to help determine where the change belongs. Because the traceability matrix is structured as a hierarchy, high-level requirements are documented as soon as they become known. Detailed requirements are added through the process of progressive elaboration.
2. Analyze the impact of the change on the affected business processes. Changes usually affect the way people do their jobs, even if the requested change is small. It is essential for business stakeholders to understand that a change might affect not just their processes, but those in other business units. For example, a requested change in a sales promotion system might affect how stakeholders place orders, how items are picked in a warehouse, how stores stock items, etc.
3. Analyze the impact on the organizational culture, if appropriate. Changes requested by one group of stakeholders might be rejected by another. It is important that key stakeholders agree on the change. Even when there is a signed approval for the change, some stakeholders might react negatively and try to derail the effort.
4. Analyze the impact to the project. Using the project management plan and its subsidiary plans, determine the impact to each of the plans. For example, if the change relates to new functionality, what additional deliverables, associated tasks and estimates are needed? What is the priority of this change? How will the baselines be affected? What additional risks surface? Will additional stakeholders be involved? How will the change affect the quality plan and testing? Will additional resources be needed? These are just a few of the many questions that need to be answered before moving ahead with the change.
5. Obtain the benefits from the requestor and the costs from the development team before recommending whether or not to proceed with the change. If requested to do so, accompany the business stakeholder who requested the change to the person or group who will make the go/no-go decision.

Configuration management and version control

Configuration management is used mostly on complex projects to ensure that changes do not adversely affect the end product or any component of that product. When complex products are being developed, it is easy to change one component without realizing the effect on another component. Configuration management systems provide a structure to ensure that changes are managed; that they are implemented purposefully; and that documentation, which often does not get updated with changes, remains current.

Version control tracks product versions. It is commonly used with software development. For example, when a piece of software needs to be tested, it is removed from a “library,” tested, and replaced in the library. If testing reveals defects and those defects are corrected, it is important for other teams who might be developing or testing interfaces to know which version they are using and if a newer version is available. In other words, version control is helpful when multiple teams are developing and testing the same system or other interfacing systems.

Recommending the right amount of requirements management

So much to do—so little time!

If this sounds like too much work, too bureaucratic, or a waste of time when we could be spending that time actually delivering results, think again. Requirements management in and of itself does not cause work. Requirements management can actually save time and money be avoiding unnecessary rework and scope creep. Even projects using agile methods require discipline to be effective. Some of that discipline is the use of requirements management. Requirements management techniques and processes include: developing the release and sprint plans; prioritizing user stories in the product backlog; adding changes to the product backlog in the form of new user stories; behavior-driven and design-driven testing, and using acceptance criteria to determine when the user stories are complete.

The formality required does not mean that changes are not welcome or that the team must stick to the plan, nor does it mean that there is too much paperwork. Formality should not imply bureaucracy or wasted time. The key to productivity is to know how much requirements management to apply to our projects, since we only want to apply the minimum necessary to keep our requirements activities on track.

In general, we should apply less requirements management to projects that are smaller, less complex, with fewer cross-functional stakeholders, fewer business processes, and fewer existing systems/systems interfaces that require changes. Just enough and no more. The type of requirements management depends on such things as the type of product being developed (more management where human lives are at risk than for an internal web page); the location of key stakeholders (more management for geographically dispersed stakeholders speaking different languages); the processes and templates in use at the organization (some internal governance processes require more discipline); and, in a highly regulated environment, and the approach (agile or waterfall) used. “One set of processes and templates rarely fits all efforts.” (Larson & Larson, 2013, p. 185).

The need to influence

Some of us find ourselves in organizations with a one-size-fits-all requirements management process that we feel is too burdensome for our particular projects. On the other hand, some of us find that there is little discipline and we would like to see more. When we see such gaps, we serve our organizations best by recommending the right amount of requirements management for our projects. This type of consultative influence is extremely effective. In order to influence through consultation it is necessary to build trust, be prepared, and have the courage to not only recommend what we feel is the right thing for the organization, but also justify the many challenges we can expect to receive from those who have a vested interest in maintaining the status quo. Building trust means building bridges, and as Cohen and Bradford suggest, even if you do not succeed in having your recommendation accepted, “Don't burn any bridges. Colleagues come back” (Cohen & Bradford, 2005, p. 218). To be thoroughly prepared, we must document the problems with the current method of managing requirements (number and types of defects, time spent documenting requirements and maintaining requirements documentation, which elicitation and modeling techniques added value, which did not and why/why not, etc.), develop alternatives, articulate the benefits of changing the requirements management process, and anticipate and be able to answer questions that might arise, particularly from those who developed the process and have a vested interest in its use and success.

Summary

In this paper we presented several misconceptions related to requirements management; compared project management and requirements management showing how they fit together; highlighted the similarities and differences of requirements management and business analysis; discussed the importance of requirements modeling to the ability to elicit detailed requirements; described the components of a requirements management plan; the importance of traceability; how to manage changes using the techniques of impact analysis, configuration management, and version control; and finally, described the importance of influencing the organization to adopt the right amount of requirements management.