1

 

INTRODUCTION

1.1 OVERVIEW AND PURPOSE OF THIS GUIDE

The PMI Guide to Business Analysis, referred to here as the guide, is intended to serve the needs of organizations and business analysis professionals by providing practical knowledge and good practices needed to contribute to portfolio, program, project, and product success and support the delivery of high-quality solutions. This guide is intended to enable business analysis to be effectively performed regardless of the project life cycle, whether a predictive, iterative, adaptive, or hybrid approach is used, and provide guidance for business analysis regardless of the job title of the individual performing it. This guide:

• Defines what the work of business analysis is and why it is important;
• Describes the competencies, processes, tools, and techniques needed to effectively perform business analysis tasks and activities;
• Defines concepts related to business analysis that can be applied consistently across all product and project life cycles, product types, and industries to deliver successful business outcomes within portfolios, programs, and projects;
• Highlights collaboration points between those who perform business analysis activities and other roles that business analysts typically need to work with collaboratively; and
• Provides and promotes a common business analysis vocabulary for organizations and business analysis professionals.

According to PMI's Pulse of the Profession^® In-Depth Report: Requirements Management: A Core Competency for Project and Program Success [1],¹ 47% of unsuccessful projects fail to meet original goals due to poor requirements management. In the 2017 Pulse Report: Success Rates Rise—Transforming the High Cost of Low Performance [2], 39% of failed projects identify inaccurate requirements gathering as a primary cause of failure. Research continues to validate that when organizations do not embrace business analysis and overlook the importance of establishing effective processes to perform it, there is a direct impact to their ability to perform effectively on projects. Those organizations that demonstrate maturity in business analysis practices are 55% more successful in implementing strategy and are much more likely to achieve the expected value from the investments made on programs and projects. These are just a few of the statistics obtained from recent PMI research proving the value of business analysis.

Currently organizations are interested in understanding how best to:

• Strategically leverage business analysis to ensure that investments are allocated to the highest-value initiatives;
• Adequately invest so that product teams have the resources they need to properly identify and solve the right problems; and
• Deliver solutions that provide measurable business value and meet stakeholder expectations.

Such trends are driving the need for additional skilled business analysis professionals globally.

PMI research has also shown that improved business analysis skills and practices can significantly impact the success of an organization, including providing a competitive advantage in the marketplace. In this research, business analysis was identified as a contributor to gaining a competitive advantage over the past five years by 81% of the business analysts who stated they work in an organization where business analysis practices are considered highly mature [2]. In addition to skills development and process maturity, organizations are also taking steps to champion an improved and stronger integration of business analysis with project management, recognizing the contributions of each role in ensuring project success.

Business analysis professionals from every level of experience and competency, regardless of where they report functionally, require a business analysis standard that can be universally applied in any size organization, industry, or region of the world. Business analysis professionals need a standard that recognizes generally accepted good practices to support the practice of business analysis efficiently, effectively, and consistently to deliver solutions that provide the most value.

This guide identifies business analysis practices that are generally recognized as good practice. These terms are defined as follows:

• Generally recognized. Generally recognized means the knowledge and practices described are applicable to most portfolios, programs, and projects most of the time, and there is consensus about their value and usefulness.
• Good practice. Good practice means there is general agreement that the application of the knowledge, skills, tools, and techniques when performing business analysis contributes to the successful delivery of the expected business values and results across portfolios, programs, and projects. Good practice does not mean that the knowledge described should always be applied uniformly to all portfolios, programs, or projects; the business analysis professional, working with stakeholders and the product team, determines what is appropriate for given situations.

This guide is different from a methodology. A methodology is a system of practices, techniques, procedures, and rules used by those who work within a discipline. The guide, on the other hand, is a foundation upon which organizations can build methodologies, policies, procedures, rules, tools, and techniques needed to practice business analysis effectively. This guide aligns the global community on what comprises the business analysis profession and aims to help organizations realize improvements in business analysis capabilities by ensuring that business analysis is commonly defined and understood.

1.1.1 THE NEED FOR THIS GUIDE

As organizations strive to meet market demands, the expectation is to deliver better solutions in a faster and less expensive manner. Recent PMI research identified business analysis as a key competency to help organizations achieve this goal. The Standard for Business Analysis and the PMI Guide to Business Analysis are intended to assist organizations and individuals in understanding the business analysis discipline as a basis for attaining mature and effective business analysis processes.

1.1.2 INTENDED AUDIENCE FOR THIS GUIDE

This guide is intended for anyone who performs business analysis activities, regardless of job title or percentage of time spent performing business analysis. This guide is also intended for anyone who works with someone who performs business analysis, for example, those who perform portfolio, program, or project management; the information presented here supports better collaboration among roles. This guide can be used by organizations and project teams to understand what constitutes good business analysis practice and can serve as a framework to provide a common business analysis language and structure by which practices can be further understood with regard to the value and purpose each provides.

1.1.3 THE VALUE OF BUSINESS ANALYSIS

Organizations with highly mature business analysis practices believe that business analysis has a tangible impact on their organization's success and provides a competitive advantage [3]. Research confirmed that a significantly larger percentage of highly mature organizations rank themselves well above average against their peer organizations with regard to:

• Ability to implement strategy,
• Organizational agility,
• Management of projects, and
• Overall financial performance [3].

With strong research validating business analysis as a key competency, organizations that follow mature business analysis practices will deliver better results and do so more efficiently and effectively than peer organizations with immature practices [3].

PMI's Pulse of the Profession^® In-Depth Report: Requirements Management: A Core Competency for Project and Program Success [1] reports that organizations can focus more attention on the following three critical areas to improve the effectiveness of their business analysis capabilities:

• People. By putting in place the necessary human resources who can properly apply business analysis to recommend solutions to the problems or opportunities addressed by the portfolios, programs, and projects, and at the same time, recognizing and developing the skills needed to perform this important role.
• Processes. By establishing and standardizing processes at the portfolio, program, and project levels, so consistent application of good business analysis can occur across initiatives within an organization.
• Culture. By creating a sense of urgency at the top so that executive management and sponsors fully value the practice of business analysis as a critical competency of portfolios, programs, and projects, and provide the appropriate support and commitment needed to excel throughout the organization.

Those responsible for performing business analysis can work collaboratively with members of their organization to determine and apply the appropriate level of generally recognized good business analysis practices for different situations and needs. The effort to determine and apply the appropriate business analysis processes, tools, techniques, and other items, including the life cycle(s) being employed, is referred to as tailoring. Refer to Section 1.3.4 for more information on how business analysis practices may be tailored to address the specific needs of the organization.

Business analysis can be performed when creating or enhancing a product, solving a problem, or seeking to understand stakeholder needs. The value of business analysis spans many industries and types of projects. For instance:

• In the financial industry, business analysis can be used to create or modify financial products that meet customer needs;
• In the health-care industry, business analysis can be used to minimize wait times from entrance to first diagnosis;
• On construction projects, business analysis can be used to define the requirements of a new building for use as the basis for the scope of work;
• Governments use business analysis to analyze situations and determine the best solutions to improve issues such as poverty, economic crises, and environmental issues;
• In manufacturing, business analysis can be applied to optimize assembly-line processes; and
• On IT projects, business analysis is performed to translate the business requirements into stakeholder and system requirements to provide clear guidance to designers and developers on what to build.

There are many uncertainties that affect business outcomes, such as whether consumers will purchase a product when it is built, whether existing infrastructure will support future growth rates, uncertainties over having sufficient staff to support customer demands, or the many unknowns that could result in a product being broken when used in unconventional ways that were not considered during product design. Effective business analysis enables individuals, groups, and public and private organizations to achieve better business outcomes. Effective business analysis helps:

• Address business needs;
• Manage risk and reduce rework;
• Minimize product defects, recalls, lawsuits, and reduction in consumer confidence; and
• Achieve stakeholder satisfaction.

These items are further discussed in Sections 1.1.3.1 through 1.1.3.4.

1.1.3.1 ADDRESSING BUSINESS NEEDS

Organizations are often tempted to provide solutions before fully understanding a situation. Business analysis enables the organization to identify and fix the root causes of problems instead of repeatedly addressing symptoms as they occur. Good business analysis hinges on conducting a needs assessment and recommending a solution based on the specifics of the problem space, including, but not limited to, understanding the business and enterprise architectures. Business analysis assists in detecting new opportunities that are essential for the growth and perhaps even the survival of an organization. Exploiting opportunities is imperative to secure a competitive advantage in the marketplace. Business analysis helps organizations obtain business value when addressing business needs.

1.1.3.2 MANAGING RISK AND REDUCING REWORK

What constitutes sufficient business analysis is dependent on the risk appetite of the organization and the level of confidence required before the organization is comfortable proceeding with its initiatives. The decision to proceed without performing sufficient business analysis and accepting a higher level of uncertainty is often the result of undervaluing business analysis activities. Although business analysis requires considerable time and resources, if overlooked, it can result in insufficiently understood requirements, missed stakeholder expectations, and frustration on the part of the project team and other key stakeholders. These issues can lead to much rework and many requests for change. It may seem counterintuitive, but taking the time to conduct business analysis actually saves time, reduces costs, and minimizes risk exposure in the long run.

1.1.3.3 EFFECTS OF PRODUCT DEFECTS

When insufficient time is allocated to business analysis activities, gaps in requirements can arise. Missing and misunderstood requirements can lead to product defects. Product defects uncovered within the confines of the project result in rework, but if these product defects are uncovered once a product is released to the consumer, the results are exponentially worse. Product defects in production may result in product recalls, lawsuits, reduction in consumer confidence, or harm to end users.

1.1.3.4 STAKEHOLDER SATISFACTION

Creating products to address the needs of the business and delivering those products on time and within budget while minimizing potential threats to the organization results in increased stakeholder satisfaction. Looking at how accepting stakeholders are of the end product or how willing the stakeholder is to pay for the solution once it is built can provide an overall indication of true stakeholder satisfaction. The application of good business analysis practices can result in the product or solution being accepted early on and fully adopted once implemented or released, and achieving high levels of stakeholder satisfaction.

1.1.4 UNDERSTANDING ROLE BOUNDARIES

The business analyst role is often misunderstood and underutilized and often commonly confused with other roles within the organization. The role of the business analyst is often confused with that of a project manager, because of a perceived overlap; however they both serve in critical leadership roles on programs and projects [3]. Another complicating factor is that many people who perform business analysis have different titles across various industries and sometimes even within the same organization. Similarly, many organizations create business analysis positions but use the position as a “catch-all,” asking business analysts to perform activities outside of what is common responsibility for the discipline, such as performing testing activities or administrative tasks.

To ensure successful role collaboration, it is imperative to understand the role boundaries between critical resources engaged in work on portfolios, programs, and projects. The research indicated that organizations that achieve a high level of collaboration between project managers and business analysts are able to deliver more successfully on projects [3]. This research should serve as encouragement to establish an organizational culture that embraces collaboration between these roles. When an individual is tasked with performing more than one role, such as a business analyst and project manager hybrid, this individual will have the added responsibility of distinguishing between different and sometimes competing priorities, tasks, and methods involved in each role.

Section 3 further explores role boundaries by looking at the position of the business analyst within the organizational structure and presenting a comprehensive list of the skills often demonstrated by those who perform business analysis.

1.1.5 THE STANDARD FOR BUSINESS ANALYSIS

The Standard for Business Analysis [4], referred to here as the standard, is a foundational reference for the practice of business analysis and PMI's business analysis professional development programs. The standard identifies the processes that are considered good business analysis practices on most portfolios, programs, and projects most of the time. The standard identifies the inputs and outputs that are usually associated with those processes. One or more methodologies may be used to implement the business analysis processes outlined in this standard.

1.1.6 USING THE STANDARD IN CONJUNCTION WITH OTHER PMI PRODUCTS

The Standard for Business Analysis complements PMI's other foundational standards by identifying and discussing the alignment between business analysis and portfolio, program, and project management. The other foundational standards are:

• A Guide to the Project Management Body of Knowledge (PMBOK^® Guide) [5],
• The Standard for Program Management [6],
• The Standard for Portfolio Management [7], and
• The Standard for Organizational Project Management [8].

The Standard for Business Analysis and the PMI Guide to Business Analysis can be used in conjunction with Business Analysis for Practitioners: A Practice Guide [9]. While the guide and standard define the business analysis processes and concepts that are generally recognized as good practice, Business Analysis for Practitioners: A Practice Guide provides practical knowledge about how to apply business analysis tools and techniques to develop and manage requirements to perform the work. For example, the guide will help determine which tools and techniques may be used to perform each business analysis process and the Business Analysis for Practitioners: A Practice Guide may be consulted for examples and information on how to use the tool or perform the technique.

1.1.7 COMMON VOCABULARY

This section describes common vocabulary necessary for working in and understanding the discipline of business analysis.

1.1.7.1 BUSINESS ANALYSIS

Business analysis is the application of knowledge, skills, tools, and techniques to:

• Determine problems and opportunities;
• Identify business needs and recommend viable solutions to meet those needs and support strategic decision making;
• Elicit, analyze, specify, communicate, and manage requirements and other product information; and
• Define benefits and approaches for measuring and realizing value, and analyzing those results.

In short, business analysis is the set of activities performed to support the delivery of solutions that align to business objectives and provide continuous value to the organization.

Business analysis is performed through the application of a set of processes that are defined and explored in this guide. The sum of all the processes within this guide provides a thorough definition and knowledge of business analysis.

Business analysis is conducted in support of solution development, through portfolios, programs, and projects, as well as ongoing operational activities, such as monitoring, modeling, and forecasting. The practices defined within this guide apply wherever business analysis is conducted.

