5

TRACEABILITY AND MONITORING

5.1 Overview of this Section

From the perspective of the PMBOK® Guide – Fifth Edition, traceability and monitoring consist of the activities completed to ensure that requirements are approved and managed throughout the project life cycle. During traceability and monitoring, the traceability matrix and associated attributes are created and applied to help monitor and control the product scope. Approved requirements are baselined and tracked. As new requirements surface, these are documented, added to the traceability matrix, assessed for their impacts to the project and product, and presented to stakeholders for approval. Throughout traceability and monitoring, the status of all requirements is communicated using the communication methods defined and approved within the business analysis plan.

The kind of thinking that is inherent in traceability and monitoring applies to all projects and all life cycles. Thinking about the relationships between requirements and their relationships to other project considerations, such as tests and releases, is critical for ensuring project consistency and completeness. Traceability principles that enable change impact analysis are the basis for confirming fulfillment of objectives and ensuring test coverage. Traceability enables the discovery of missing and extraneous requirements. There is a need to track and monitor completed requirements, no matter what type of life cycle is used for a project or what type of format is used to document the requirements. Traceability should be maintained, at a minimum, for the entire duration of the project, even when someone with a business analysis role is no longer associated with the project.

Formal and comprehensive traceability and monitoring requires up-front effort for setup but only provides benefits when there is an ongoing commitment of effort to maintain it and when it is used and referred to by the stakeholders. Organizations that have identified a need for formal traceability and are willing and able to invest in it are more than paid back for that investment because traceability makes it easier to manage requirements. That said, not every organization or project may need formal and comprehensive traceability. Moreover, some degree of traceability can be achieved in less formal ways and may be sufficient for the work at hand.

While some examples of streamlined approaches to traceability are mentioned, this section primarily provides information that would enable an organization to undertake formal, comprehensive traceability and monitoring in a way that is in alignment with PMBOK® Guide – Fifth Edition principles. It highlights the value that these techniques and the underlying thought processes bring and the risks associated with streamlining, as well as the risks of overuse. Practitioners and organizations can use it as a starting point to consider their own traceability needs and risk acceptance and to determine the optimal amount of traceability and monitoring appropriate for their work.

5.2 Traceability

5.2.1 What is Traceability?

Traceability provides the ability to track product requirements from their origin to the deliverables that satisfy them. Traceability is sometimes qualified as bidirectional or forward and backward, because requirements are traced in more than one direction. Not all projects require the same amount of traceability; therefore, the specific deliverables that will be traced for the project are determined during business analysis planning. Generally, more complex projects require more traceability. A project in a heavily regulated industry or one with numerous components, interfaces, risks, and stakeholders will likely require more traceability than a project without these characteristics.

From the perspective of the PMBOK® Guide – Fifth Edition, traceability includes, but is not limited to tracking the following requirements:

• Business needs (business problems or opportunities), goals, and objectives;
• Project objectives;
• Project scope/WBS deliverables;
• Product design components;
• Product development components;
• Test strategy and test scenarios;
• High-level to more detailed-level requirements;
• Detailed to higher-level requirements; and
• Different types of functional requirements that are related to each other. For example, adding a new customer type requires changes to several business processes that use customer data.

Additionally some practitioners trace:

• Use cases to acceptance tests, as well as to other types of requirements, and
• Models and diagrams to their related requirements.

For projects using an adaptive life cycle:

• Epics or user stories may be traced to features and acceptance tests.
• A Kanban Board may provide some amount of traceability.

  Collaboration Point—Decisions about how the traceability process will be conducted are determined during business analysis planning. Conducting minimal traceability can incur project risks, and using an extensive traceability process can consume a lot of time and require extensive management of the traceability links. The business analyst should work with the project manager to determine how much traceability is appropriate for the project, because traceability impacts the usage of resources and the level of project risk.

5.2.2 Benefits of Tracing Requirements

Tracing requirements provides significant benefits:

• Helps to ensure that each requirement adds business value. Tracing each requirement to the business need, goals, and objectives helps ensure its relevancy. When the requirement helps to solve the business problem, takes advantage of a business opportunity, or meets at least one goal or objective, it is relevant and is an indication that the end product will add value. On the other hand, when the requirement is unable to be traced to a business need, goal, or objective, its relevance needs to be analyzed. In this case, the business analyst should consider such things as:
  • Have the business needs, goals, and objectives been articulated in enough detail? A requirement may be relevant, but there may be an incorrectly stated problem or missing objective.
  • Are there missing requirements? Project objectives with no associated requirements indicate that the objective will not be met. Without defined requirements, the end product, service, or result will not add the value that the organization anticipates.
  • Does a specific project objective belong in the project? When there are project objectives without requirements, the objective is misaligned with the current project, in which case it belongs elsewhere or should be eliminated.
