3 Business Analysis Planning and Monitoring

Business Analysis Planning and Monitoring

The Business Analysis Planning and Monitoring knowledge area tasks organize and coordinate the efforts of business analysts and stakeholders. These tasks produce outputs that are used as key guidelines for the other tasks throughout the BABOK® Guide.
The Business Analysis Planning and Monitoring knowledge area includes the following tasks:
• Plan Business Analysis Approach: describes the planning of business analysis work from creation or selection of a methodology to planning the individual activities, tasks, and deliverables.
• Plan Stakeholder Engagement: describes understanding which stakeholders are relevant to the change, what business analysts need from them, what they need from business analysts, and the best way to collaborate.
• Plan Business Analysis Governance: defines the components of business analysis that are used to support the governance function of the organization. It helps ensure that decisions are made properly and consistently, and follows a process that ensures decision makers have the information they need. Examples of this include requirements management, business analysis risk management, and allocation of business analysis resources.
• Plan Business Analysis Information Management: defines how information developed by business analysts (including requirements and designs) is captured, stored, and integrated with other information for long-term use.

Business Analysis Planning and Monitoring

• Identify Business Analysis Performance Improvements: describes managing and monitoring how business analysis work is performed to ensure that commitments are met and continuous learning and improvement opportunities are realized.

The Core Concept Model in Business Analysis Planning and Monitoring

The Business Analysis Core Concept Model™ (BACCM™) describes the relationships among the six core concepts. The following table describes the usage and application of each of the core concepts within the context of Business Analysis Planning and Monitoring.

Table 3.0.1: The Core Concept Model in Business Analysis Planning and Monitoring

Figure 3.0.1: Business Analysis Planning and Monitoring Input/Output Diagram

**

3.1 Plan Business Analysis Approach
3.1.1 Purpose
The purpose of Plan Business Analysis Approach is to define an appropriate method to conduct business analysis activities.

3.1.2 Description
Business analysis approaches describe the overall method that will be followed when performing business analysis work on a given initiative, how and when tasks will be performed, and the deliverables that will be produced.
The business analyst may also identify an initial set of techniques to use. This list may change as the initiative proceeds and the business analyst gains a deeper understanding of the change and its stakeholders.
The business analysis approach may be defined by a methodology or by organizational standards. In some organizations, elements of the business analysis approach may be standardized and formalized into a repeatable business analysis process which can be leveraged for each effort. Even where a standard approach exists, it may be tailored to the needs of a specific initiative. Tailoring may be governed by standards that define which approaches are permitted, which elements of those processes may be tailored, and general guidelines for selecting a process.
If organizational standards do not exist, the business analyst works with the appropriate stakeholders to determine how the work will be completed. For example, if the change is delivered via a project, the standards and approach may be developed during the project planning phase.
The business analysis approach should:
• align to the overall goals of the change,
• coordinate the business analysis tasks with the activities and deliverables of the overall change,
• include tasks to manage any risks that could reduce the quality of business analysis deliverables or impede task efficiency, and
• leverage approaches and select techniques and tools that have historically worked well.

3.1.3 Inputs

• Needs: the business analysis approach is shaped by the problem or opportunity faced by the organization. It is necessary to consider what is known about the need at the time of planning, while acknowledging that understanding evolves throughout business analysis activities.

Figure 3.1.1: Plan Business Analysis Approach Input/Output Diagram

**

3.1.4 Elements

.1 Planning Approach
There are various planning methods used across perspectives, industries, and enterprises. Many planning methods fit somewhere along a continuum between predictive and adaptive approaches.
Predictive approaches focus on minimizing upfront uncertainty and ensuring that the solution is defined before implementation begins in order to maximize control and minimize risk. These approaches are often preferred in situations where requirements can effectively be defined ahead of implementation, the risk of an incorrect implementation is unacceptably high, or when engaging stakeholders presents significant challenges.
Adaptive approaches focus on rapid delivery of business value in short iterations in return for acceptance of a higher degree of uncertainty regarding the overall delivery of the solution. These approaches tend to be preferred when taking an exploratory approach to finding the best solution or for incremental improvement of an existing solution.
Different approaches may be used within the same initiative. Among other factors, the business analyst may consider the organization’s standards, tolerance for uncertainty, and previous experience with different approaches when planning for business analysis activities.
Regardless of the approach, planning is an essential task to ensure value is delivered to an enterprise. Planning typically occurs more than once on a given initiative as plans are updated to address changing business conditions and newly raised issues. The business analysis approach should describe how plans will be altered if changes are required.

.2 Formality and Level of Detail of Business Analysis Deliverables

When defining the business analysis approach, consider the level of formality that is appropriate for approaching and planning the initiative.
Predictive approaches typically call for formal documentation and representations. Business analysis information may be captured in a formal document or set of representations following standardized templates.
Information is captured at various levels of detail. The specific content and format of business analysis information can vary depending on the organizational methodologies, processes, and templates in use.
Adaptive approaches favour defining requirements and designs through team interaction and gathering feedback on a working solution. Mandatory requirements representations are often limited to a prioritized requirements list. Additional business analysis documentation may be created at the discretion of the team, and generally consists of models developed to enhance the team’s understanding of a specific problem. Formal documentation is often produced after the solution is implemented to facilitate knowledge transfer.