1.1.7.2 BUSINESS ANALYST

Business analysis may be performed by any individual regardless of the person's job title. In this guide, the person(s) who performs business analysis processes will be referred to as a business analyst. The term is being used in the broad sense and represents all the roles that are responsible for performing business analysis activities across industries or within organizations, regardless of whether the work is performed to support portfolios, programs, or projects. Many portfolios, programs, and projects require a team of individuals to perform business analysis, and in these scenarios, the term business analyst will also be applied.

Section 3 elaborates on the role of the business analyst and presents job titles often used to identify those who perform business analysis.

1.1.7.3 PRODUCT

A product is an artifact that is produced, is quantifiable, and can be either an end item in itself or a component item. Products are also referred to as materials or goods. A product can be tangible or intangible—for example, an organizational structure, a process, or a service. A service is the performance of duties or work for another party. Products are created or updated as parts of solutions to address business needs; therefore, they provide business value.

1.1.7.4 PRODUCT REQUIREMENTS

A requirement is defined as a condition or capability that is required to be present in a product, service, or result to satisfy a business need. This guide uses the term product requirement to describe the types of requirements that are part of the business analysis effort. Product requirements are the primary focus of this guide, and the term requirement without a qualifier is used to specify all product requirement types.

A product requirement represents something that can be met by a solution and addresses a need of a business, person, or group of people. A product requirement should be independent of the design of the solution that addresses it. Product requirements are specified to clarify and communicate a business need or required capability. Whether they are expressed as requirement statements, use cases, user stories, backlog items, or visual models, a clear understanding of product requirements is essential for developing solutions that meet the business needs. Sometimes requirements are unstated because stakeholders are unaware of what is really needed until they are using a solution or viewing a prototype. Although unstated, these needs are still requirements. This highlights the importance of using a variety of elicitation techniques to draw forth sufficient information to develop the solution, reducing the likelihood that stakeholders have expectations that have not been verbalized.

This guide uses the term product requirement in the broad sense; therefore, when performing the work of requirements elicitation, specification, or requirements management, one may choose to indicate the type of requirement to be able to communicate whether the product requirement represents a need of the business, an aspect of the solution, or a product requirement for a particular stakeholder group. To provide clarity and context, product requirements are often categorized by type.

The following product requirement types are discussed in this guide:

• Business requirement. Describes the higher-level needs of the organization such as business issues or opportunities, reasons why an initiative has been undertaken, and measurable representations of goals the business is seeking to achieve. Business requirements are used to provide context and direction for any solution so that the solution addresses the business need. Business requirements are typically defined before a portfolio component, program, or project has been initiated, as they represent the reason why the portfolio component, program, or project has been undertaken or why the product should be created or modified. Business requirements are often used to define the success criteria for the portfolio component, program, or project. An organization may have multiple business requirements. All other remaining product requirement types—such as stakeholder, solution, and transition requirements—are typically defined within the context of a project.
• Stakeholder requirement. Describes the needs of a stakeholder, where the term stakeholder refers to an individual, group, or organization that may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a portfolio, program, or project. Examples of stakeholders include customers, users, regulators, suppliers, and partners, as well as internal business roles.
• Solution requirement. Describes the features, functions, and characteristics of a product that will meet the business and stakeholder requirements. Solution requirements are further grouped into functional and nonfunctional requirements as follows:

• Functional requirement. Describes the behaviors of the product. Examples of types of functional requirements include actions, processes, and interactions that the product should perform. The data and rules needed to support functional requirements are typically elicited concurrently.
• Nonfunctional requirement. Describes the environmental conditions or qualities required for the product to be effective. Nonfunctional requirements are sometimes known as product quality requirements or quality of service requirements. Examples of types of nonfunctional requirements include reliability, security, performance, safety, level of service, and supportability. Quality of service requirements are not the same as the quality requirements discussed from a project management perspective.

• Transition requirement. Describes temporary capabilities, such as data conversion and training requirements, and operational changes needed to transition from the current state to the future state. Once the transition to the future state is complete, the transition requirements are no longer needed.

Two other types of requirements are project requirements and quality requirements. These requirement types are not part of the business analysis effort and are not considered to be product requirements. Project and quality requirements focus on project execution and are part of the project management effort. Because project and quality requirements are outside the scope of business analysis, they are only discussed here to show context of their relationship to business analysis:

• Project requirement. Describes the actions, processes, or other conditions the project needs to meet. Examples of types of project requirements include milestone dates, contractual obligations, and constraints.
• Quality requirement. Describes any condition or criterion needed to validate the successful completion of a project deliverable or the fulfillment of other project requirements. Examples of types of quality requirements include tests, certifications, and validations.

Although project and quality requirements are part of the project management effort, collaboration is required to define all types of requirements. The project management effort comprises the management of all requirements-related deliverables, including ensuring that the definition of the product requirements is completed. When product requirements are defined, the constraints of the project need to be accounted for to ensure that the defined solution can be delivered within the time, resource, and cost parameters of the project. It would be difficult to accurately describe the work needed to deliver the solution and determine how to validate the successful completion of project deliverables without some information about the solution. Project and quality requirements, therefore, cannot be defined until the solution is somewhat defined.

Business analysis focuses on ensuring that the product is of sufficient quality through the development of nonfunctional requirements. Project management focuses on ensuring that the processes performed to deliver the solution are of sufficient quality through the development of quality requirements. When the solution adheres to nonfunctional requirements and the processes to deliver the solution adhere to quality requirements, it maximizes the probability that the solution will meet business needs.

For more information about project and quality requirements, refer to the PMBOK^® Guide – Sixth Edition.

Figure 1-1 depicts the relationships that exist among various categories of product and project requirements, for example:

• A single business requirement may be supported by multiple stakeholder and solution requirements;
• A single stakeholder requirement may be supported by many solution requirements;
• Solution requirements may be written as functional or nonfunctional requirements;
• Because transition requirements describe the transition from the current to future state, they support the implementation of stakeholder and solution requirements;
• Project requirements support product requirements, as project requirements describe the work needed to deliver the unique solution(s); and
• Quality requirements support project requirements because they are used to validate the successful completion of a project deliverable or the fulfillment of other project requirements.

1.1.7.5 PRODUCT INFORMATION

Throughout the performance of the business analysis process, significant amounts of information are created, collected, analyzed, modified, consumed, and shared. Within the guide and standard, when product information is referred to in process descriptions as an input or as an output, the reference is being made to the most common component of product information that is relevant to the process. A choice was made not to list specific types of product information except where it could provide more context or understanding, because typically the specifics are highly dependent on life cycles and organization-specific terminology used by teams. The types of information the guide refers to as product information include:

• Business goals and objectives,
• Requirements,
• Analysis models,
• Backlogs,
• User stories,
• Acceptance criteria and definition of associated metrics,
• Product scope,
• Product risks,
• Assumptions,
• Constraints,
• Dependencies, and
• Issues.

