1

 

INTRODUCTION

This standard covers the foundational concepts of business analysis and how business analysis supports organizational strategy, governance, portfolio management, program management, project management, and the project environment, as well as business analysis's contribution to achieving business outcomes. These relationships are explained throughout the guide and standard through the use of Business Analysis Process Groups, Knowledge Areas, processes, mapping tables, collaboration points, and other tools. It also includes information on the role of the business analyst, differing project life cycles, and diverse stakeholders. This standard describes the processes used to perform business analysis within programs and projects and to support portfolio management.

Section 1 provides key concepts and contextual information about business analysis. Sections 2 through 7 provide definitions for each of the six Process Groups; describe all of the business analysis processes within those groups; and identify the key benefits, inputs, and outputs for each.

This standard serves as the foundation and framework for The PMI Guide to Business Analysis [2], referred to herein as the guide. The guide expands on the information in this standard by providing a more in-depth discussion of the context, environment, and influences on business analysis. In addition, the guide provides descriptions of the inputs and outputs; identifies tools and techniques used to perform each process; and discusses key concepts, emerging trends, and opportunities for collaboration between business analysts and those with whom they collaborate within each Knowledge Area.

1.1 WHAT IS A STANDARD?

A standard is established by an authority, by custom, or by general consent as a model or example. This standard provides a foundational reference for anyone performing business analysis in support of portfolios, programs, projects, and operations. The Standard for Business Analysis is a global standard that has been developed using a process based on the concepts of consensus, openness, due process, and balance, and it is meant to define good practices for most portfolios, programs, or projects most of the time.

1.2 FRAMEWORK FOR THIS STANDARD

This standard describes the nature of business analysis processes in terms of the integration among processes, their interactions, and the purposes they serve. The processes included in this standard define the activities and outcomes of business analysis, regardless of the job title or role of those performing the work. This standard acknowledges that some business analysis work is performed outside the confines of a project in support of portfolio and program management and is a blend of business analysis activities that support the formulation of organizational strategy and its fulfillment through successful project delivery. The business analysis activities presented in this standard are applicable for all project life cycles, from predictive to adaptive and the various approaches in between. The activities are applicable across industries and all types of organizations (e.g., for-profit, nonprofit, and government organizations, etc.).

1.3 BUSINESS ANALYSIS AND REQUIREMENTS

In this standard and guide, the term business represents the area of the organization that possesses the problem or opportunity to be investigated. The investigation and subsequent analysis is performed using 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.

A requirement is defined as a condition or capability that is necessary to be present in a product, service, or result to satisfy a business need. Whether they are expressed as requirement statements, use cases, user stories, backlog items, or visual models, a clear understanding of 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 use a solution or view 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.

1.4 THE BENEFITS OF BUSINESS ANALYSIS

PMI research conducted as part of the 2017 Pulse of the Profession^® In-Depth Report Success Rates Rise: Transforming the High Cost of Low Performance [3] revealed that requirements-related issues continue to remain a primary cause of project failure (39% in 2017, which was up from 37% in 2014 and 32% in 2013). Research also indicates that when business analysis is poorly sized, performed inadequately, or sparsely considered, there is a direct impact to a team's ability to deliver to the commitments made. As a result of the direct impact that business analysis has on program and project success, there is substantial interest across organizations to fully understand the best usage of business analysis, which will enable successful portfolio, program, project, and business outcomes.

The same PMI research validates that when business analysis is properly accounted for and executed on programs and projects, the following benefits are achieved:

• Requirements are well defined;
• Projects are more likely to be delivered on time, within scope, and within budget; and
• High-quality solutions are implemented that result in achieving customer satisfaction.

When business analysis is performed well, program and project outcomes are more likely to be aligned with each other and with organizational strategies. Also, stakeholder participation and engagement increase, making it easier for the product team to obtain buy-in on the requirements, design, and ultimately, the final solution. Business analysis enables the development of high-quality solutions that deliver value to organizations. With sufficient business analysis, unnecessary legal and regulatory risks can be mitigated as program or project noncompliance issues are reduced. As repeatable business analysis processes are used, organizations can develop improved business analysis skills and competencies that are reusable to support future portfolios, programs, and projects.

1.5 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 to 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. Business Analysis Process Groups are explained in more detail in Section 1.12 on Business Analysis Process Groups.

Table 1-1 compares business analysis with project, program, and portfolio management.

1.6 THE ROLE OF THE BUSINESS ANALYST

Those who perform business analysis are commonly called business analysts, but there are business analysis professionals with other job titles who also perform business analysis activities. Some business analysis professionals are specialized and therefore have a title that reflects that area of their competency; strategic business analyst, data analyst, process analyst, or systems analyst are a few examples of these roles. How an organization uses business analysis resources; where these resources functionally report; and the type of industry, type of project, and type of project life cycle being used are some of the factors that influence how organizations title those who have the responsibility for business analysis.