Other considerations that may affect the approach include:
• the change is complex and high risk,
• the organization is in, or interacts with, heavily regulated industries,
• contracts or agreements necessitate formality,
• stakeholders are geographically distributed,
• resources are outsourced,
• staff turnover is high and/or team members may be inexperienced,
• requirements must be formally signed off, and
• business analysis information must be maintained long-term or handed over for use on future initiatives.

Figure 3.1.2: Formality and Level of Detail of Business Analysis Deliverables

.3 Business Analysis Activities
A business analysis approach provides a description of the types of activities that the business analyst will perform. Frequently the organization’s adopted methodologies influence the activities that are selected.
Integrating business analysis activities in the business analysis approach includes:
• identifying the activities required to complete each deliverable and then breaking each activity into tasks,
• dividing the work into iterations, identifying the deliverables for each iteration, and then identifying the associated activities and tasks, or

• using a previous similar initiative as an outline and applying the detailed tasks and activities unique to the current initiative.

.4 Timing of Business Analysis Work

Business analysts determine when the business analysis tasks need to be performed and if the level of business analysis effort will need to vary over time. This type of planning includes determining whether the business analysis tasks performed within the other knowledge areas will be performed primarily in specific phases or iteratively over the course of the initiative.
The timing of business analysis activities can also be affected by:
• the availability of resources,
• priority and/or urgency of the initiative,
• other concurrent initiatives, or
• constraints such as contract terms or regulatory deadlines.

.5 Complexity and Risk

The complexity and size of the change and the overall risk of the effort to the organization are considered when determining the business analysis approach. As complexity and risk increase or decrease, the nature and scope of business analysis work can be altered and reflected in the approach.
The approach may also be altered based on the number of stakeholders or business analysis resources involved in the initiative. As the number of stakeholders increases, the approach may be adjusted to include additional process steps to better manage the business analysis work.
Other factors that can impact complexity include:
• size of the change,
• number of business areas or systems affected,
• geographic and cultural considerations,
• technological complexities, and
• any risks that could impede the business analysis effort.
Factors that can impact the risk level of a business analysis effort include:
• experience level of the business analyst,
• extent of domain knowledge held by the business analyst,
• level of experience stakeholders have in communicating their needs,
• stakeholder attitudes about the change and business analysis in general,
• amount of time allocated by stakeholders to the business analysis activities,
• any pre-selected framework, methodology, tools, and/or techniques

imposed by organizational policies and practices, and
• cultural norms of the organization.

.6 Acceptance

The business analysis approach is reviewed and agreed upon by key stakeholders. In some organizations, the business analysis process may be more structured and require key stakeholders to sign off on the approach to ensure all business analysis activities have been identified, estimates are realistic, and the proposed roles and responsibilities are correct. Any issues raised by stakeholders when reviewing the approach are documented by the business analyst and resolutions are sought. Stakeholders also play a role in reviewing and accepting changes to the approach as alterations are made to accommodate changing conditions across the initiative.

3.1.5 Guidelines and Tools

• Business Analysis Performance Assessment: provides results of previous assessments that should be reviewed and incorporated into all planning approaches.
• Business Policies: define the limits within which decisions must be made. They may be described by regulations, contracts, agreements, deals, warranties, certifications, or other legal obligations. These policies can influence the business analysis approach.
• Expert Judgment: used to determine the optimal business analysis approach. Expertise may be provided from a wide range of sources including stakeholders on the initiative, organizational Centres of Excellence, consultants, or associations and industry groups. Prior experiences of the business analyst and other stakeholders should be considered when selecting or modifying an approach.
• Methodologies and Frameworks: shape the approach that will be used by providing methods, techniques, procedures, working concepts, and rules. They may need to be tailored to better meet the needs of the specific business challenge.
• Stakeholder Engagement Approach: understanding the stakeholders and their concerns and interests may influence decisions made when determining the business analysis approach.

3.1.6 Techniques

• Brainstorming: used to identify possible business analysis activities, techniques, risks and other relevant items to help build the business analysis approach.
• Business Cases: used to understand whether elements of the problem or opportunity are especially time-sensitive, high-value, or whether there is any particular uncertainty around elements of the possible need or solution.

• Document Analysis: used to review existing organizational assets that might assist in planning the approach.
• Estimation: used to determine how long it may take to perform business analysis activities.
• Financial Analysis: used to assess how different approaches (and the supported delivery options) affect the value delivered.
• Functional Decomposition: used to break down complex business analysis processes or approaches into more feasible components.
• Interviews: used to help build the plan with an individual or small group.
• ItemTracking: used to track any issues raised during planning activities with stakeholders. Can also track risk related items raised during discussions when building the approach.
• Lessons Learned: used to identify an enterprise’s previous experience (both successes and challenges) with planning business analysis approach.
• Process Modelling: used to define and document the business analysis approach.
• Reviews: used to validate the selected business analysis approach with stakeholders.
• Risk Analysis and Management: used to assess risks in order to select the proper business analysis approach.
• Scope Modelling: used to determine the boundaries of the solution as an input to planning and to estimating.
• Survey or Questionnaire: used to identify possible business analysis activities, techniques, risks and other relevant items to help build the business analysis approach.
• Workshops: used to help build the plan in a team setting.

