2

THE ENVIRONMENT IN WHICH BUSINESS ANALYSIS IS CONDUCTED

2.1 OVERVIEW

This section examines the influences within the environment and organization where business analysis is performed and discusses how these influences impact the manner in which business analysis is conducted.

The two major categories of influences discussed in this section are enterprise environmental factors and organizational process assets:

• Enterprise environmental factors (EEFs). Conditions not under the immediate control of the team that influence, constrain, or direct the portfolio, program, or project. In business analysis, these conditions influence, constrain, or direct how business analysis is conducted and are not under the control of business analysts. Any given EEF can be external or internal to an organization.
• Organizational process assets (OPAs). The plans, processes, policies, procedures, and knowledge bases specific to and used by a performing organization.

EEFs and OPAs are implicit inputs to all business analysis processes. As noted in Section 1, an important distinction between business analysis and project management is that the primary focus of project management is the project, while the primary focus of business analysis is the product. A consequence of business analysis being product focused is that some aspects are fairly independent of these influences and others are highly dependent on the influences. The following are examples of each:

• Independent of influences. Simply put, analysis is analysis. The same thought patterns used to think about a solution are used before or during a project or when considering the solution as part of a portfolio or program. In this guide, these thought processes are categorized as processes within Process Groups and Knowledge Areas and they occur whether:

• The solution is highly complex or simple;
• The solution is ultimately operationalized in a highly regulated environment or in a small start-up;
• The project teams are colocated or regionally dispersed (large or small);
• The projects in which the solution is conceptualized, designed, and developed are executed with a predictive, adaptive, or hybrid life cycle; or
• The eventual solution implementation necessitates building something physical, building software, devising or revising business processes, or any combination thereof.

• Dependent on influences. Influences often dictate which project life cycle or life cycles are used to develop or enhance products, how business analysis processes are named, the methodology used to conduct them, the depth and style, and optionally, product information documentation, the level of formality of deliverables, and the collaboration style of a team as it works together to conduct analysis. How to bundle, slice, or split the delivery of a solution depends on environmental influences as well. For example, different deliverables or levels of collaboration could be appropriate in business analysis within a highly regulated environment as compared to a small start-up. The teams' physical working locations could change how much detail is documented about the product information and how frequently a team communicates.

Influences on how business analysis is conducted may be categorized in a similar but not identical way as influences on projects. Figure 2-1 shows the breakdown of influences into EEFs and OPAs.

EEFs influence how business analysis is conducted, and can originate from either within or outside of the enterprise. Refer to Section 2.2 for additional information on EEFs.

OPAs are internal to the enterprise. These may arise from the enterprise itself, a portfolio, a program, another project, or a combination of these. Refer to Section 2.3 for additional information on OPAs.

In addition to EEFs and OPAs, organizational systems can also impact how business analysis is conducted. System factors that impact the power, influence, interests, competencies, and political capabilities of the people to act within the organizational system are discussed further in Sections 2.4.3 and 2.4.4.

A challenge for those who are responsible for business analysis is to choose appropriate business analysis processes to perform in support of product development while working within the framework of an organization's environmental and organizational influences.

2.2 ENTERPRISE ENVIRONMENTAL FACTORS

This section examines individual EEFs. Representative examples of each factor are listed along with the areas of business analysis that are impacted. Although an individual factor may influence one or more specific aspects of business analysis, the cumulative influence of all the environmental factors on the choice of the project or product life cycle drives how they impact business analysis.

2.2.1 EXTERNAL TO THE ORGANIZATION

The following categories of EEFs are external to the organization and can impact how business analysis is performed:

• Marketplace conditions. Examples include competitors, market share, brand recognition, trademarks, and customer expectations. Marketplace conditions may impact the timing, duration, and segmentation of business analysis processes in support of product development.
• Social and cultural influences and issues. Examples include organizational politics, codes of conduct, ethics, and perceptions. Social and cultural considerations may impact the formality of business analysis efforts and how and when those responsible for business analysis collaborate with their stakeholders.
• Stakeholder expectations and risk appetite. Examples include organizational culture, organizational politics, governance structure of the organization, service levels, and customer representation. Like social and cultural considerations, stakeholder expectations and risk appetite may impact the rigor and formality of business analysis efforts and the style of collaboration with stakeholders.
• Legal and contractual restrictions. Examples of legal restrictions include country, local, or industry-specific laws and regulations related to security, data protection, business conduct, employment, and procurement. Examples of contractual restrictions include relationships with companies that provide products and/or resources to build or enhance products and the indirect relationship between an organization and the union that represents some or all of its workers (in some cases, this includes business analysts). Legal and contractual restrictions may substantially impact the formality and style of and storage, access, and audit requirements for business analysis documentation as well as how business analysis processes are conducted.
• External professional standards for business analysis. Examples include professional development organizations, such as PMI, which are setting the expectations and standards for how to conduct business analysis. These professional standards are resources for confirming or adjusting organizational business analysis practices.

The following categories of external EEFs primarily provide sources of additional information to be analyzed to support product development and enhancement. When included as part of a project, these information sources may simplify or shorten business analysis efforts in some situations, and in other situations, may increase complexity or scope:

• Commercial databases. Examples include benchmarking results, standardized cost estimating data, industry risk study information, and risk databases. Reuse of this type of information could shorten business analysis efforts.
• Academic research. Examples include studies, publications, and benchmarking results. As with commercially available information, reuse of academic research results could shorten business analysis efforts.
• Government or industry standards. Examples include regulatory agency regulations and standards related to products, production, environment, quality, and workmanship. Consideration of government or industry standards could substantially increase or decrease the complexity of the business analysis effort. Government or industry standards about the process may also influence how business analysis is conducted.
• Financial considerations. Examples include currency exchange rates, interest rates, tariffs, and geographic location. Any of these considerations may impact the scope of a business analysis effort if they need to be considered to develop or enhance the product.
• Physical environmental elements. Examples include working conditions, weather, and construction constraints caused by previous construction or geology. Consideration of the physical environment may impact the scope or complexity of a business analysis effort.

2.2.2 INTERNAL TO THE ORGANIZATION

The following EEFs are internal to the organization. They are listed along with representative examples for each factor. Most organizations are impacted by more than one of these influences. While each could have an impact on its own if it were the only influence involved, the impact made is usually the result of the cumulative effect of multiple EEFs:

• Organizational culture, structure, and governance. Examples include vision, mission, values, beliefs, cultural norms, leadership style, hierarchy and authority relationships, organizational style, ethics, and code of conduct. Additionally, the history or experience of the organization with the product under evolution or with the methods used in prior business analysis efforts can color the acceptance of the current business analysis approach. Ultimately, these factors—especially organizational values and beliefs—are the basis for the presence or absence of many of the other internal environmental factors of an organization. As such, organizational culture, structure, and governance are among the most significant internal factors that impact how business analysis is conducted. Organizational structure and governance frameworks are explored further in Sections 2.4.2 and 2.4.3.
• Stakeholder expectations and risk appetite. These considerations are internal as well as external EEFs. Examples include organizational culture, organizational politics, governance structure of the organization, service levels, and customer representation. Like social and cultural considerations, stakeholder expectations and risk appetite may impact the rigor and formality of business analysis efforts and the style of collaboration with stakeholders.
• Geographic distribution of facilities and resources. Examples include factory locations, virtual teams, shared systems, and cloud computing. Geographic distribution impacts how and when business analysts collaborate.
• Market research and experimentation. Examples include considering real customer feedback, product experiments, and prototyping feedback. Like external EEFs, information from these initiatives may simplify or shorten business analysis efforts, especially when they have been performed as part of a separate effort.
• Architecture and infrastructure. Enterprise architecture is a collection of the business and technology components needed to operate an enterprise. Business architecture is a collection of the business functions, organizational structures, locations, and processes of an organization, including documents and depictions of those elements. The business architecture is usually a subset of the enterprise architecture and is extended with the applications, information, and supporting technology to form a complete blueprint of an organization. This blueprint includes the enterprise's existing inventory of purchased or built software used in its business operations. Infrastructure components are either part of a physical architecture or a software architecture. Infrastructure components include existing facilities, equipment, organizational telecommunications channels, information technology hardware, availability, and capacity. Architecture and infrastructure factors are taken into account during business analysis.
• Information technology software. Examples that impact how business analysis is conducted include the availability of tools to support business analysis, such as conferencing tools, modeling tools, and product requirements or backlog management tools. For more information about tools used in business analysis, see Section X3.6.
• Interest and level of commitment to reuse the results of business analysis. How business analysis is conducted and the tools used to support it are impacted by whether or not the organization intends to leverage the analysis results of past products as a starting point to enhance those products or to consider or create future products. Some organizations have little interest or commitment to reuse the results of business analysis. For organizations that practice reuse of business analysis results, this may occur at a team level, a business unit level, or an enterprise level. An organization's approach to reuse results impacts how business analysis deliverables are structured, stored, and shared when the project is completed.
• Human resources management policies and procedures. Examples include staffing and retention guidelines, employee performance reviews and training records, reward and overtime policy, cost per skill type, and time tracking. Human resource management policies and procedures may determine which individuals can conduct business analysis or may impose restrictions on who can perform the work. These policies and procedures may also impact the number of projects assigned concurrently to any one person who is responsible for business analysis. Reward and incentive policies can indirectly impact the way business analysis is conducted by influencing how stakeholders, subject matter experts, and other project team members prioritize their availability to participate in a business analysis process. For example, when busy subject matter experts are needed for business analysis for a new product, but are incentivized based on their responsibilities for other product development or operational areas, they may be less available for business analysis of that new product.
• Resource policies, procedures, and availability. Examples include contracting and purchasing constraints, certified providers and subcontractors, and collaboration agreements.
• Employee capability. Examples include existing human resources expertise, skills, competencies, and specialized knowledge. Overall skills impact the level of business analysis maturity of the organization as a whole, which has a direct impact on the quality of business analysis at the project level. The experience level of those conducting business analysis can impact the tools and techniques chosen as well as the number of individuals assigned to work together on business analysis tasks and whether those individuals need coaching support. For more information about business analyst competencies, see Appendix X3.
• Security policies, procedures, and protocols. Examples include access protocols for facilities and data, protection of personal and customer information, proprietary information policies, procedures for personal security, and levels of confidentiality.

2.3 ORGANIZATIONAL PROCESS ASSETS

Organizational process assets (OPAs) are the plans, processes, policies, procedures, and knowledge bases specific to and used by a performing organization. These assets influence how business analysis is conducted.

In general, OPAs include any work product, practice, or knowledge from any or all of the organizations involved in the project that can be used to perform or govern a project. Examples of an organization's OPAs include templates, tools, methodologies, or internally and externally developed standards in response to regulatory constraints that the organization wishes to use across projects. Process assets also include the organization's knowledge bases, such as lessons learned and results from retrospectives and other historical information. For business analysis, OPAs may additionally include the actual results of prior business analysis efforts, such as enterprise-wide, locally shared, product-specific, or project-specific requirements and models.

OPAs are implicit inputs to all business analysis processes. For example, during business analysis planning, decisions may be made about which types of OPAs should be used while conducting business analysis. During the business analysis execution processes, specific OPAs may be selected for use. Because OPAs are internal to the organization, the project team members may be able to update and add to the organizational process assets as necessary throughout the project.

Organizational process assets may be grouped into three categories:

• Business analysis processes, policies, and procedures;
• Corporate knowledge bases; and
• Team and subject matter expert knowledge.

Generally, business analysis processes, policies, procedures, and templates are not updated as part of the project work in support of creating or modifying a product. Updates are usually established by a global organizational function, such as a business analysis center of excellence, business analysis community of practice, business analysis shared service organization, or possibly a project management office (PMO). Some organizations encourage teams to tailor copies of templates and other assets to meet the needs of a project; other organizations require such assets to be used without modification unless they undergo an approved organization-wide change. In any event, updates to organizational business analysis processes, policies, and procedures can be applied by following the appropriate organizational change management processes.