• Helps to meet customer expectations. Traceability provides a means to track requirements throughout the project life cycle, helping to ensure that approved requirements are delivered at the end of the project. For example, a data field on a user interface (UI) is an approved requirement, but if it is not developed, tested, or delivered, the expected data field will be missing from the UI in the implemented solution.
• Helps to manage scope. It is more difficult for requirements that do not add value to make their way into the product, because approval is provided only to requirements that add value.

  Predictive projects provide a better case for formal traceability than adaptive projects; however, the life cycle model is not the only factor that determines the optimal amount of traceability. Other factors include whether or not the business is highly regulated, organizational policies and processes, and the degree to which traceability is actually used.

  Collaboration Point—There is often confusion between project managers and business analysts as to who manages scope. The project manager is responsible for managing project scope while the business analyst is responsible for managing product scope. The process of tracing requirements is a clear example of the involvement that the business analyst has in scope management at the product level. Several models that are presented in Section 4 on Requirements Elicitation and Analysis also demonstrate how the business analyst analyzes product scope while modeling.

5.2.3 The Traceability Matrix

Organizations often trace their requirements using a structure called a traceability matrix. A traceability matrix is a grid that allows for the linkage of product requirements from the source to the deliverables that satisfy them throughout the project life cycle. The implementation of a requirements traceability matrix supports the goal that each requirement adds business value by linking it to the business and project objectives. It provides a means to track requirements throughout the project life cycle, helping to ensure that requirements approved in the requirements documentation are delivered at the end of the project. The matrix also provides a structure for managing changes, thereby helping to manage the product scope.

For formal traceability, a traceability matrix contains a short description of each requirement and facts about the requirements, which are called attributes. Requirement attributes help define key information about the requirement. Each attribute forms a column on the traceability matrix.

The types and number of attributes selected should be appropriate for the needs of the organization and the chosen project life cycle. For example, unless the nature of the project or the organizational policies and processes require its use, a project using an adaptive life cycle may not require the use of a traceability matrix, because a less formal method is generally selected for tracing requirements. Projects following an adaptive life cycle may also collect fewer attributes. Other factors, such as the organizational culture may also influence the formality of the traceability approach. More entrepreneurial organizations may choose a less formal traceability approach.

For projects that use a traceability matrix, the business analyst may leverage the organization's standard traceability matrix template. When there is no traceability matrix template, then the matrix needs to be created as part of business analysis planning.

5.2.3.1 Requirements Attributes

For formal traceability, the business analyst should exercise care when selecting requirements attributes to ensure that the proper type and number are chosen. The business analyst should be sure to choose attributes that will actually be tracked and managed and not overlooked. Care should be taken to ensure that selected attributes do not overlap with information that is tracked and managed elsewhere. When information is duplicated, steps should be taken to ensure it is in sync in all locations.

The organization may determine that some attributes should always be considered, for example, creation date, last revision date, and version number, due to the value these attributes provide in managing and controlling requirement changes.

From the perspective of the PMBOK® Guide – Fifth Edition, typical attributes used in the requirements traceability matrix include but are not limited to:

• Requirement ID, which uniquely identifies each requirement;
• Short textual description of the requirement;
• Objectives:
  • Business need,
  • Business goals and objectives, and
  • Project objectives;
• Product development stage:
  • Design,
  • Build,
  • Test,
  • Implement, and
  • Verify;
• WBS (work breakdown structure), a cross reference to deliverables as identified in the WBS;
• Status, such as active, approved, deferred, canceled, added;
• Rationale for inclusion (why the requirement is important to include);
• Priority (how important the requirement is);
• Owner;
• Source (where the requirement came from);
• Version;
• Date completed;
• Stakeholder satisfaction;
• Stability;
• Complexity; and
• Acceptance criteria.

Organizations commonly use requirements management tools or spreadsheets to trace requirements. Figure 5-1 provides an example of a traceability matrix with attributes from the PMBOK® Guide – Fifth Edition. For some organizations, the traceability matrix that is kept on a spreadsheet becomes the de facto requirements repository.

5.2.3.2 Traceability Matrix Hierarchy

A formal traceability matrix is usually built hierarchically, starting with high-level requirements and filling in the details as the requirement is progressively elaborated. This hierarchy is similar to an outline that is filled in as more detail is known.

There are several advantages to creating a hierarchical grid:

• It provides a logical order for the requirements, one that is not disrupted when new requirements are added. It is clear where each new requirement belongs and whether it is related to another requirement. It also provides a way to organize requirements to ensure that there are no duplicate or conflicting requirements.
• Traceability can be started as soon as the first requirement is defined and detailed, because the requirements are progressively elaborated, allowing for the incremental development of the requirements.
• There is no implied sequence, which enables work to be easily divided up among the team.

The traceability matrix is built hierarchically; therefore, it provides for the evaluation of each new requirement. High-level requirements are evaluated to ensure alignment with their source. As high-level requirements are defined, these are included on the traceability matrix and traced to the business need, project objectives, and business goals. As lower-level requirements are defined, these are evaluated against the higher-level requirements for alignment. The lower-level requirements expand on the details articulated in the high-level requirements, and the progression is displayed easily on the traceability matrix. The matrix also helps to evaluate new requirements against associated high-level and lower-level requirements when they are added to ensure alignment in all directions.

Collaboration Point—Some organizations develop a traceability matrix template as a starting point. During business analysis planning, the business analyst collaborates with the project manager and business stakeholders to determine which components of the template are to be used during the project, which components complete the matrix, and at what point during business analysis is traceability considered to be complete.

5.3 Relationships and Dependencies

The traceability matrix is a tool that supports dependency analysis and impact analysis. Requirements are often related to other requirements; therefore, sometimes a requirement is not able to be satisfied in a solution without the other(s) being present. Dependency analysis is a technique used to discover these dependent relationships. Once analyzed, the set of requirements on the traceability matrix is recorded by grouping dependent requirements together. Some requirements management tools illustrate the dependencies visually by creating traceability trees.

Some examples of dependent relationships are as follows:

5.3.1 Subsets

A requirement may be a subset of another requirement.

Example—An organization may have different types of customers—retail customers and business customers—which are considered subsets or subtypes of a customer. All customers may have some common data, such as customer ID, name, and contact information, in addition to some common processes performed on the common data, such as ordering products. Each subset of customer may have data and processes unique to them. Retail customers may have a frequent buyer program and may allow customers to select preferred pickup times for products they purchase. Business customers may have a tax identification number and a line of credit, and may also be permitted to purchase products that are not available to retail customers. The hierarchical relationships of these requirements are easy to portray in a traceability matrix.

5.3.2 Implementation Dependency

Some requirements are dependent on the implementation of other requirements before they can be implemented.

Example—An organization is interested in developing a new sales report but discovers that some of the data to be included on the new report is not being captured. In this case, the reporting requirements are dependent on additional functional requirements to allow the new data elements to be captured on the customer order entry screen.

5.3.3 Benefit or Value Dependency

Sometimes the benefit of a requirement is unable to be realized unless another requirement is implemented first.

Example—An organization interested in improving wait times for customers calling into their phone reservation center finds out that a requirement to add a new phone line has been identified as a high-priority feature, but unfortunately the existing phone system is unable to accommodate any additional phone lines. This particular requirement's value will not be achieved until a new phone system is implemented.

5.4 Approving Requirements

Organizations and projects vary in how requirements are approved. Some organizations require a formal signoff on a requirements package, such as a business requirement document. In other organizations or for specific types of projects, the approval of requirements may be informal, requiring only a verbal approval.

The approval process is determined, documented, and approved up-front in business analysis planning. Determining the process early on helps to avoid conflicts later when the approvals are being sought. The approval process may include any of the following:

5.4.1 Work Authorization System

The work authorization system defines the process for authorizing work. It may include process steps, documents, tracking systems, and approval levels. The work authorization system is one of many organizational environmental factors that lie outside the control of the project team and therefore constrain the project team's options.

Example—The team prefers less formality, but is constrained by a formal approval process that has been recently introduced to solve the problem of scope creep. In agile/lean organizations, there is sometimes less formality about authorization, yet there is still some norm or informal agreement about what needs to be approved and how and when approval occurs. An agile team may agree that when the team wants to add any user stories, the product owner needs to approve them before they are put on the backlog, or it may decide that the team can add the items to the backlog, in which case the product owner's prioritization of the items becomes the mechanism for approval. Further approvals may be obtained during incremental demonstrations of the working product.

5.4.2 Approval Levels

Authorization levels are part of a work authorization system. Approval levels provide the detail regarding who has the authority to approve new and changed requirements. In absence of a work authorization system or when the current system does not cover requirements approval, the business analyst, project manager, and sponsor determine requirement approval levels in business analysis planning. Tools such as a RACI are helpful in facilitating discussions and decisions about approval levels.

There are different types of approvals. Distinguishing among these different types helps to avoid confusion about who gets to approve what. Some examples are:

• Approval vs. signoff. In one organization, business stakeholders may approve a set of requirements during a facilitated workshop and the sponsor may sign off on the requirements, knowing that the business provided verbal approval. In this example, there is a difference between approval and signoff. The sponsor is designated as the only person responsible for signoff. In another organization, the business analyst, the project manager, all business stakeholders, and the project sponsor are required to sign off on each business analysis deliverable including all requirements documents.
• Reviewer vs. approver. On one project, it was explained to the testers that they would review the requirements and their input was welcome, but they were not authorized to approve or reject requirements. On another project, testers review the requirements and when any are not clear, the testers have full veto power to reject any of the requirements.
• Approval authority vs. accountability. In one organization, business analysts were expected to be responsible for managing the requirements, the project manager was accountable for ensuring that the requirements were managed, and the sponsor was accountable for the end product and, therefore, the requirements of that product.
• Rejection of requirements. It is not always clear who can reject requirements. In some organizations, the power to reject requirements is granted only to those who are permitted to sign off on them. In other organizations, all participants in the requirements process may be provided with veto power, regardless of whether they have been granted approval authority or not.
• Change Control Board (CCB) and approval of changes. A CCB is a formally chartered group responsible for reviewing, evaluating, approving, delaying, or rejecting changes to the project, and for recording and communicating such decisions. The CCB is often the ultimate source for approving requirements when there is a significant scope change beyond the project manager's ability to approve. Approved requirements are then baselined, and changes are proposed through the CCB.

  The CCB may choose to have change requests under a prescribed dollar limit approved by business stakeholders and/or the sponsor, and change requests over the limit approved by the CCB. There are many ways for an organization to use a CCB within the requirements process. The process for the current project should be described and documented in the business analysis plan.

  Collaboration Point—Organizations that use an adaptive life cycle may also have CCBs. When they exist, teams on adaptive life cycle projects and the CCB need to determine an optimal way to interact with each other.

• Expert judgment and the approval process. In addition to the business analyst, stakeholders may be asked to provide their expertise. Subject matter experts may be asked to sit on the CCB periodically or when specific changes arise based on their expertise relating to the proposed change. Their judgment and expertise are leveraged when assessing whether the change makes sense. When requirement changes require the review of one or more experts, this information should be documented in the business analysis plan. Knowing this detail up-front allows the business analyst and project manager to allocate sufficient time to evaluate requirement changes.

5.5 Baselining Approved Requirements

5.5.1 What is a Requirements Baseline?

The requirements baseline is the boundary that contains all of the approved requirements for the project, project phase, iteration, increment, release, or any other part of a project. The baseline provides a mechanism for comparison, thereby allowing the project team to recognize that a change has occurred. All approved work is inside the boundary or baseline. Everything outside the boundary needs to be approved. Once requirements are approved, these can be changed only through the change control procedures defined for the project.

The degree of formality applied to changes outside the baseline varies depending on the project life cycle and the organization's processes for managing change. A project using a predictive life cycle is apt to apply a more formal and complex change control process; a less formal process is used for projects with adaptive life cycles. See Section 5.5.3 (maintaining the product backlog) for more information regarding change in an adaptive life cycle.

5.5.2 Relationship of Requirements Baseline, Product Scope, and Project Scope

The project scope is the work performed to deliver a product, service, or result. The product scope is comprised of the features and functions that characterize the product, service, or result. Requirements describe features and functions of the final product, service, or result for the project; therefore, there is a direct relationship between the number of requirements and the product scope. The more approved requirements there are, the larger the product scope and the project scope.

5.5.3 Maintaining the Product Backlog

Business analysis work is important on projects regardless of whether the project follows adaptive or predictive life cycles. For projects that follow an adaptive life cycle, baselining requirements is performed by maintaining the product backlog. The product backlog is the list of requirements, usually written in the form of user stories. Although not commonly referred to as baselining, the principle is the same for all project life cycles. The backlog may have some large user stories, which when broken down, may include options that are not going to be selected and are not approved. On adaptive life cycle projects, a subset of the backlog is approved for each iteration.

The product owner is accountable for the product requirements, known as features, as well as for making priority decisions based on which requirements or user stories provide the greatest business value. Requested requirements (features) are written up as user stories and added to the product backlog throughout the project. New requirements often surface after a product review at the end of each iteration, but could be requested at any time.

The priority of user stories can change at any time. A requirement thought to be a high priority at the beginning of a project may be changed to a lower priority as the project progresses. On the other hand, the product owner could elevate the priority of other requirements that were originally thought to be unimportant. The business analyst or person performing that role may choose to maintain the status of requirements as the project, release, or iteration is executed. As requirements are added to the product backlog or changes in priority result in the movement of requirements from one release or iteration to another, the changes are tracked and communicated to the appropriate stakeholders as agreed upon in the communication plan, either formally or informally.