3.1.7 Stakeholders

• Domain Subject Matter Expert: can be a source of risk when their involvement is required and availability is lacking. The approach taken may depend on availability and level of their involvement with the initiative.
• Project Manager: determines that the approach is realistic for the overall schedule and timelines. The business analysis approach must be compatible with other activities.
• Regulator: may be needed to provide approval for aspects of the business analysis approach or decisions made in tailoring the process, especially in organizations where the business analysis process is audited.
• Sponsor: can provide needs and objectives for the approach and ensures that organizational policies are followed. The selected approach may depend on availability and involvement with the initiative.

3.1.8 Outputs

• Business Analysis Approach: identifies the business analysis approach and activities that will be performed across an initiative including who will perform the activities, the timing and sequencing of the work, the deliverables that will be produced and the business analysis techniques that may be utilized. The remaining outputs of the Business Analysis Planning and Monitoring knowledge area may be integrated into an overall approach or be independent based upon methodology, organization, and perspective.

3.2 Plan Stakeholder Engagement

3.2.1 Purpose

The purpose of Plan Stakeholder Engagement is to plan an approach for establishing and maintaining effective working relationships with the stakeholders.

3.2.2 Description

Plan Stakeholder Engagement involves conducting a thorough stakeholder analysis to identify all of the involved stakeholders and analyze their characteristics. The results of the analysis are then utilized to define the best collaboration and communication approaches for the initiative and to appropriately plan for stakeholder risks.
When planning for stakeholder engagement, the degree of complexity can increase disproportionately as the number of stakeholders involved in the business analysis activities increases. This is important because new or different techniques for the management of stakeholders may be required when the engagement moves from collaborating with a few stakeholders into dozens, hundreds, or even thousands of people.

3.2.3 Inputs

• Needs: understanding the business need and the parts of the enterprise that it affects helps in the identification of stakeholders. The need may evolve as stakeholder analysis is performed.
• Business Analysis Approach: incorporating the overall business analysis approach into the stakeholder analysis, collaboration, and communication approaches is necessary to ensure consistency across the approaches.

Figure 3.2.1: Plan Stakeholder Engagement Input/Output Diagram

Input

**

Guidelines and Tools
Needs
3.1
Business Analysis Approach
**

**

Current State Description
3.2 Plan Stakeholder Engagement

Output
**

3.2.4 Elements

.1 Perform Stakeholder Analysis

Stakeholder analysis involves identifying the stakeholders (who will be directly or indirectly impacted by the change) and their characteristics, as well as analyzing the information once collected. Stakeholder analysis is performed repeatedly as business analysis activities continue.
A thorough and detailed stakeholder list ensures that stakeholders are not overlooked. Understanding who the stakeholders are, the impact of proposed changes on them, and the influence they may have on the change is vital to understanding what needs, wants, and expectations must be satisfied by a

solution. If stakeholders are not identified, the business analyst may miss uncovering critical needs. Stakeholder needs uncovered late will often require a revision to business analysis tasks that are either in progress or are completed. This can result in increased costs and decreased stakeholder satisfaction.
How business analysts perform stakeholder analysis can vary between projects, methodologies, and organizations. A company’s organizational chart and business processes can serve as an initial source for identifying internal stakeholders. The sponsor may also identify stakeholders. Stakeholders outside the organization may be identified and can be uncovered by understanding any existing contracts that may be in place, anticipated vendors that may have a role based on existing relationships with the organization, as well as regulatory and governing bodies that may influence the work. Shareholders, customers, and suppliers are also considered when searching for external stakeholders.

Roles

Business analysts identify stakeholder roles in order to understand where and how the stakeholders will contribute to the initiative. It is important that the business analyst is aware of the various roles a stakeholder is responsible for within the organization.

Attitudes

Stakeholder attitudes can positively or negatively impact a change. Business analysts identify stakeholder attitudes in order to fully understand what may impact a stakeholder’s actions and behaviours. Knowing how a stakeholder perceives the initiative allows an opportunity for the business analyst to specifically plan their collaboration and engagement with that stakeholder.
Business analysts analyze stakeholder attitudes about:
• business goals, objectives of the initiative, and any proposed solutions,
• business analysis in general,
• the level of interest in the change,
• the sponsor,
• team members and other stakeholders, and
• collaboration and a team-based approach.
Stakeholders with positive attitudes may be strong champions and great contributors. Other stakeholders may not see value in the work, may misunderstand the value being provided, or may be concerned about the effect the change will have on them. Stakeholders who are expected to serve in key roles and participate heavily in business analysis activities, but who view a change negatively, may require collaboration approaches that increase their cooperation.