Corporate knowledge base assets are updated throughout a project with information about business analysis performance and product information. For example, business analysis performance information from lessons learned and retrospectives and product requirements documentation and models are continually updated throughout a project. Many organizations use business analysis performance information as an input for evolving business analysis processes, policies, and procedures. In organizations with an interest and commitment to reuse the results of business analysis, product requirements and models can be used to seed projects to enhance existing products or develop new ones.

Team and SME knowledge evolves and grows over time. As team members and SMEs integrate new learnings and insights into their own personal knowledge base, the hope is that they will find ways to share that knowledge rather than using it to become “indispensable.”

2.3.1 PROCESSES, POLICIES, AND PROCEDURES

As noted earlier, these OPAs are used as needed in support of the product life cycle. An organization's business analysis process, policy, and procedures include but are not limited to the following:

• Guidelines and criteria. These include the organization's set of standard processes and procedures and deliverables that satisfy the specific needs of a product and project.
• Specific organizational standards. These include policies, such as human resources policies, health and safety policies, security and confidentiality policies, quality policies, environmental policies, and audit policies.
• Project life cycles. As noted in Section 1.3.4.5, project life cycles can significantly impact the names of business analysis processes and deliverables, the formality with which they are documented, as well as when business analysis is conducted and which analysis techniques are used. They can also impact who is responsible for conducting business analysis and how much analysis to conduct. Keep in mind that organizations may use more than one life cycle approach to develop or enhance a given product, which may add an additional level of complexity to conducting business analysis.
• Templates. Examples include but are not limited to templates for business cases, business analysis plans, product requirements, use cases, user stories, backlog lists, models, risk registers, and traceability matrices.
• Change control procedures for product requirements and other product information. These procedures include the steps by which business analysis standards, policies, plans, and procedures or any business analysis product or project documents are to be modified, and how any changes are to be approved and validated.
• Requirements management tool procedures. Examples include procedures for the use of requirements management repositories, backlog management tools for product requirements, or traceability tools, as well as the configuration of such tools—whether out-of-the-box, customized, or internally developed—to support the procedures.
• Financial controls procedures. Examples include standard contract provisions that may impact how business analysis is conducted.
• Issue and defect management procedures as applied to product requirements and other product information. Examples include defining issue and defect controls, issue and defect identification and resolution, and action item tracking, along with the procedures for using any tracking tools.
• Organizational communication requirements as applied to business analysis processes. Examples include specific communication technology available, authorized communication media, record retention policies, videoconferencing, remote collaboration tools, and security requirements.
• Procedures. Examples include procedures for prioritizing, verifying, and approving product requirements.
• Risk management templates. Templates are used for identifying product risks.
• Standardized guidelines. Guidelines may include work instructions, proposal evaluation criteria, and business analysis performance measurement criteria.
• Project closure guidelines or requirements. Examples include cumulative information from lessons learned and retrospective sessions, final project audits, project evaluations, product validations, acceptance criteria, and knowledge transfer.

2.3.2 CORPORATE KNOWLEDGE BASE

In its discussion about managing project knowledge, Section 4.4 of A Guide to the Project Management Body of Knowledge (PMBOK^® Guide) – Sixth Edition [5] makes a distinction between explicit knowledge and tacit knowledge. Explicit knowledge can be readily codified using words, pictures, and numbers. Tacit knowledge is personal and difficult to express, such as beliefs, insights, experience, and know-how. The PMBOK^® Guide further states that tacit knowledge has context built in, but is very difficult to codify. It resides in the minds of individual experts or in social groups and situations, and is normally shared through conversations and interactions between people.

Much of the explicit knowledge elicited and analyzed by business analysts is stored in corporate knowledge bases, also known as repositories. In some organizations, all or part of the explicit knowledge elicited and analyzed by business analysts may be shared in conversations and interactions between people, along with tacit knowledge. For business analysis in such organizations, team members and subject matter experts act as living repositories. For additional information about team and SME knowledge, see Section 2.3.3.

Corporate knowledge repositories are used while conducting business analysis to store and retrieve product requirements and other product information and business analysis practices. These repositories can be used to research and understand as-is products and as-is business practices, procedures, and problems. They include but are not limited to the following:

• Business knowledge repositories. Contain versioned project and product documents, such as locally shared, enterprise-wide, product-specific, or project-specific product requirements and models. For more information about the types of requirements and models that may be included in a business knowledge repository, see Sections 7.2 and 7.3. As-built documentation is analysis and design documentation that has been updated to correspond to the released solution, and can also be considered part of the business knowledge repository. For some organizations, business knowledge is stored in requirements management tools or modeling tools; others may store this information in project folders and files.
• Configuration management knowledge repositories. Contain the versions of software and hardware components and baselines of all performing organizational standards, policies, and procedures.
• Historical information and lessons learned knowledge repositories. Examples include project records and documents relating to business analysis performance, project closure information related to business analysis, information regarding both the results of previous project and product selection decisions, previous business analysis performance information, and information from risk management processes.
• Issue and defect management data repositories. Contain issue and defect status, control information, issue and defect resolution, and action item results. In some organizations, issues and defects may be tracked and managed separately.
• Data repositories for metrics. Include metrics defined for collecting and sharing measurement data on business processes and products.

2.3.3 TEAM AND SUBJECT MATTER EXPERT (SME) KNOWLEDGE

No matter what life cycle is used, some product information may not be fully and/or formally documented. As noted in Section 1, product requirements and other product information may be stored in a variety of forms such as tools, documents, notes, emails, and in the minds of subject matter experts. For business analysis, SMEs are a rich source of information, insights, and expectations for a future state. Long-time members of product development or product enhancement teams may also have knowledge that is not formally documented; in some sense, these team members become SMEs themselves. Solutions developed using any life cycle approach, but especially adaptive life cycle approaches, often use conversations to elicit, elaborate, and analyze product requirements. Though adaptive life cycles may also use lightweight documentation, such as user stories and models, to serve as reminders to have those conversations and may use sketches of lightweight models as reminders of the results of those conversations, some of the product information may still reside in people's minds. Product teams have the responsibility for transferring the product knowledge to the newest team members, so that the team itself becomes a living and self-sustaining repository of product knowledge.

2.4 THE IMPACT OF ORGANIZATIONAL SYSTEMS ON HOW BUSINESS ANALYSIS IS CONDUCTED

2.4.1 OVERVIEW

Section 2.4.1 of A Guide to the Project Management Body of Knowledge (PMBOK^® Guide) – Sixth Edition [5] defines a system as a collection of various components that together can produce results not obtainable by the individual components alone. It notes that an organizational system is composed of organizational components, which are identifiable elements within an organization that provide a particular function or group of related functions. The interaction of the various system functional components creates the organization's capabilities and influences its culture.

Organizational systems impact how business analysis is conducted by influencing:

• Choice of project life cycles that the organization uses, which is explored in Section 2.4.2;
• Type of support provided for business analysis practices and where it is located organizationally, which is explored in Section 2.4.3; and
• Collaboration with individuals in other functional areas, which is noted in Section 2.4.4 and explored further in Section 3.3.

A challenge for those who are responsible for business analysis is to leverage business analysis processes in support of product development while working within the framework of an organizational system. Regardless of these impacts, business analysis processes should be performed to effectively elicit, elaborate, and analyze product requirements and product information in support of sound decision making about solutions and to ensure that enough is known about a product so that it can be developed or enhanced properly.

2.4.2 ORGANIZATIONAL SYSTEMS, PROJECT LIFE CYCLES, AND BUSINESS ANALYSIS

Internal EEFs, especially those that are examples of organizational culture, such as values and beliefs, structure, and governance, determine many of the characteristics of an organizational system. They come into play when determining an organization's processes, policies, and procedures, including its choice of project life cycles and approaches to solution delivery. As noted in Section 1.3.4, the project life cycles and approaches to solution delivery that are chosen create likely scenarios for the formality with which business analysis is conducted and what tools and techniques are used. As mentioned in Section 1.3.4.5, the level of formality is a factor in deciding how business analysis deliverables are tailored. Typical considerations for conducting business analysis processes within adaptive and predictive life cycles can be found in the Knowledge Area process description sections of this guide.