5.6 Monitoring Requirements Using a Traceability Matrix

Once the requirement attributes are determined, the traceability matrix created, and requirements approved and baselined, the requirements are monitored throughout the project life cycle. At this point, every detailed requirement should align with a business requirement. Business requirements are discussed in Section 2 on Needs Assessment.

Projects with an adaptive life cycle that use a traceability matrix may build the matrix incrementally in a consistent manner as details are elicited and analyzed.

5.6.1 Benefits of Using Traceability to Monitor Requirements

Monitoring requirements throughout the life cycle using a traceability matrix or similar structure helps to ensure that:

• More detailed requirements that surface are linked to the baselined requirements. As the requirements are progressively elaborated and additional details surface, the relationships are progressively elaborated. Every detail relates back to a higher-level requirement.

  Example—An organization has a baselined requirement to support multiple customer types. Through business analysis requirement workshops, it is uncovered that there is a difference in how complaints are handled for each customer type. Detailed requirements emerge for a concierge service for business customers, which trace back to the initial requirement.

• A complete set of baselined requirements has the detail needed to build the feature or set of features. When a high-level requirement exists with no associated detail requirements, this points to an area needing further requirements elicitation to uncover the details.
• Supporting business analysis work products are created for each baselined requirement when needed.

  Example—An organization decides to create a concierge service for business customers. Process flows are developed to demonstrate the various interactions between the business customer and the concierge service. Training documents are developed to help staff address customer types and the associated processes.

• Work products created across phases, such as design and test documents, are created for each approved requirement.

  When there is a requirement with no associated work product, there is a risk that important components may be missed. For example, in a software development project, approved requirements need to be designed, built, tested, implemented, and verified, so that appropriate work products, such as the physical database design and other design documents, programs, and test cases can be developed.

  Requirement relationships are monitored to their related work products to help ensure that gaps between the approved requirement and what has been built and tested are not missed. When gaps are identified, the business analyst should:

  • Cancel or defer the approved requirement, or
  • Create the missing work product.
• Scope creep is prevented. PMI defines scope creep as the uncontrolled expansion to product or project scope without adjustments to time, costs, and resources. Projects using a predictive life cycle with many work products can monitor requirements relationships and also review each work product that is created throughout the project to ensure that it links back to an approved requirement.

  For example, when requirements are included on a traceability matrix, it is easier to see this linkage and spot missing requirements. By routinely comparing work products to requirements on the traceability matrix as they are created, gaps can be questioned and appropriate action taken.

  Example—A developer working on a user interface for an order entry screen decides to exceed customer expectations by highlighting the data fields that the customer changes to yellow to make them stand out. These changes are programmed without obtaining approval and are not discovered until user acceptance testing. The sponsor is not happy with the change, which ultimately results in rework, cost, and schedule overruns. Had test cases been created at the point of design or development, these changes could have been checked against the approved requirements and brought to the sponsor for approval. In this case, the request would have been declined because the sponsor knew that highlighted text is problematic for clients who use mobile devices to place orders.

  Product owners on projects using an adaptive life cycle manage scope creep through regular reprioritization of the backlog. For adaptive projects, traceability matrices may be used to help manage scope creep or less formal techniques may be used to achieve the same level of thought.

5.7 The Requirements Life Cycle

The status or state of a requirement is a common attribute on the traceability matrix. The state of a requirement characterizes where it is in the requirements life cycle. The requirements life cycle, not to be confused with the project life cycle, represents the various phases that a requirement moves through as it is maintained across the project.

During business analysis planning, the list of requirement states is defined for the project. When an organization uses a requirements management tool, the requirement state is maintained automatically by the software after the business rules for determining state changes are configured within the tool. Without a requirements management tool, the business analyst maintains the states manually.

An authorizing body influences the requirement state when making decisions on requirements, such as:

• Approving a requirement but postponing it to another project, iteration, or project phase;
• Deferring a requirement to some unspecified future project, iteration, or project phase;
• Replacing an approved requirement that has not been started with another requirement;
• Canceling an approved requirement;
• Rejecting a requested requirement; or
• A combination of the above. For example, the authorizing body could approve one part of the requirement but defer another part.

Figure 5-2 is a state diagram that provides an example of some common requirement states and the life cycle that may be followed.

The actual states that a project tracks can vary considerably between, and sometimes within, organizations. For each project, within organizational constraints, a decision is made concerning which states the organization is willing and able to track and manage.