Decision Making Authority

Business analysts identify the authority level a stakeholder possesses over business analysis activities, deliverables, and changes to business analysis work.

Understanding authority levels upfront eliminates confusion during the business analysis effort and ensures the business analyst collaborates with the proper stakeholders when looking for a decision to be made or seeking approvals.

Level of Power or Influence

Understanding the nature of influence and the influence structures and channels within an organization can prove invaluable when seeking to build relationships and trust. Understanding the influence and attitude each stakeholder may have can help develop strategies for obtaining buy-in and collaboration. Business analysts evaluate how much influence is needed to implement a change compared to the amount of influence the key stakeholders can bring. If there is a mismatch between the influence required and the amount of influence the stakeholder has or is perceived to have, business analysts develop risk plans, responses and other strategies that might be needed to obtain the required level of support.

.2 Define Stakeholder Collaboration

Ensuring effective collaboration with stakeholders is essential for maintaining their engagement in business analysis activities. Collaboration can be a spontaneous event. However, much collaboration is deliberate and planned, with specific activities and outcomes determined ahead of time during planning activities.
The business analyst may plan different collaboration approaches for internal and external stakeholders, and approaches may differ by business analysis activity. The objective is to select the approaches that work best to meet the needs of each stakeholder group and ensure their interest and involvement is maintained across the initiative. Some considerations when planning collaboration include:
• timing and frequency of collaboration,
• location,
• available tools such as wikis and online communities,
• delivery method such as in-person or virtual, and
• preferences of the stakeholders.
Planning considerations can be documented in the form of a stakeholder collaboration plan. As factors change, plans can be revisited, and adjustments and adaptations can be made to ensure ongoing engagement of stakeholders.

.3 Stakeholder Communication Needs

The business analyst evaluates:
• what needs to be communicated,
• what is the appropriate delivery method (written or verbal),
• who the appropriate audience is,
• when communication should occur,
• frequency of communication,

• geographic location of stakeholders who will receive communications,
• level of detail appropriate for the communication and stakeholder, and
• level of formality of communications.
Communication considerations can be documented in the form of a stakeholder communication plan. Business analysts build and review communication plans with stakeholders to ensure their communication requirements and expectations are met.

3.2.5 Guidelines and Tools

• Business Analysis Performance Assessment: provides results of previous assessments that should be reviewed and incorporated.
• Change Strategy: used for improved assessment of stakeholder impact and the development of more effective stakeholder engagement strategies.
• Current State Description: provides the context within which the work needs to be completed. This information will lead to more effective stakeholder analysis and better understanding of the impact of the desired change.

3.2.6 Techniques

• Brainstorming: used to produce the stakeholder list and identify stakeholder roles and responsibilities.
• Business Rules Analysis: used to identify stakeholders who were the source of the business rules.
• Document Analysis: used to review existing organizational assets that might assist in planning stakeholder engagement.
• Interviews: used to interact with specific stakeholders to gain more information or knowledge about stakeholder groups.
• Lessons Learned: used to identify an enterprise’s previous experience (both successes and challenges) with planning stakeholder engagement.
• Mind Mapping: used to identify potential stakeholders and help understand the relationships between them.
• Organizational Modelling: used to determine if the organizational units or people listed have any unique needs and interests that should be considered. Organizational models describe the roles and functions in the organization and the ways in which stakeholders interact which can help to identify stakeholders who will be affected by a change.
• Process Modelling: used to categorize stakeholders by the systems that support their business processes.
• Risk Analysis and Management: used to identify risks to the initiative resulting from stakeholder attitudes or the inability of key stakeholders to participate in the initiative.

• Scope Modelling: used to develop scope models to show stakeholders that fall outside the scope of the solution but still interact with it in some way.
• Stakeholder List, Map, or Personas: used to depict the relationship of stakeholders to the solution and to one another.
• Survey or Questionnaire: used to identify shared characteristics of a stakeholder group.
• Workshops: used to interact with groups of stakeholders to gain more information about stakeholder groups.

3.2.7 Stakeholders

• Customers: a source of external stakeholders.
• Domain Subject Matter Expert: may help to identify stakeholders and may themselves be identified to fulfill one or more roles on the initiative.
• End User: a source of internal stakeholders.
• Project Manager: may be able to identify and recommend stakeholders. Responsibility for stakeholder identification and management may be shared with the business analyst.
• Regulator: may require that specific stakeholder representatives or groups be involved in the business analysis activities.
• Sponsor: may request that specific stakeholders be involved in the business analysis activities.
• Supplier: a source of external stakeholders.

3.2.8 Outputs

• Stakeholder Engagement Approach: contains a list of the stakeholders, their characteristics which were analyzed, and a listing of roles and responsibilities for the change. It also identifies the collaboration and communication approaches the business analyst will utilize during the initiative.

3.3 Plan Business Analysis Governance

3.3.1 Purpose

The purpose of Plan Business Analysis Governance is to define how decisions are made about requirements and designs, including reviews, change control, approvals, and prioritization.

3.3.2 Description