Product information can include different types or levels of detail. For example, requirements could refer to business requirements or stakeholder requirements, and issues might be stakeholder issues or defects. Product information can take on different states as various processes consume and produce the information. For example, at different points in business analysis work, requirements can be in a verified, validated, prioritized, or approved state. The product information may be stored in a variety of forms, such as tools, documents, notes, emails, and possibly in people's minds.

Product information is by no means the only information relevant to business analysis processes. Additional kinds of information are used to create and analyze the product information throughout the course of performing business analysis. The type and form of the additional information could include the original source material from which elicitation results came, elicitation notes, emails with additional context about analysis, and verbal or written comments from stakeholders about the information.

1.1.7.6 SOLUTION

A solution is something that is produced to deliver measurable business value to meet the business need and expectations of stakeholders. It defines what a specific portfolio component, program, or project will deliver. A solution could be one or more new products, components of products, or enhancements or corrections to a product.

1.1.7.7 STAKEHOLDER

In project management, a stakeholder is an individual, group, or organization that may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project. In business analysis, stakeholders also include those affected or perceived to be affected by activities and decisions related to the solution. Identifying stakeholders, analyzing them, and effectively managing their expectations are critical activities for both project management and business analysis. Each discipline performs these activities for different purposes and with a different focus; project managers identify and analyze stakeholders to best manage the project and business analysts identify and analyze stakeholders to best manage the business analysis activities. See Section 1.2.1 for more information on the product/project relationship.

In business analysis, stakeholder identification begins when business analysis activities are performed to define the business need and situation statement and continues through the development of a business case and during charter development. It is imperative that the stakeholder list be revised regularly to retain its accuracy. Throughout an initiative, several factors may occur that require further identification or analysis to be performed, such as a change in product scope or a refinement of requirements that uncovers new stakeholders. Business analysts work very closely with stakeholders, often on a day-to-day basis, and therefore, they continue to make refinements to the stakeholder register as new information becomes available. Maintaining accuracy of the stakeholder register is critical because when stakeholders are overlooked, there is a high chance that requirements will be missed.

In business analysis, understanding the stakeholders identified in the register is equally important. When stakeholder characteristics are not known or understood, the business analyst may choose techniques that are ineffective. Misunderstanding stakeholders may result in ineffectively communicating or collaborating with stakeholders throughout the entire product life cycle. For more information on stakeholder characteristics, see Section 5.2.

Stakeholders have different roles and relationships across the business analysis effort. Their involvement can change over the course of the product life cycle. Stakeholder involvement may range from being occasional contributors in surveys and focus groups to full project sponsorship that includes the provision of financial, political, or other types of support. Stakeholders may be actively involved in requirements-related activities, serving as subject matter experts (SMEs) or decision makers with regard to product scope, requirements priorities, or proposed changes to product features. Stakeholders may have interests that may be positively or negatively affected by the end solution. Different stakeholders may have competing requirements and expectations that could create conflicts for decisions about approving solution options, requirements, or allocating requirements across releases. Stakeholders may also exert influence over various aspects of the business analysis process, its deliverables, and other stakeholders to achieve a set of outcomes that satisfies their own needs and expectations. It is essential that these relationships and dependencies be identified and managed to ensure a successful business analysis process. Section 3.3.3.1 describes some of the typical relationships created and managed by business analysts, including those relationships managed with stakeholders.

1.2 FOUNDATIONAL ELEMENTS

1.2.1 RELATIONSHIP BETWEEN PRODUCTS AND PROJECTS

For organizations to remain competitive, products often evolve through the work of projects. Projects deliver solutions through new products, product enhancements, revised processes, integrated systems, restructured organizations, market research, and trained personnel. Remaining competitive, however, is not the only reason products are advanced—evolution could occur to address regulatory or compliance needs, fix inefficiencies, increase revenue, cut costs, or other reasons. Business analysis is used to identify business needs and subsequently to identify and define appropriate solutions to address those needs.

Projects are temporary endeavors undertaken to create unique products, services, or results. Business analysis focuses on products, whereas project management focuses on delivering projects to create or evolve products. Both views are essential because the concepts of products and projects are highly intertwined—a fact that cannot be ignored. Figure 1-2 represents one scenario for the relationship between projects and products in which one product evolves over the course of multiple projects.

1.2.2 PRODUCT AND PROJECT LIFE CYCLES

A product life cycle is a series of phases that represent the evolution of a product from concept through delivery, growth, maturity, maintenance, and retirement. The number of intermediary phases that a product goes through is dependent on the longevity of the product life cycle. Projects may be implemented to evolve products, but projects are not required for this evolution. It may take multiple projects to evolve a product through the product life cycle and, in some cases, a product may evolve in the same phase.

A product life cycle may consist of multiple project life cycles. A needs assessment conducted within the product life cycle provides strategic alignment and justification for the investment of a new project. After the project is complete, an evaluation of the product is performed within the product life cycle to determine if a new project is needed to evolve the product. Business analysis focuses on the entire product life cycle, including the many projects that advance the product.

A project life cycle is the series of phases through which a project passes from its initiation to its closure. The phases can be sequential or they may overlap. The names, number, and duration of the project phases are influenced by a number of factors, including the management and control needs of the organization(s) involved in the project, the nature of the project itself, its area of application, and the complexity or volatility of the product information. The phase or phases associated with the development of features and capabilities can be unitary or composed of multiple iterations. Iterations are generally time-bounded, with a start and end or control point. At the control point, the project charter, business case, and other project baselines are reexamined based on the current environment. The project's risk exposure and evaluation of project execution compared to its performance measurement baseline are used to determine if the project should be changed, terminated, or continued as planned.

The project life cycle is influenced by many internal and external factors, including but not limited to, the unique aspects of the organization, industry, or technology employed. While every project has a clear start and end, the specific deliverables and work that take place vary widely depending on the project. The life cycle provides the basic framework for managing the project, regardless of the specific work involved.

Figure 1-3 shows the relationship between product and project life cycles, illustrating that a product life cycle is comprised of one or more project life cycles. While the diagram is not intended to model life cycle phases, keep in mind that each project life cycle may contain activities related to a part of the product life cycle (e.g., product development, product maintenance, and eventually product retirement).

Project life cycles can range along a continuum from predictive life cycles at one end to adaptive ones at the other. In a predictive life cycle, the project deliverables are defined at the beginning of the project, and any changes to the scope are managed. In an adaptive life cycle, such as an agile approach, the deliverables are developed over multiple iterations where a detailed scope is defined and approved at the beginning of each iteration.

1.2.3 HOW BUSINESS ANALYSIS SUPPORTS PORTFOLIO, PROGRAM, AND PROJECT MANAGEMENT

