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:
Additionally some practitioners trace:
For projects using an adaptive life cycle:
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:
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:
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:
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:
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.
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:
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.
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.
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:
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:
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:
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:
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.