Business analysts ensure that a governance process is in place and clarify any ambiguities within it. A governance process identifies the decision makers, process, and information required for decisions to be made. A governance process describes how approvals and prioritization decisions are made for requirements and designs.
When planning the governance approach, business analysts identify:
• how business analysis work will be approached and prioritized,
• what the process for proposing a change to business analysis information is,
• who has the authority and responsibility to propose changes and who should be involved in the change discussions,
• who has responsibility for analyzing change requests,
• who has the authority to approve changes, and
• how changes will be documented and communicated.

3.3.3 Inputs

• Business Analysis Approach: incorporating the overall business analysis approach into the governance approach is necessary to ensure consistency across the approaches.
• Stakeholder Engagement Approach: identifying stakeholders and understanding their communication and collaboration needs is useful in determining their participation in the governance approach. The engagement approach may be updated based on the completion of the governance approach.

Figure 3.3.1: Plan Business Analysis Governance Input/Output Diagram

3.3.4 Elements

.1 Decision Making
Decisions are made throughout the initiative. A stakeholder may serve in various roles in the decision-making process such as:
• participant in decision-making discussions,
• subject matter expert (SME) lending experience and knowledge to the decision-making process,
• reviewer of information, and
• approver of decisions.
The decision-making process defines what happens when teams cannot reach consensus, by identifying escalation paths and key stakeholders who hold final decision-making authority.

.2 Change Control Process

When business analysts develop a change control process, they:
• Determine the process for requesting changes: specify which requirements and designs the change control process covers and determine whether it applies to all changes or only to changes of a specific size, cost, or level of effort. This process details the steps for proposing a change, when changes can be proposed, who can propose changes and how change requests are communicated.
• Determine the elements of the change request: identify the information to be included in a proposal to support decision making and implementation if it is approved.
Possible components to consider on a change request are:
• Cost and time estimates: for each area affected by the proposed change, the expected cost of change is estimated.
• Benefits: an explanation of how the change aligns with the initiative and business objectives to show how the change adds value. Benefits considered include both financial benefits and tactical benefits such as implications to scope, time, cost, quality, and resources.
• Risks: an analysis of risks to the initiative, the solution, or business objectives.
• Priority: the level of importance of the change relative to other factors such as organizational objectives, regulatory compliance requirements, and stakeholder needs.
• Course(s) of action: the course of action for the change includes an assessment of the components of the change request (cost, time, benefits, risks and priority). It is common to identify several alternative courses, including those recommended by the requester and by other stakeholders so decision makers can make a choice that will best serve the needs of the initiative.
• Determine how changes will be prioritized: the priority of the proposed change is established relative to other competing interests within the current initiative.
• Determine how changes will be documented: configuration management and traceability standards establish product baselines and version control practices that identify which baseline is affected by the change.
• Determine how changes will be communicated: how proposed changes, changes under review, and approved, declined, or deferred changes will be communicated to stakeholders.
• Determine who will perform the impact analysis: specify who is responsible for performing an analysis of the impacts the proposed change will have across the initiative.

• Determine who will authorize changes: include a designation of who can approve changes and what business analysis information their authority covers.

.3 Plan Prioritization Approach

Timelines, expected value, dependencies, resource constraints, adopted methodologies, and other factors influence how requirements and designs are prioritized.
When planning the prioritization process, business analysts determine the:
• formality and rigour of the prioritization process,
• participants who will be involved in prioritization,
• process for deciding how prioritization will occur, including which prioritization techniques will be utilized, and
• criteria to be used for prioritization. For example, requirements may be prioritized based on cost, risk, and value.
The approach should also determine which stakeholders will have a role in prioritization.

.4 Plan for Approvals

An approval formalizes the agreement between all stakeholders that the content and presentation of the requirements and designs are accurate, adequate, and contain sufficient detail to allow for continued progress to be made.
The timing and frequency of approvals are dependent on the size and complexity of the change and associated risks of foregoing or delaying an approval.
The business analyst must determine the type of requirements and designs to be approved, the timing for the approvals, the process to follow to gain approval, and who will approve the requirements and designs.
When planning the appropriate approval process, business analysts consider the organizational culture and the type of information being approved. For example, new systems or processes for highly regulated industries such as financial, pharmaceutical, or healthcare are likely to require frequent and rigorous review and approval of very detailed specifications. For other types of initiatives, a less intensive approval process may be more appropriate and result in a faster implementation.
Planning for approvals also includes the schedule of events where approvals will occur and how they will be tracked. Stakeholder availability, attitude, and willingness to engage determine the efficiency of the approval process and may significantly affect delivery timelines.

3.3.5 Guidelines and Tools

• Business Analysis Performance Assessment: provides results of previous assessments that should be reviewed and incorporated into all planning approaches.

Business Analysis Planning and Monitoring Plan Business Analysis Governance

• Business Policies: define the limits within which decisions must be made. They may be described by regulations, contracts, agreements, warranties, certifications or other legal obligations.
• Current State Description: provides the context within which the work needs to be completed. This information can help drive how to make better decisions.
• Legal/Regulatory Information: describes legislative rules or regulations that must be followed, and can be used to help develop a framework that ensures sound business decision making.