Portfolio management is the centralized management of one or more groupings of projects, programs, subsidiary portfolios, and operations to achieve strategic objectives. Programs focus on achieving a specific set of expected benefits as determined by organizational strategy and objectives, whereas projects are largely concerned with creating specific deliverables that support specific organizational objectives. Projects may or may not be part of a program. Business analysis supports portfolio, program, and project management. Business analysis competencies increase alignment between the higher-level strategies and outcomes of programs and enable portfolio, program, and project management practices and processes.

Business analysis begins with defining a situation and a complete understanding of the problem or opportunity that the organization wishes to address; this work is considered pre-project. The results of pre-project activities provide information to understand the value a given project provides the portfolio and program. When organizations lack portfolio and program management practices, the definition of the problem or opportunity should be performed at the onset of the project. Business analysis activities support portfolio management by helping to align programs and projects to organizational strategy. In portfolio, program, and project management, business analysis also involves the elicitation and analysis necessary to define the product scope, requirements, models, and other product information necessary to build a common understanding of the solution and clearly communicate product features to those responsible for developing the end product.

The business analysis processes performed as part of the Defining and Aligning Process Group produce analysis results and other outputs leveraged by portfolio management. All other business analysis activities performed outside of the Defining and Aligning Process Group help define the solution and support the work of program and project management. The Business Analysis Process Groups are defined in Section 1.3.2.

Table 1-1 provides a comparison of business analysis with project, program, and portfolio management.

1.2.4 BUSINESS VALUE

Organizations employ portfolio, program, and project management to improve their abilities to deliver benefits. Business value may be defined as the net quantifiable benefit derived from a business endeavor. The benefit may be tangible, intangible, or both. In business analysis, business value is considered the return, in the form of time, money, goods, or intangibles for something exchanged. For example, tangible benefits may include monetary assets, facilities, fixtures, equity, and utility, and intangible benefits may include goodwill, brand recognition, public benefit, trademarks, compliance, and capabilities. Business value may also be created through the effective management of ongoing, well-established operations. However, the effective use of portfolio, program, and project management enables organizations to employ reliable, established processes to generate new business value by effectively pursuing new business strategies that are consistent with their mission and vision for the future.

Portfolio management ensures that an organization's programs, projects, and/or operations are aligned with its strategy. It allows organizations to define how they will pursue their strategic goals through programs and projects, and how those programs and projects will be supported by human, financial, or material resources. In doing this, portfolio management optimizes the pursuit of business value.

Program management enables organizations to effectively pursue their strategic goals through the coordinated pursuit of projects, programs, and other program-related work. Program management seeks to optimize the management of related component projects and programs to improve the generation of business value.

Project management enables organizations to efficiently and effectively generate outputs and outcomes required for the pursuit of their strategic goals by applying knowledge, processes, skills, tools, and techniques that enhance the delivery of outputs and outcomes by projects. Project management seeks to optimize the delivery of business value by improving the efficiency of organizations as they deliver new products, services, or results.

Business analysis is used to perform research and elicit sufficient information to support business decision making, to determine if and when there is value in pursuing organizational changes to address business needs, and when it makes sense, to initiate a project or program to facilitate such change. As a result, business analysis optimizes the delivery of business value by providing the information needed to make wiser investment decisions on portfolios, programs, and projects. These processes are further discussed in Sections 7.4 and 9.3, where business value is defined and the results of measurements are considered.

Business analysis also supports the elicitation necessary to specify the set of product information used by development teams to design, build, and deliver solutions once the decision to pursue an organizational change has been made.

To ensure the best chance of success, business analysis performance can be assessed periodically by using the results from evaluation to identify and act on opportunities for improving business analysis practices. As with any valuation, agreed-upon measures need to be defined up front. See Section 5.7 for details about evaluating business analysis performance during and after projects.

1.2.4.1 DETERMINING BUSINESS VALUE

A project benefit is defined as an outcome of actions, behaviors, or solutions that provide value to the sponsoring organization as well as to the project's intended beneficiaries. However, it may sometimes be difficult to measure whether projects have delivered business value because business value can mean different things to different stakeholder groups. For example, if a project introducing a new product missed its sales targets, but those who purchased the product were very satisfied with it and indicated that they would repurchase the product, then depending on whom you ask, you may obtain a different response to the question of whether this project provided business value.

Some organizations might choose to define and prioritize based on customer value instead of, or in addition to, business value. Ideally, customer and business value are aligned such that items that are of value to the customer are also of value to the business. However, this is not always the case. Even when a proposed change that is of value to the business might not be of value to the customer, the business might choose to move forward with the implementation. Similarly, something that is of value to the customer might not provide value to the business. For this reason, focusing solely on customer value is risky because the business might not receive the benefits to justify pursuing the proposed change. Business analysis is used to understand and prioritize competing definitions of value by different stakeholders. The rest of this section refers to business value, but the same concepts about defining and measuring business value also apply to customer value.

A challenge in defining business value often lies with first articulating the intended business value before the project has started, so the project team knows what to strive for, which answers the question “Why are we doing this project?” Project benefits are defined in the form of business objectives that serve as the foundation for business requirements and all other categories of product requirements. Business analysis is used to define reasonable business objectives that can be measured. For example, a business objective to which a project might contribute could be to increase revenue by US$1 million in the next calendar year.

Another challenge is articulating the business value in a measurable form or articulating or finding indirect evidence for business value. In the previous example, where the business objective was to measure revenue growth, some organizations might find it difficult to set a target revenue, baseline the revenue, or even measure revenue growth. Organizations are also sometimes hesitant to commit to achieving a target benefit. A measurement, such as customer satisfaction, can be used as a proxy or indirect evidence for revenue growth, with the assumption that there is a correlation between customer satisfaction and revenue growth. Increasing customer satisfaction is also something that is not easily measured; however, customer satisfaction surveys can be a means to quantify customer satisfaction. If the business objective is to increase customer satisfaction by three points, then customer satisfaction surveys can answer whether the business value has been achieved.

1.2.4.2 MEASURING BUSINESS VALUE

A complication is that the realization of benefits often does not happen until well after project completion. For example, when measuring revenue growth, measurement of the target revenue cannot be performed until a year after the solution has been deployed. Measurement of customer satisfaction, which is a good leading indicator that revenue growth is also on track, may be accomplished sooner. By establishing a business objective before the project starts and determining how it will be measured, the project team is able to build requirements based on the business objectives and to incorporate the process of measuring the business value into the project, which ensures that metrics are available when the project has been implemented and that measurement data can be collected. If it is known that business value will be measured by customer satisfaction survey scores, a baseline survey should be taken to determine whether satisfaction increased. Resources can also be set aside to measure whether the business value was achieved after the project was implemented to learn from this experience, which could also introduce new projects and support the development of the product roadmap.

1.2.4.3 MEASURING PROJECT SUCCESS