There are also many roles where business analysis is performed as a part of the role but is not necessarily the only responsibility. Enterprise and business architects; portfolio, program, and project managers; and operational analysts are a few examples. The business analysis processes, tools, and techniques presented in the guide and this standard are relevant to these individuals, too. Because there are many titles and variations of business analysis roles in use, the guide and this standard use the phrase business analysis professional over business analyst. When the term business analyst is used, it is done for the sake of brevity and should always be considered a reference to anyone performing business analysis, regardless of the title a person holds or the percentage of job function spent on the work. The objective of this guide and standard is to establish an understanding about business analysis and not job titles.

This standard establishes an understanding of business analysis by presenting 35 business analysis processes to explain the work and discussing these in context to the Process Groups and Knowledge Areas to which each relates.

1.7 THE DIFFERENCE BETWEEN PROJECT MANAGERS AND BUSINESS ANALYSTS

Project managers and business analysts serve in critical leadership roles on programs and projects. When these roles partner and collaborate effectively, a project has a greater chance of being successful. While collaboration is key, many projects and organizations struggle with or confuse project manager and business analyst responsibilities. These struggles are compounded when the project manager and business analyst report into different functional units, or when these roles are from different organizations as is often the case when there is a client-supplier relationship.

This standard describes the work of business analysis, regardless of the role performing it. For organizations and projects that separate business analysis responsibilities from project management responsibilities, The PMI Guide to Business Analysis provides additional details to identify the areas of perceived overlap and clarify the areas of confusion that exist between project managers and business analysts. While several of the business analysis processes identified in this standard appear to have the same process names as those in A Guide to the Project Management Body of Knowledge (PMBOK^® Guide) [4], they are not the same. For example, the PMBOK^® Guide – Sixth Edition includes Section 4.1 on Develop Project Charter, and this standard includes the process performed to support this work, that is, Section 3.1 on Support Charter Development.

Project managers are responsible for the successful delivery of the project, while business analysts are responsible for successful delivery of the product. Therefore, the processes presented and discussed in this standard are product focused. Sometimes, project management and business analysis activities overlap, which is why project managers and business analysts work closely together. Products, or enhancements to products, are delivered by employing project life cycles. For example, project managers are responsible for stakeholders remaining engaged across the project, and business analysts are responsible for stakeholders remaining engaged throughout the business analysis processes. The processes identified in this standard are intended to reduce the confusion and perceived overlap between these two roles.

1.8 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-1 illustrates the relationship between product and project life cycles, showing 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, for example, 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 life cycles 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.9 HOW ITERATIVE AND ADAPTIVE LIFE CYCLES AFFECT BUSINESS ANALYSIS ROLES

Over the past 20 years, the emergence of iterative and adaptive project life cycles has introduced new ways to address product complexity and the ever-increasing pace of change by delivering segments of solutions to stakeholders for early and frequent feedback.

Adopting these project life cycles alters the notion that an individual assigned to a project performs only the role that is his or her specialty. Whether dealing with iterative or scrum projects with time-boxed iterations or sprints or working with projects using the Kanban approach, with continuous flow and work-in-progress limits, the team commits to demonstrating completed features and capabilities to the stakeholders at the end of each delivery. In situations where a project team using a scrum approach confronts a negative risk that the selected features and capabilities cannot be completed within the time-box, all team members will pitch in to make sure the work gets done, even if that means doing work not usually associated with their roles. For teams using a Kanban approach with continuous flow and work-in-progress limits, if the amount of work that needs to be completed exceeds the capacity of the individuals who normally perform that work, one option is for all team members to pitch in; the other is for the flow to be interrupted until the individuals who normally perform that work can take on more work. This means that individuals assigned to iterative or adaptive projects are either part of cross-functional teams or are considered specialty resources. On cross-functional teams, every team member can typically play more than one role. Specialty resources possess a particular skill, such as business analysis, which they provide to the team by serving as practitioners, mentors, or subject matter experts. With the help of other team members who can advise or mentor them, specialty resources also take on other roles that are less familiar to them to complete the work to which the team is committed.

Additionally, for adaptive approaches such as scrum and Kanban, from the perspective of business analysis, the entire team is responsible for the work of eliciting and analyzing requirements, whether or not the team has an individual who holds the role of business analyst. One or more people on the team should have sufficient business analysis skills to help the team identify and refine the requirements, so that the team can develop a solution that will satisfy those requirements.

1.10 TAILORING THE BUSINESS ANALYSIS PLAN AND PROJECT DOCUMENTS

Business analysis involves selecting the appropriate processes, inputs, and outputs represented in this standard for use on a specific portfolio, program, or project. Likewise, tools and techniques can be selected from The PMI Guide to Business Analysis. 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 is required for every business analysis effort. The format of inputs and outputs listed within each process may also be tailored. For example, in the guide, the output of the Define and Elaborate Requirements process is requirements and other product information. Requirements and other product information can 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.