The requirement state is used when reporting requirement status to project stakeholders. For example, the state is required in order to report how many requirements are documented and how many are approved, deferred, or rejected in order to provide a fuller understanding of the conditions of the requirements on the project at any given point in the life cycle.

5.8 Managing Changes to Requirements

A change to a requirement may be proposed at any time during a project. Who can propose changes and how those changes are proposed are defined in the business analysis plan. Although suggested changes may be initiated verbally, these should be recorded for tracking and management purposes.

Change requests are a part of the overall change control process. The PMBOK® Guide – Fifth Edition defines a change request as a formal proposal to modify any document, deliverable, or baseline. When the change request template is defined and maintained as an organizational process asset, the project team is required to use the approved template on the project. In cases where a template is not defined, the template needs to be created as part of business analysis planning. Some project life cycles use an informal change control process and, therefore, a less formal proposal is acceptable, for example, discussing the change.

The change control process defines how changes are submitted. For formal change control, change requests are submitted manually or as part of an online process. The business analyst monitors change requests and takes an active role in assessing the impacts of a proposed change. A change request process defines the information required to be gathered before a request can be considered for approval. The business analyst may be required to collect information based on the level of effort to make the change, cost impacts, risk impacts, and impacts on completed work or existing approved requirements. Eventually, every logged change request should be approved, deferred, or rejected by the change-approving body in accordance with the process defined in the business analysis plan. The change process may require a recommended turnaround time that the project team needs to adhere to when assessing a proposed change.

5.8.1 Change Management as it Relates to Business Analysis

Within change management, the role of the business analyst is to maintain the integrity of the requirements and the associated deliverables and work products and to ensure that each new requirement aligns with the business need and the business and project objectives. The key benefit of a requirements change process is to allow for changes to documented requirements while reducing product and project risk, which often arises from making changes without consideration to the overall impact to the product and project, as well as considerations related to dependencies.

The applied level of change management is dependent upon many factors, such as the application area, the organizational culture, the organizational process assets, the complexity of the specific project and end result, contractual requirements, the project life cycle, and the context and environment in which the project is performed.

Project managers and business analysts both have an interest in change management. The project manager is concerned with all things associated to project scope. Approved change requests may require adjustments to the project management plan and other project documents, cost estimates, activity sequences, scheduled dates, resource requirements, and the analysis of risk response alternatives related to the project; therefore, the project manager is very involved in change management activities. The business analyst is interested in understanding the impacts to product scope, such as how the change request will impact documented requirements, existing and approved business analysis work products (e.g., process flows and models), and any product components that have been built and tested from existing approved requirements.

Collaboration Point—Assessing the impacts a proposed change will have on project and product scope requires the collaborative efforts of both the project manager and business analyst. It is important for the business analyst and project manager to have frequent communication about the proposed changes and their disposition.

For projects using an adaptive life cycle, the team determines the details for most of the requirements on a just-in-time basis. Most details are elicited during the iteration or increment in which the requirement or user story will be delivered. Because requirements details emerge along the way, product owners and their teams expect changes during an adaptive project. The product owner regularly reprioritizes what is to be delivered, usually at the start of a new increment. Since adaptive projects rapidly deliver small increments, while changes tend to be frequent and each change is often small, it is more likely that small changes will be assessed on an informal basis. Changes that add value can be accepted and prioritized.

The approaches to change management taken by projects using adaptive life cycles are evolving. Variations for change management on adaptive projects include, but are not limited to, discussing changes and adjusting the backlog or Kanban board based on the discussion; managing change simultaneously from a long-range, mid-range, and immediate range perspective; or using automated tool support to streamline a more formal change management approach.

5.8.2 Change Control Tools and Techniques

Manual or automated tools may be used to manage change requests and the resulting decisions. These tools may already be in place within the organization. When a change control tool is being introduced on a project, the needs of all stakeholders involved in the change control process should be considered.

Collaboration Point—The business analyst and project manager need to work together to ensure that both business and technical stakeholders’ needs are met when defining the change control process and the supporting tools.

5.8.2.1 Configuration Management System (CMS)

Configuration management helps to ensure the product or service being built conforms to its approved requirements. It provides a process to verify this conformance, document changes, and report the status of each change throughout the project life cycle. It includes documentation, a tracking process, and defined approval levels necessary for authorizing changes. It enables managing changes to aspects of a product in the context of the entire product as well as the context of other products on which it depends or which depend upon it.