Project success should be tied to whether a project delivered its intended business value. PMI's Pulse of the Profession In-Depth Report: The High Cost of Low Performance [2] reported that organizations have consistently struggled to deliver projects that meet original goals and business intent. In 2016, only 62% of the organizations surveyed said they achieved what they set out to do, and in 2017 this measure rose to 69% [2].

The types of information that can be analyzed and documented when deciding how portfolio, program, and project success will be measured include the following:

• Business objectives. Measurable objectives, including the timing of when they should be measured.
• Strategic alignment. How well the business objectives align to the overall strategies of the organization.
• Benefits owner. Accountable person to monitor, record, and report realized benefits throughout the plan.
• Measurement plan. Plan describing what to measure, how to measure it, and when to measure whether the business objectives have been achieved.
• Risks. Uncertain events or conditions that could affect the achievement of business objectives.
• Assumptions. Assumptions that are made when defining the business objectives and how they will be achieved.

1.3 COMPONENTS OF THIS GUIDE

1.3.1 BUSINESS ANALYSIS PROCESSES

Business analysis processes describe the activities performed to conduct business analysis. Every business analysis process produces one or more outputs from one or more inputs by using appropriate business analysis tools and techniques. A process is defined as a systematic series of activities directed toward causing an end result such that one or more inputs will be acted upon to create one or more outputs.

An input is defined as any item that is required by a process before that process proceeds. Depending on the point in time within the product life cycle, the list of inputs may change; therefore, the processes listed in this guide represent the inputs that would apply regardless of timing. In practice, if there are better inputs available, then the process can be tailored to use them. It is important to note that organizational process assets, enterprise environmental factors, expert judgment, and the business analysis plan are commonly used as inputs into all business analysis processes and will therefore not be repeated as inputs for each process discussed within the guide.

An output is defined as a product, result, or service generated by a process. The output of one process generally results in:

• An input to another process;
• A business analysis deliverable; and/or
• An outcome, end result, or consequence of a process.

Business analysis is accomplished through the appropriate application and integration of logically grouped business analysis processes that are linked by the outputs they produce. Business analysis processes apply globally across industry groups. Processes may be used in parallel, contain overlapping activities, and occur multiple times throughout the product life cycle. While business analysis processes are not required, each process is recommended to varying levels of detail under different conditions. For more information about tailoring business analysis processes, see Section 1.3.4.

1.3.2 BUSINESS ANALYSIS PROCESS GROUPS

A Business Analysis Process Group is a logical grouping of business analysis processes. The Standard for Business Analysis defines six Business Analysis Process Groups. Each Process Group is independent of the application area or industry in which it is performed. Process Groups are not project life cycle phases; sequence and timing are not prescribed. Process Groups are revisited as one or more processes within the Process Group can be repeated on an ongoing basis throughout the project life cycle. The Executing Process Group is one such example. The processes for elicitation are ongoing and are performed for each iteration in an adaptive life cycle.

The six Business Analysis Process Groups are defined as follows:

• Defining and Aligning Process Group. The processes performed to investigate and evaluate the viability for initiating a new product or changes to or retirement of an existing product as well as defining scope and aligning products, portfolios, programs, and projects to the overall organizational strategy.
• Initiating Process Group. The process performed to define the portfolio, program, or project objectives and apply resources to a portfolio component, program, project, or project phase.
• Planning Process Group. The processes performed to determine an optimal approach for performing business analysis activities, including how they are adapted for the chosen project life cycle, and to analyze the internal and external stakeholders who will interact and influence the overall definition of the solution.
• Executing Process Group. The processes performed to elicit, analyze, model, define, verify, validate, prioritize, and approve all types of product information, ranging from backlogs to user stories and requirements to constraints.
• Monitoring and Controlling Process Group. The processes performed on an ongoing basis to assess the impact of proposed product changes within a portfolio, program, or project to assess business analysis performance and to promote ongoing communication and engagement with stakeholders.
• Releasing Process Group. The process performed to determine whether all or part of a solution should be released and to obtain acceptance that all or part of a solution is ready to be transitioned to an operational team that will take ongoing responsibility for it.

Figure 1-4 depicts the six Business Analysis Process Groups within the product and project life cycles. This diagram demonstrates that processes within the Business Analysis Process Groups can be performed within the context of a project and beyond by supporting the activities in program or portfolio management. The left side of Figure 1-4 shows the Business Analysis Process Groups that are used before a project initiates, but still within the product life cycle. The center section shows the Business Analysis Process Groups that are used during one or more iterations of a project. The right side of the figure shows the Business Analysis Process Groups that are used after a project but still within a product life cycle.

1.3.3 BUSINESS ANALYSIS KNOWLEDGE AREAS

Knowledge Areas are fields or areas of specialization that are commonly employed when performing business analysis. A Knowledge Area is a set of processes associated with a particular function. In this guide, the Knowledge Areas presented contain the set of processes that comprise the work of business analysis. The processes, though related, do not prescribe a sequence or order. The guide covers the following Business Analysis Knowledge Areas:

• Needs Assessment. Analyzing current business problems or opportunities to understand what is necessary to attain the desired future state.
• Stakeholder Engagement. Identifying and analyzing those who have an interest in the outcome of the solution to determine how to collaborate and communicate with them.
• Elicitation. Planning and preparing for elicitation, conducting elicitation, and confirming elicitation results to obtain information from sources.
• Analysis. Examining, breaking down, synthesizing, and clarifying information to further understand it, complete it, and improve it.
• Traceability and Monitoring. Tracing, approving, and assessing changes to product information to manage it throughout the business analysis effort.
• Solution Evaluation. Validating a full solution or a segment of a solution that is about to be or has already been implemented to determine how well a solution meets the business needs and delivers value to the organization.

Figure 1-5 illustrates the relationships that exist among the six Business Analysis Knowledge Areas. For example:

• The processes in the Stakeholder Engagement Knowledge Area are used throughout all business analysis efforts and interact with all the other Business Analysis Knowledge Areas;
• The results obtained by using the processes in the Needs Assessment Knowledge Area are the basis for work conducted using the processes in the Elicitation, Analysis, and Traceability and Monitoring Knowledge Areas;
• The processes in the Elicitation, Analysis, and Traceability and Monitoring Knowledge Areas tend to be used concurrently; and
• The processes in the Elicitation, Analysis, and Traceability and Monitoring Knowledge Areas produce results that are analyzed with the processes in the Solution Evaluation Knowledge Area, which, in turn, may trigger additional usage of the processes in the Needs Assessment Knowledge Area.

The Standard for Business Analysis presents the work of business analysis as a set of processes, relating those processes to the six Business Analysis Process Groups and six Knowledge Areas. In The Standard for Business Analysis, the Process Groups assist with understanding how business analysis processes are performed. Within this guide, Knowledge Areas are used to group related processes to demonstrate how work is associated or logically related to collectively achieve the objectives of the Knowledge Area.