3.3.6 Techniques

• Brainstorming: used to generate an initial list of potential stakeholder names who may need approval roles in the defined governance process.
• Document Analysis: used to evaluate existing governance processes or templates.
• Interviews: used to identify possible decision-making, change control, approval, or prioritization approaches and participants with an individual or small group.
• ItemTracking: used to track any issues that arise when planning a governance approach.
• Lessons Learned: used to find if past initiatives have identified valuable experiences with governance that can be leveraged on current or future initiatives.
• Organizational Modelling: used to understand roles/responsibilities within the organization in an effort to define a governance approach that involves the right stakeholders.
• Process Modelling: used to document the process or method for governing business analysis.
• Reviews: used to review the proposed governance plan with key stakeholders.
• Survey or Questionnaire: used to identify possible decision-making, change control, approval, or prioritization approaches and participants.
• Workshops: used to identify possible decision-making, change control, approval, or prioritization approaches and participants within a team setting.

3.3.7 Stakeholders

• Domain Subject Matter Expert: may be a possible source of a requested change or may be identified as needing to be involved in change discussions.
• Project Manager: works with the business analyst to ensure that overall project governance aligns with the business analysis governance approach.
• Regulator: may impose rules or regulations that need to be considered when determining the business analysis governance plan. May also be a possible source of a requested change.

Plan Business Analysis Information Management Business Analysis Planning and Monitoring

• Sponsor: can impose their own requirements for how business analysis information should be managed. Participates in change discussions and approves proposed changes.

3.3.8 Outputs

• Governance Approach: identifies the stakeholders who will have the responsibility and authority to make decisions about business analysis work including who will be responsible for setting priorities and who will approve changes to business analysis information. It also defines the process that will be utilized to manage requirement and design changes across the initiative.

3.4 Plan Business Analysis Information Management

3.4.1 Purpose

The purpose of Plan Business Analysis Information Management is to develop an approach for how business analysis information will be stored and accessed.

3.4.2 Description

Business analysis information is comprised of all the information business analysts elicit, create, compile, and disseminate in the course of performing business analysis. Models, scope statements, stakeholder concerns, elicitation results, requirements, designs, and solution options are just a few examples. This includes requirements and designs, from lightweight user stories to formal requirement documents to functioning prototypes.
Information management entails identifying:
• how information should be organized,
• the level of detail at which information should be captured,
• any relationships between the information,
• how information may be used across multiple initiatives and throughout the enterprise,
• how information should be accessed and stored, and
• characteristics about the information that must be maintained.
Information management helps ensure that business analysis information is organized in a functional and useful manner, is easily accessible to appropriate personnel, and is stored for the necessary length of time.

3.4.3 Inputs

• Business Analysis Approach: incorporating the overall business analysis approach into the information management approach is necessary to ensure consistency across the approaches.

Business Analysis Planning and Monitoring Plan Business Analysis Information Management

• Governance Approach: defines how business analysts manage changes to requirements and designs, how decisions and approvals for business analysis deliverables will be made, and how priorities will be set.
• Stakeholder Engagement Approach: identifying stakeholders and understanding their communication and collaboration needs is useful in determining their specific information management needs.

Figure 3.4.1: Plan Business Analysis Information Management Input/Output Diagram

3.4.4 Elements

.1 Organization of Business Analysis Information
Business analysts are responsible for organizing business analysis information in a manner that allows for efficient access and use. Information must be well structured to ensure it is not difficult to locate, conflicts with other information, or is needlessly duplicated.

Plan Business Analysis Information Management Business Analysis Planning and Monitoring

The business analyst determines how best to structure and organize the business analysis information at the start of an initiative. This involves taking into consideration the type and amount of information to be collected, the stakeholder’s access and usage needs, and the size and complexity of the change. Relationships among the types of information must be defined to assist in managing the effect of new or changed information in the future.

.2 Level of Abstraction

Level of abstraction describes the breadth and depth of the information being provided. Representations of information may range from highly conceptual or summarized to very detailed. In determining how much detail each stakeholder may require as the initiative evolves, consideration is given to the needs of the stakeholders, the complexity of what is being explained, and the importance of the change. Rather than present the same information to all stakeholders, business analysts should present information with appropriate breadth and level of detail based on each stakeholder’s role. Business analysis information regarding a topic of significant importance or high level of risk is frequently represented in greater detail.

.3 Plan Traceability Approach

The traceability approach is based on:
• the complexity of the domain,
• the number of views of requirements that will be produced,
• any requirement-related risks, organizational standards, applicable regulatory requirements, and
• an understanding of the costs and benefits involved with tracing.
Business analysts plan to ensure the approach is at a level of detail to add value without excessive overhead.

.4 Plan for Requirements Reuse