Configuration management for business analysis ensures that (a) the requirements and requirement-related documents, such as, models, traceability matrix, and issues list, are stored where they can be easily accessed by project stakeholders and are safeguarded from loss; and (b) access to previous versions of documents is available, when needed. A business analyst may achieve these objectives with a CMS, a requirements management repository, or with a wiki platform. When using less formal tooling, such as a wiki, the CM goals will not be achieved without a process on how and when to access and write to the wiki. The process for storing requirements-related information and the tools to support the project needs are determined and agreed upon in business analysis planning.

5.8.2.2 Version Control System (VCS)

A version control system (VCS) tracks the history of revisions, but not always those that are related to software. A VCS is like a baseline in that the original code or work product is established, and changes to that code or work product are tracked. A VCS falls under the umbrella of a CMS and is one of the many processes that comprise configuration management.

Although often associated with software source code, a VCS can be used for managing business analysis documentation. When the requirements documentation is extensive, a VCS may be appropriate. Project teams need to decide whether or not previous versions of requirements and models are required. If this is a necessity for the project team, a VCS can help support this requirement.

Version control ranges from a simple system, for example, using the document's file name to reflect a date, time, and version number, to a more formal approach where documents are maintained by a tool that requires that documents be checked out of a library, locked by the system during the editing process, checked back in with mandatory comments explaining the changes made, and versioned automatically by the tool. When version control is required for the requirements documentation and when a version control system will be used should be noted in the business analysis plan.

5.8.3 Impact Analysis

When a requirement change is proposed, it is necessary to complete an impact analysis to evaluate the proposed change in relation to how it will affect other requirements, the product, the project, and the program. Impact analysis is the work performed to assess a proposed change, which includes identifying the risks associated to the change, the work required to incorporate the change, and the schedule and cost implications. A key benefit of completing an impact analysis is that it allows for changes within the project to be considered in an integrated fashion, thereby reducing project and product risk, which often arise from changes made without consideration to the effect on the program, project, and end product.

Sections 5.8.3.1 through 5.8.3.5 describe a formal approach to impact analysis. Projects using an adaptive life cycle may use an informal approach to assess impacts and devise a course of action based on the value of the change along with its impacts. Impact analysis includes, but is not limited to, the following:

5.8.3.1 Impact on the Requirements Baseline

The business analyst reviews the change request to determine whether the request is a change to an existing requirement, a new requirement or set of requirements, or whether the change provides further detail of the same requirement. Using the traceability matrix, the business analyst identifies the requirements impacted by the change within the matrix. The business analyst can then quickly assess the affected relationships by impact, roughly quantifying how big or small and complex the change may be.

5.8.3.2 Impact on whether a Proposed Change Conflicts with Other Requirements

The business analyst assesses the proposed change against the baselined requirements or requirements residing in the requirements backlog. The business analyst is looking for situations where requirements could be in conflict with one another. When implemented, a requirement that is in conflict will cause another requirement to break or not be implementable. Conflicting requirements may break solution components that are already implemented. The business analyst analyzes the change request against the requirements baseline and existing solution components and notes areas of potential conflict.

When requirement conflicts arise, the business analyst facilitates a resolution to the conflict and may schedule a requirement session to discuss alternatives and reach consensus. It is very important to ensure that all impacted stakeholders are represented when sorting through conflicts. A proposed change request that is identified as being in conflict with existing product features, when approved, will overturn or override existing approved functionality. The business analyst has an important role to preserve the integrity of the requirements baseline, solution components, and existing features already implemented to ensure a proposed change adds the value that the organization expects.

5.8.3.3 Impact on Business Analysis

When conducting impact analysis, the business analyst assesses the impact that the proposed change will have on business analysis work that is currently in process, including work that has been completed and approved. The business analyst also considers how far along the solution is in the development cycle and works with the project team members accountable for product development to obtain input regarding how the proposed change, if approved, impacts the work completed to date.

The business analyst may need to replan current business analysis activities when the proposed change is deemed higher in priority than requirements that are currently in process. An adaptive project life cycle is used for some projects, which is well-suited for accommodating change.

Aside from assessing the impacts to the current business analysis activities, the business analyst considers any updates that are required to existing business analysis documents, because these deliverables are often the input to the project team members who perform work after the business analyst. These documents need to accurately reflect the requirements for the product and solution at all times in order for the development teams to produce the correct end product.

Interim documents or work products may need to be updated, but usually, these are created for a one-time use (e.g., a model that is built to elicit requirements from a specific stakeholder group). When the work products are not to be reused or referenced by project teams, then the business analyst does not need to spend time reviewing and revising them.

Process flows, use cases, business requirement documents, software requirements specifications, and user stories are examples of documents that may need to be revised whenever a change is approved. When the business analyst is conducting impact analysis, the time needed for revising the required business analysis documentation should be estimated in the event that the proposed change is approved.