Because this standard is adapted to support the characteristics of a portfolio, program, or project, 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.

The business analysis deliverables that are produced from a process—and the degree of formality with which each is detailed and maintained—will depend on the selected project life cycle and other project characteristics, for example, size of the project, complexity of the solution, and industry in which the solution will be used. During business analysis planning, the business analyst identifies the types of deliverables expected to be produced and considers the maintenance, storage, and access needs for each.

1.11 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 standard, the Knowledge Areas contain the set of processes that the work of business analysis comprises. Although they are related, the processes do not prescribe a sequence or order. This standard 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-2 illustrates the relationships that exist among the six Business Analysis Knowledge Areas. 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 processes in the Elicitation, Analysis, and Traceability and Monitoring Knowledge Areas tend to be used concurrently. The results obtained by using the processes in the Needs Assessment Knowledge Area are the basis for work conducted using the processes in Elicitation, Analysis, and Traceability and Monitoring. The processes in Elicitation, Analysis, and Traceability and Monitoring 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.

1.12 BUSINESS ANALYSIS PROCESS GROUPS

Within this standard, the nature of business analysis is described through 35 processes distributed across the six Business Analysis Process Groups. Each Process Group is independent of the application area or industry in which it is performed. Processes are not one-time events, and processes can overlap throughout the project and product life cycles.

The six Business Analysis Process Groups presented in this standard are defined as follows:

• Defining and Aligning Process Group. The processes performed to investigate and evaluate the viability of 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-3 depicts the six Business Analysis Process Groups within the product and project life cycles. This figure 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 portfolio or program management. The left side of Figure 1-3 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.

The output of one process may become an input to another process, a project deliverable, or supporting information, leveraged by portfolio and program management. The definitions of each process, which follow the more detailed descriptions of each Business Analysis Process Group, include a list of typical inputs and outputs.

Process Groups are not project phases or product life cycle phases. When the project or product life cycle is divided into phases, Process Groups may interact within each phase. In fact, it is possible that all Process Groups could be conducted within a phase, as illustrated in Figure 1-3. As projects are separated into distinct phases or subcomponents, such as concept development, feasibility study, design, prototype, build, test, and so forth, all of the Process Groups are normally repeated for each phase until the completion criteria for that phase have been satisfied.

Individual processes are often iterated several times throughout the product life cycle and even within a project. They may require that decisions or deliverables produced early on be revisited and revised. The timing and duration of the iterations and interactions among processes will vary based on the selected project life cycle. The processes presented in this standard provide a comprehensive picture of the activities that business analysis comprises and are transferable to all delivery methods, from predictive to adaptive and variations in between.

There are patterns for how the Process Groups are used in support of different project delivery methods:

• Predictive life cycles. For predictive life cycles, typically most of the Business Analysis Initiating, Planning, and Executing Process Group activities are conducted earlier in a project, in the front end, along with any defining and aligning that has not been completed prior to project approval. For predictive life cycles, the Business Analysis Releasing Process Group activities are conducted near the end of a project.
• Adaptive life cycles. For adaptive life cycles, all of the Process Groups are focused on the segment of product features or functionality that the team has committed to deliver in each iteration. Each iteration incrementally delivers a segment of a product for early feedback. The feedback from that delivery can impact the commitment priorities for the next iteration. Each iteration is not a mini-predictive life cycle, but rather encompasses whatever level of business analysis effort is necessary for the team to make its commitment. Consequently, the Business Analysis Execution Process Group activities are exercised the most during each iteration. Some teams working with an adaptive life cycle use some of the time within an iteration to look ahead and start Business Analysis Execution Process Group activities for product backlog items that are likely to be delivered in the next one or two iterations.

The following figures show a typical level of effort expended during each Business Analysis Process Group over the course of a project. Figure 1-4 depicts the level of effort for a project following a predictive life cycle and Figure 1-5 provides the level of effort for a project following an adaptive life cycle.

Table 1-2 reflects the mapping of the 35 business analysis processes that are within the six Business Analysis Process Groups and the six Knowledge Areas. Within this standard, processes are numbered according to the sequence in which they appear within each Process Group. Within the guide, processes are numbered according to the sequence they appear within each Knowledge Area. For a mapping of Knowledge Area processes to Process Group processes, refer to Appendix X4.

The business analysis processes are shown in the Process Group where most of the activity takes place. For example, when a process that normally takes place in the Planning Process Group is revisited in the Executing Process Group, it is not considered a new process. The iterative nature of business analysis means that processes from any Process Group may be used throughout the product life cycle. For example, when managing stakeholder engagement in the Monitoring and Controlling Process Group, 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 Stakeholder Engagement and Communication Approach process.

^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.