Reusing requirements can save an organization time, effort, and cost—provided the requirements are accessible and structured in a manner that supports their reuse.
Requirements that are potential candidates for long-term use are those an organization must meet on an ongoing basis such as:
• regulatory requirements,
• contractual obligations,
• quality standards,
• service level agreements,
• business rules,
• business processes, or
• requirements describing products the enterprise produces.

Requirements may also be reused when describing common features or services that are used across multiple systems, processes, or programs.
To make requirements useful beyond the current change, business analysts plan ahead for requirements reuse by identifying how best to structure, store, and access requirements so they are usable and accessible for future business analysis efforts.
In order for requirements to be reused they must be clearly named, defined, and stored in a repository that is available to other business analysts.

.5 Storage and Access

Business analysis information can be stored in many ways. Storage decisions depend on many factors such as who must access the information, how often they need to access it, and what conditions must be present for access.
Organizational standards and tool availability also influence storage and access decisions. The business analysis approach defines how various tools will be used on the initiative and how the information will be captured and stored within those tools. Tools may shape the selection of business analysis techniques, notations to be used, and the way that information is organized.
The repository may need to store information other than requirements and designs. It should be able to indicate the status of any stored information, and allow for modification of that information over time.

.6 Requirements Attributes

Requirements attributes provide information about requirements, and aid in the ongoing management of the requirements throughout the change. They are planned for and determined with the requirements themselves.
Requirements attributes allow business analysts to associate information with individual or related groups of requirements. The information documented by the attributes helps the team efficiently and effectively make trade-offs between requirements, identify stakeholders affected by potential changes, and understand the effect of a proposed change.
Some commonly used requirements attributes include:
• Absolute reference: provides a unique identifier. The reference is not altered or reused if the requirement is moved, changed, or deleted.
• Author: provides the name of the person who needs to be consulted should the requirement later be found to be ambiguous, unclear, or in conflict.
• Complexity: indicates how difficult the requirement will be to implement.
• Ownership: indicates the individual or group that needs the requirement or will be the business owner after the solution is implemented.
• Priority: indicates relative importance of requirements. Priority can refer to the relative value of a requirement or to the sequence in which it will be implemented.

• Risks: identifies uncertain events that may impact requirements.
• Source: identifies the origin of the requirement. The source is often consulted if the requirement changes or if more information regarding the requirement or the need that drove the requirement has to be obtained.
• Stability: indicates the maturity of the requirement.
• Status: indicates the state of the requirement, whether it is proposed, accepted, verified, postponed, cancelled, or implemented.
• Urgency: indicates how soon the requirement is needed. It is usually only necessary to specify this separately from the priority when a deadline exists for implementation.

3.4.5 Guidelines and Tools

• Business Analysis Performance Assessment: provides results of previous assessments that should be reviewed and incorporated into all planning approaches.
• Business Policies: define the limits within which decisions must be made. They may be described by regulations, contracts, agreements, warranties, certifications, or other legal obligations.
• Information Management Tools: each organization uses some tools to store, retrieve, and share business analysis information. These may be as simple as a whiteboard, or as complex as a global wiki or robust requirements management tool.
• Legal/Regulatory Information: describes legislative rules or regulations that must be followed, and helps determine how business analysis information will be managed.

3.4.6 Techniques

• Brainstorming: used to help stakeholders uncover their business analysis information management needs.
• Interviews: used to help specific stakeholders uncover their business analysis information management needs.
• ItemTracking: used to track issues with current information management processes.
• Lessons Learned: used to create a source of information for analyzing approaches for efficiently managing business analysis information.
• Mind Mapping: used to identify and categorize the kinds of information that need to be managed.
• Process Modelling: used to document the process or method for managing business analysis information.

• Survey or Questionnaire: used to ask stakeholders to provide input into defining business analysis information management.
• Workshops: used to uncover business analysis information management needs in a group setting.

3.4.7 Stakeholders

• Domain Subject Matter Expert: may need to access and work with business analysis information, and will be interested in a more specific view of business analysis information which relates to their area of expertise.
• Regulator: may define rules and processes related to information management.
• Sponsor: reviews, comments on, and approves business analysis information.

3.4.8 Outputs

• Information Management Approach: includes the defined approach for how business analysis information will be stored, accessed, and utilized during the change and after the change is complete.

3.5 Identify Business Analysis Performance Improvements

3.5.1 Purpose

The purpose of Identify Business Analysis Performance Improvements is to assess business analysis work and to plan to improve processes where required.

3.5.2 Description

To monitor and improve performance, it is necessary to establish the performance measures, conduct the performance analysis, report on the results of the analysis, and identify any necessary preventive, corrective, or developmental actions.
Performance analysis should occur throughout an initiative. Once potential performance improvements are identified, they become guidelines for the next time a task is executed.

3.5.3 Inputs

• Business Analysis Approach: identifies business analysis deliverables that will be produced, activities that will need to be performed (including when they will be performed and who will be performing them), and techniques that will be used.
• Performance Objectives (external): describe the desired performance outcomes that an enterprise or organization is hoping to achieve.

Figure 3.5.1: Identify Business Analysis Performance Improvements Input/Output Diagram

Output

3.5.4 Elements

.1 Performance Analysis