5.8.3.4 Impact on Project Management

Even the smallest change needs to be understood in terms of the impact to the project. Approved changes may impact one or more subsidiary plans within the project management plan as well as in-process work that the project manager has been monitoring and controlling.

Maintenance of the project management subsidiary plans is outside the scope of business analysis, and not all plans may be impacted. The following list represents plans that a project manager may need to address whenever a change request is approved:

• Scope management plan,
• Business analysis plan,
• Schedule management plan,
• Cost management plan,
• Quality management plan,
• Process improvement plan,
• Human resource management plan,
• Communications management plan,
• Procurement management plan,
• Risk management plan,
• Stakeholder management plan,
• Scope baseline,
• Schedule baseline, and
• Cost baseline.

While adaptive projects tend to have fewer plans, they very often have a product roadmap, which shows, at a high level, what is planned for release over the course of the project iterations.

Collaboration Point—The project manager and business analyst can work together to assess project impacts. The time, cost, and risk impacts are reflected in the impact analysis to properly scope the level of effort associated with the proposed change. The project manager assesses project impacts, and the business analyst assesses impacts to the product. Product impacts may include changes to the business analysis deliverables required to build the end product, changes to scheduled business analysis activities, or changes to solution components in process or already implemented. To properly assess both the project and product impacts of a proposed change, the project manager and business analyst should work together, because each provide a perspective and level of knowledge that, when contributed jointly, will properly assess the size, cost, schedule, and risk impacts associated with the proposed change.

5.8.3.5 Recommending a Course of Action

After analyzing all of the impacts of the change and understanding the scope, risk, schedule, and cost implications, the business analyst assembles the results of the analysis. The business analyst recommends a course of action and includes this recommendation in the assessment. Some organizations look to the project team to provide more than one alternative along with the pros and cons, assumptions, risks, etc. for each alternative. Each impact assessment may result in an abbreviated form of a business case to speak to the value of the change. The purpose of the recommendation and supporting analysis is to provide those responsible for approving the change with all the information required to make a sound decision.

The process for approving changes was determined and approved up-front in business analysis planning. When the organization uses a CCB, the impact assessment is submitted for consideration. The business analyst adheres to the agreed change approval process for the project.

Once a decision is reached, the business analyst proceeds to address the outcome. The following courses of action are possible after the proposed change is evaluated:

• Change approved. The business analyst completes the necessary updates to the impacted business analysis deliverables. Planned and in-process business analysis activities are adjusted when impacted.
• Change deferred. The business analyst documents the decision along with a rationale for the decision. When a proposed date or product release is decided upon, this information is noted and reflected in the appropriate plans to ensure the change is addressed at the requested future date.
• Change rejected. The business analyst documents the decision and provides a rationale for the decision in the appropriate plan. Unlike the action for change deferred, there are no future date reminders established in the plans, because this work will not occur.
• More information required. Despite best efforts to ensure that the impact analysis is thoroughly constructed, sometimes the CCB or approval team requests more information. Conditions in the business may have changed since the project was first approved, or the CCB may now be considering different solutions or working from new data that was unavailable previously. This in turn involves another round of elicitation and analysis, an update to the impact analysis, and a resubmittal to the authoritative body considering the change.

Regardless of the decision made by the authorizing body, the business analyst has the responsibility of communicating the outcome of the change discussion with the project stakeholders. Interested stakeholders need to understand why a change was deferred or rejected and the rationale for the decision as much as they have a need to hear about the approved changed requests.

Projects using an adaptive life cycle often arrive at change decisions during incremental demonstrations of the working product. In iterative and adaptive projects, change is ongoing and emergent learning is often how the right product that maximizes value is identified. As in all projects, product owners in projects with an adaptive life cycle still need to think about the impact of the change on the product and project and to consider alternatives. Again, the degree of formality and the amount of documentation for the change decision process depends upon the requirements of the organizational policies and processes or external regulations.

5.8.4 Controlling Changes Related to Defects

Not all proposed changes are requests for new features or new requirements. Some changes are requests to fix defects that are identified in the solution. Such defects may be raised after formal or informal audits (e.g., inspections or walkthroughs) or may surface when stakeholders interact with the solution. Because a defect is a deviation from a requirement, the business analyst stays involved in the defect repair process by monitoring the repair or the replacement of the nonconforming solution component. Although the requirements-related documentation is not impacted, it is the component that is being modified to be aligned with the approved requirement. Defects in projects following an adaptive life cycle may be identified during incremental demonstrations of the working product and defect management may be informal. For more information on controlling changes related to defects, see Section 6 on Solution Evaluation.