Table 1-2 maps the 35 business analysis processes within the six Business Analysis Process Groups and the six Business Analysis Knowledge Areas. The business analysis processes depicted in this table are relevant to all projects regardless of the life cycle the project is following. Within this guide, processes are numbered and presented according to the sequence they appear within each Knowledge Area. Within the standard, the sequencing and location of the processes are different, as each is presented according to the order in which it appears within each Process Group.

Table 1-2 provides the reference numbers for locating each process within the guide and standard. The reference number appearing before the process name identifies the section where the process is located in the guide and the reference number in parentheses represents the section where the process is located within the standard. There is also a quick reference guide that summarizes this mapping in Appendix X4.

^A The section number preceding each process name identifies the location of the process in the guide. The section number in parentheses following the process name identifies the location of the process in the standard.

Business analysis processes are shown in the Process Group in which most of the activity takes place. When a process is performed in the Planning Process Group and its output is updated as part of the work in Executing, the process does not reappear in the Executing Process Group, but instead the process is just performed again. The iterative nature of business analysis means that processes from any group may be used throughout the product life cycle in any order. For example, when managing stakeholder engagement in Monitoring and Controlling, it may be necessary to adjust how best to engage stakeholders after gaining some experience working with them, thereby resulting in a need to revisit the Determine Stakeholder Engagement and Communication Approach process.

1.3.4. BUSINESS ANALYSIS TAILORING

Business analysis involves selecting the appropriate business analysis processes, tools, techniques, inputs, and outputs for use on a specific portfolio, program, or project. The business analyst performs this selection activity in collaboration with the project manager, sponsor, functional managers, other business analysts, or some combination thereof. This selection activity is known as tailoring business analysis.

Tailoring is necessary because each organization, portfolio, program, and project is unique; therefore, not every process, tool, or technique in this guide is necessarily required for every business analysis effort. The format of inputs and outputs listed within each process may also be tailored. For example, the output of Define and Elaborate Requirements (Section 7.3) is requirements and other product information. Requirements and other product information may be presented in the form of a requirements document, a collection of user stories, or another format deemed suitable for the situation. The inputs themselves can also be tailored, in that the inputs listed for each process are required at minimum to perform that process; however, if there are other helpful inputs available, they should be used. For example, a product roadmap may be beneficial when prioritizing product information, but is not listed as an input because a product roadmap may not always be available when prioritizing product information.

This guide provides a recommended reference for tailoring because it identifies the body of knowledge that defines business analysis that is generally recognized as good practice. Good practice does not mean that the knowledge described should always be applied uniformly to all portfolios, programs, or projects. There are different aspects of business analysis that can be tailored, including the:

• Business analysis methodology and techniques selected for use,
• Level of detail in the product information, and
• Business analysis deliverables.

Tailoring business analysis methodologies and practices is covered in Section 1.3.4.1. Tailoring the level of detail of product information is covered in Section 1.3.4.3. Tailoring the business analysis deliverables is covered in Section 1.3.4.4. More details about tailoring each process are covered within the process descriptions throughout the guide.

There are several factors that impact how to tailor business analysis. When deciding how to tailor business analysis, the team should consider the factors shown in Table 1-3. Table 1-3 presents the factors individually, but the cumulative effect of these factors could have a different impact on tailoring. For example, experienced stakeholders working in a highly regulated environment may require more detailed product information than they would otherwise if the environment were unregulated.

Table 1-3. Factors That Impact Tailoring Business Analysis

Tailoring Consideration Factors	How Factor Impacts Tailoring
Chosen project life cycle	Adaptive and predictive project life cycles almost always require different business analysis methodologies, different product information, and different deliverables. Tailoring business analysis based on the project life cycle is covered in more detail in Section 1.3.4.5.
Stakeholder knowledge and experience	Experienced and knowledgeable stakeholders or teams that have been working together for a while may require less detailed product information.
Location of the project participants	Distributed project participants may require detailed product information and additional deliverables to ensure communication when not face-to-face.
Business analysis experience on the team	Experienced business analysts may require less detailed business analysis practices than an inexperienced team. Teams that are not familiar with business analysis practices may need to conduct formal business analysis practices to help mature the teams.
Maturity level of the organization	Start-up organizations may not need or have formal business analysis practices or deliverables, whereas established organizations may have existing and repeatable business analysis practices.
Corporate culture	Some changes to business analysis practices are difficult or not possible without changes incorporate culture. Though improvements in business analysis processes may be justified, they may not be successful without a shift in mindset. Business analysis needs to be balanced between what is required, what is possible, and what will be accepted.
Importance or value of the project or components of the project	Highest-value projects or components of projects may warrant more rigorous business analysis practices, detailed product information, and additional formal deliverables.
Risk appetite of stakeholders and risk to the project, product, or its components	Higher risk levels may require rigorous business analysis methodology and detailed product information and additional deliverables for the riskiest components. Some stakeholders with lower risk appetite levels may want all details documented and approved.
Team stability	Irrespective of the project life cycle, when staffing volatility is a concern, there may be a need for more detailed product information and additional deliverables to reduce risk.
Size and complexity of the project	Larger or complex projects may require rigorous business analysis methodology, detailed product information, and additional interim deliverables to ensure thorough communication.
Governing standards and regulatory constraints	Regulatory constraints may require formal methodology, detailed product information, and additional deliverables to meet compliance requirements.
Outsourcing or vendor involvement	Contractual aspects of dealing with outsourced product development may require more formal business analysis practices and hand offs, more detailed project information, and additional hand-off deliverables.

1.3.4.1 BUSINESS ANALYSIS METHODOLOGY AND PRACTICES TAILORING

In some organizations, business analysts apply a business analysis methodology or business analysis practices to their work, which is either part of, or needs to align to, the overall project management or product development methodology. A methodology is a system of practices, techniques, tools, procedures, and rules used by those who work in a discipline. A practice is less formal than a methodology, is not required, and pertains to a manner in which we perform our work, typically based on preferences or recommended conventions or approaches. This guide itself is not a methodology because, although it offers practices, tools, and techniques, it does not prescribe the order, procedures, and rules for applying those elements. Individual business analysis methodologies may be derived from The Standard for Business Analysis. Specific methodology recommendations are outside the scope of this guide. Some practices, techniques, and tools could be used in one methodology but not another. The order of application may also vary by methodology. Business analysis methodologies and practices may be:

• Developed by experts within an organization,
• Developed by experts outside an organization,
• Defined by vendors,
• Prescribed by a tool,
• Obtained from professional associations,
• Acquired from government agencies, or
• Any combination of these items.

To summarize, business analysts need to adapt elements of this guide to fit within their organization's overall methodology and any existing project or business analysis practices where value can be enhanced.

1.3.4.2 BUSINESS ANALYSIS TECHNIQUES TAILORING