What constitutes effective business analysis work depends on the context of a particular organization or initiative. Reports on business analysis performance can be informal and verbal, or they may include formal documentation. Reports on business analysis performance are designed and tailored to meet the needs of the various types of reviewers.

.2 Assessment Measures

If current measures exist, the business analyst may leverage them or determine new measures. The business analyst may also elicit assessment measures from stakeholders.
Performance measures may be based on deliverable due dates as specified in the

All performance metrics will encourage certain behaviours and discourage others. Poorly chosen metrics may drive behaviour that is detrimental to the enterprise as a whole.
business analysis plan, metrics such as the frequency of the changes to business analysis work products, the number of review cycles required, task efficiency, or qualitative feedback from stakeholders and peers regarding the business analyst’s deliverables. Appropriate performance measures enable the business analyst to determine when problems are occurring that may affect the performance of business analysis or identify opportunities for improvement. Measures may be both quantitative and qualitative. Qualitative measures are subjective and can be heavily influenced by the stakeholder’s attitudes, perceptions, and other subjective criteria.
Some possible measures are:
• Accuracy and Completeness: determine whether the business analyst work products were correct and relevant when delivered, or whether ongoing revisions were needed to gain acceptance by stakeholders.
• Knowledge: assess whether the business analyst had the skills and/or experience to perform the assigned task.
• Effectiveness: assess whether the business analyst work products were easy to use as standalone deliverables or whether they required extensive explanation in order to be understood.
• Organizational Support: assess whether there were adequate resources available to complete business analysis activities as needed.
• Significance: consider the benefit obtained from the work products and assess whether the cost, time, and resource investments expended to produce the work products were justified for the value they delivered.
• Strategic: look at whether business objectives were met, problems were solved, and improvements were achieved.
• Timeliness: evaluate whether the business analyst delivered the work on time per stakeholder expectations and schedule.

.3 Analyze Results

The business analysis process and deliverables are compared against the set of defined measures. The analysis may be performed on the business analysis process, the resources involved, and the deliverables.
Performance may be determined from the point of view of the stakeholders who are the recipients of the business analysis work. Other times a personnel manager or a Centre of Excellence may make this determination and provide assessments. All stakeholders may have input in assessing the value of the business analysis work but organizations may differ in terms of who has the authority to set the targets against which performance is measured.

.4 Recommend Actions for Improvement

Once the analysis of performance results is complete, the business analyst engages the appropriate stakeholders to identify the following actions:
• Preventive: reduces the probability of an event with a negative impact.

• Corrective: establishes ways to reduce the negative impact of an event.
• Improvement: establishes ways to increase the probability or impact of events with a positive impact.
These actions are likely to result in changes to the business analysis approach, repeatable processes, and tools.

3.5.5 Guidelines and Tools

• Organizational Performance Standards: may include performance metrics or expectations for business analysis work mandated by the organization.

3.5.6 Techniques

• Brainstorming: used to generate ideas for improvement opportunities.
• Interviews: used to gather assessments of business analysis performance.
• ItemTracking: used to track issues that occur during the performance of business analysis for later resolution.
• Lessons Learned: used to identify recommended changes to business analysis processes, deliverables, templates, and other organizational process assets that can be incorporated into the current initiative and future work.
• Metrics and Key Performance Indicators (KPIs): used to determine what metrics are appropriate for assessing business analysis performance and how they may be tracked.
• Observation: used to witness business analysis performance.
• Process Analysis: used to analyze existing business analysis processes and identify opportunities for improvement.
• Process Modelling: used to define business analysis processes and understand how to improve those processes to reduce problems from hand-offs, improve cycle times, or alter how business analysis work is performed to support improvements in downstream processes.
• Reviews: used to identify changes to business analysis processes and deliverables that can be incorporated into future work.
• Risk Analysis and Management: used to identify and manage potential conditions or events that may impact business analysis performance.
• Root Cause Analysis: used to help identify the underlying cause of failures or difficulties in accomplishing business analysis work.
• Survey or Questionnaire: used to gather feedback from stakeholders about their satisfaction with business analysis activities and deliverables.
• Workshops: used to gather assessments of business analysis performance and generate ideas for improvement opportunities.

3.5.7 Stakeholders

• Domain Subject Matter Experts: should be informed about the business analysis activities in order to set expectations regarding their involvement in the work and to elicit their feedback regarding possible improvements to the approach.
• Project Manager: is accountable for the success of a project and must be kept informed of the current status of business analysis work. If potential problems or opportunities for improvement are identified, the project manager must be consulted before changes are implemented to assess whether those changes will have an impact on the project. They may also deliver reports on business analysis performance to the sponsor and other stakeholders.
• Sponsor: may require reports on business analysis performance to address problems as they are identified. A manager of business analysts may also sponsor initiatives to improve the performance of business analysis activities.

3.5.8 Outputs

• Business Analysis Performance Assessment: includes a comparison of planned versus actual performance, identifying the root cause of variances from the expected performance, proposed approaches to address issues, and other findings to help understand the performance of business analysis processes.