2.4.3 HOW ORGANIZATIONS SUPPORT BUSINESS ANALYSIS PRACTICES

A recent PMI survey [3] of individuals who have a role related to business analysis found the following:

• Only 18% of respondents stated that the level of maturity in their practices is considered highly mature, optimized for continuous improvement, and established.
• An astounding 46% of all respondents believed the business analysis practices and the associated maturity level of practices are considered not mature or operating from an ad-hoc or “getting started” perspective.

Organizations that establish groups to support business analysis tend to evolve to a high level of business analysis capability. They tend to create high-quality standards/governance for business analysis practices and deliverables; facilitate resource sharing, methodologies, tools, and techniques; and provide learning opportunities for those who are responsible for performing this work. Examples include:

• Business analysis forums or communities of practice are often informal support organizations that focus on sharing and learning. These structures enable business analysts to share practices, tips and techniques, and project experiences with one another where adoption of anything learned is optional. Many forums and communities of practice sponsor “lunch and learns” or other sharing events, and may create their own corporate knowledge base. Other communities of practice operate on a remote basis and maintain continuity through online discussions within their corporate knowledge base.
• Business analysis centers of excellence or business analysis competency centers are more formal support organizations. Coaches and mentors for business analysis may report to these organizations. In some organizational systems, they may also have a controlling role and require compliance for:

• Conducting specific business analysis processes with a specific level of formality based on how a solution or project is categorized;
• Use of specific templates, forms, and tools based on solution or project categorization; and
• Conformance to governance frameworks.

According to PMI's 2016 research, a significant number of organizations considered to have mature business analysis practices operate project management offices (PMOs) and enterprise project management offices (EPMOs). This research also confirmed that organizations with mature business analysis practices obtained more value from implemented solutions [2].

Business analysis shared services organizations take on all the support and controlling responsibilities listed above and also have a controlling role for resource management for business analysis. In some organizations, support organizations for business analysis are part of the PMO; in other organizations, they reside in a different functional area.

2.4.4 BUSINESS ANALYSIS COLLABORATION ACROSS ORGANIZATIONAL FUNCTIONAL AREAS

The functional areas and reporting relationships within an organizational structure have a significant impact on how business analysis is conducted as well as who participates in it and their level of participation. Section 3.3 explores the sphere of influence of business analysis and the many functional areas with which business analysts collaborate to support product development and enhancement. It provides further insights into the importance of the relationships between business analysts and other roles in other functional areas. This collaboration often requires being mindful of the impact imposed by organizational systems.

Business analysis requires a strong focus on the product. Individuals who are responsible for business analysis are often not the decision makers for products and projects even though they are often considered trusted advisors who use the product knowledge they have elicited and analyzed to advise and influence product decisions. These individuals recognize that they need to collaborate with others who hold other product and project roles, and who may belong to different functional areas. Ideally, collaboration between the business analyst and other roles occurs early and often, but sometimes those with critical roles have limited availability to collaborate. Insufficient collaboration for business analysis processes occurs when the priorities of individuals from different functional areas who are assigned to support the development or enhancement of a product are significantly different from the priorities of the business analysts. Insufficient collaboration may result in incomplete or inaccurate elicitation or review of product requirements, which cascades into incomplete or inaccurate analysis, and can have a profoundly negative impact on the product being developed or enhanced.

Obtaining sufficient collaboration may require extensive knowledge of the organization's systems, structures, culture, and governance framework. At the same time, successfully navigating organizational systems is often difficult, especially in large or complex organizational structures. To obtain sufficient collaboration and to work through the challenges that arise from the structure, governance, and culture of organizational systems, business analysts should closely collaborate with portfolio, program, and project managers and use their combined perspectives to build and share a strong understanding of organizational systems and how to successfully network within them in support of product, portfolio, program, and project initiatives. When the business analyst and portfolio, program, and project managers collaborate as closely as possible, navigating the organizational systems becomes a less daunting task, as each role leverages the knowledge and experience of the other for the betterment of the overall project.