Techniques describe different ways for performing a particular business analysis process or task. There are hundreds of techniques in use. Some techniques are specifically used when performing business analysis, while others are common and used by many disciplines. As the standard and this guide describe business analysis activities for all project life cycles, the techniques, too, are universal, regardless of the chosen delivery approach. While some techniques may be more helpful in one life cycle than another, most business analysis techniques are beneficial regardless of the life cycle chosen or industry in which they are performed.

The techniques discussed in this guide were chosen based on universal and common use and are not intended to be an exhaustive collection of all the options available. Within each business analysis process, a small sample of techniques is listed as guidance to highlight possible techniques a business analyst may apply when performing the process. This list is based on universal and common use and is not intended to be exhaustive. Those performing business analysis are always encouraged to learn new techniques or adapt current techniques to new situations; therefore, the techniques available to a practitioner are always changing and growing.

1.3.4.3 PRODUCT INFORMATION TAILORING

Product information, as described in Section 1.1.7.5, includes any of the information created, collected, analyzed, modified, consumed, and shared in business analysis. The product information used in business analysis is adapted most commonly based on the needs of the stakeholders, the context of a project, and the product and project life cycles in use. For more about effects of the project life cycle on the product information, see Section 1.3.4.5.

In general, most stakeholders want to contribute to or know about all the product information in scope. However, the level of detail in which the product information is explored and documented may vary according to stakeholder characteristics. Stakeholders who are experts in the domain of the project, located near one another, or in frequent communication with one another might require less detail when defining the product information. For stakeholders who are less familiar with the project domain, are physically distributed, or speak different languages, more detail may need to be included when defining product information.

The context of a project may vary with regard to the depth to which product information is defined. For example, for projects that are high risk or of high value, additional effort could be made to define highly detailed product information. Products that are regulated or are required to adhere to specific government regulations require detailed product information. Similarly, components of a project that are high risk may warrant more levels of depth in the product information than lower-risk components. When requirements are going to be reused by other projects, used to create training materials, or used to facilitate test case generation, it could be valuable to create more detailed requirements. For small and simple projects or small teams, fewer details in the product information may be sufficient. Expected high turnover in personnel or team distribution may warrant creating detailed product information.

1.3.4.4 BUSINESS ANALYSIS DELIVERABLES TAILORING

Business analysis processes produce deliverables that can be tailored. The deliverables, what they contain, and the degree of formality with which they are described vary based on the selected project life cycle and other project characteristics. Business analysis planning includes identifying the types of deliverables expected to be produced and considers maintenance, storage, and access needs.

When tailoring the deliverables, the business analyst needs to think through which stakeholders will consume them, what product information those stakeholders need to see, the level of understanding a stakeholder may have on the topic, and what will be the easiest format for the stakeholders to use. The objective is to produce deliverables that reflect what will be best for the stakeholders.

The deliverables may take the form of documents or they may exist in tools, such as requirements management tools, modeling tools, or agile tools. Typical business analysis deliverables and their most common forms are described in Table 1-4.

1.3.4.5 ADAPTING BUSINESS ANALYSIS TO THE PROJECT LIFE CYCLE

While many factors influence how or why business analysis is tailored, the primary reason to tailor business analysis is to enable the business analysis practices to work within a specific project life cycle. The project life cycle refers to the phases through which a project passes from its initiation to its closure. Project life cycles can range along a continuum from adaptive life cycles—for example, agile approaches—to predictive life cycles, such as waterfall approaches. The business analysis approach or methodology is adapted to whichever project life cycle is being followed. This section refers to adapting business analysis practices, tools, techniques, procedures, and rules to fit within the confines of the adaptive or predictive approach used.

Within the scope of the standard and guide, all the processes are applicable for use in any project life cycle; however, the timing and degree of depth with which they are performed may vary based on the project life cycle. For example, in a waterfall approach, the Conduct Elicitation process is performed mostly in the early phases of the project. This does not mean that elicitation will not occur in later phases, just less of it. In an agile approach, elicitation is performed repeatedly in each iteration throughout the entire project.

The project life cycle drives which product information is applicable or, at the very least, how the product information is named. For example, predictive life cycles tend to refer to requirements, whereas adaptive life cycles refer to this same product information by the names of user stories and acceptance criteria. However, all project life cycles will likely elicit business objectives and create models. For this reason, this guide provides specific names such as business objectives or models when the type of business analysis information being discussed is common across life cycles or specific to a process; otherwise, the guide uses the term product information.

The project life cycle also influences when product information is created, consumed, or modified. For example, in predictive approaches, the Conduct Elicitation process could first focus on business objectives and then on stakeholder and solution requirements—all in the early phases of the project. In later phases of the project, elicitation activities may be used primarily to correct errors or uncover missing product information. In adaptive approaches, while business objectives may have been elicited in earlier iterations, product information such as user stories and acceptance criteria are elicited in every iteration until nearly the end of the project.

The tools and techniques used on a given project also vary based on the project life cycle. Some tools and techniques are applicable in any project life cycle, while others are more specific to certain life cycles, which will be discussed in the tools and techniques descriptions where applicable. It is always acceptable to use any tool or technique in any project life cycle if it helps further the business analysis.

Section 3 provides more detail about the different knowledge, skills, and personal qualities of a business analyst. However, generally speaking, business analysis competencies are applicable across all project life cycles. For example, although the choice of necessary analytical skills will vary based on the project, any of the competencies can be used in any project life cycle. While it is likely that the methods and frequency of communication could vary by project life cycle or stakeholder group, the communication skills are applicable within any life cycle. Finally, although different tools may be used in different project life cycles, the general skills related to tool knowledge are always applicable.

Table 1-5 describes the aspects of business analysis that could be tailored as well as a description of how that aspect would vary. A version of this table is included within each process description throughout the guide and explains how that process is commonly tailored for an adaptive and predictive life cycle. Like the rest of this guide, these tables are intended as a guideline or reference, because any specific project in a particular life cycle could vary from the information provided in this table. For example, when an adaptive approach is being used, it does not mean all of the recommended tailoring listed within that process for adaptive life cycles needs to be followed. It may be appropriate to use some predictive recommendations on an adaptive project because of other considerations the project team is dealing with. Similarly, some predictive tailoring descriptions imply a heavy and formal process, but predictive life cycle projects can use a lightweight approach that follows adaptive life cycle elements.

Table 1-5. Examples of Tailoring in Business Analysis

Aspects to Be Tailored	How the Aspect Is Tailored for Adaptive or Predictive Life Cycles
Process Name	The process may be called by different names in different project life cycles.
Approach	The approach could be tailored according to the level of formality to be used and the timing for performance of the activity. For example, the project life cycle may suggest when product information is created, reviewed, or refined, the frequency for those activities and whether official sign-offs are required. The approach is described using the names of the product information that are specific to the life cycle.
Deliverables	For each of the differing life cycles, the work products and specific deliverables produced by the process may vary in name and level of formality.

---

¹ The numbers in brackets refer to the list of references at the end of this guide.