Business Analysis Planning and Monitoring Tutorial

2.1 Business Analysis Planning and Monitoring

Hello and welcome to the second lesson of the Certification of Competency in Business Analysis™ (CCBA®) course offered by Simplilearn. This lesson deals with planning and monitoring. In the first lesson, we were introduced to CCBA certification. In this lesson, we will discuss the first knowledge area in the analysis process and the approach to plan and monitor the analysis. During this step, the BA needs to gather enough information to identify stakeholders, define their roles and responsibilities, develop estimation, plan communication, determine business analyst deliverables, and define metrics to monitor business analysis work. An important point to remember while gathering preliminary information is to maintain an open mind as the on-site situation may be different from the preliminary information. Let us begin by looking at the objectives of this lesson in the next slide.

2.2 Objectives

After completing this lesson, you will be able to: Discuss the business analysis planning and monitoring knowledge area Explain the difference between a plan-driven analysis and a change-driven analysis. Identify the project roles and responsibilities for each member of the team. Use an RACI (pronounce as “R-A-C-I”) Matrix and Stakeholder Onion Diagram to evaluate stakeholders. Identify common requirement attributes. Let us get an overview of the business analysis planning and monitoring knowledge area in the next slide.

2.3 Introduction to Business Analysis Planning and Monitoring

There are many tasks associated with the planning and monitoring knowledge area. It focuses on planning the collection, documentation, and management of requirements. This knowledge area includes identifying stakeholders, defining their roles and responsibilities, developing estimations for business analysis tasks, and knowing how best to communicate with them. Next, the business analyst determines the deliverables list and estimates. The requirements have to be stated, traced, and prioritized using a method determined by the business analyst. The list of deliverables—produced by the business analyst—and the business analysis processes are defined and documented. Finally, the metrics used for monitoring business analysis work are gathered. All of these tasks are designed to get the enterprise prepared for the elicitation of requirements and finally the implementation of a solution that meets business needs. Let us discuss the inputs and outputs of business analysis planning and monitoring in the next slide.

2.4 Business Analysis Planning & Monitoring Diagram

Throughout the Business Analysis process, the same inputs and outputs can be used many times. These inputs can be updated as new information is gathered during the progress of the analysis. They can be used in multiple iterations throughout the process. The following are the inputs: Business Analysis Performance Metrics: Actual performance measures are captured, analyzed, and made the basis for taking corrective or preventive action. Capturing actual performance metrics is a process that occurs through the business analysis effort and is implicitly a potential output from every business analysis task. Business needs: They are made available for discussion to gather more input and consensus. They will be a major focus of the elicitation phase and need to give way to requirements and potential solutions. The business needs are the motivators for the project and need to be clearly defined, validated, and assessed. The BA will need the input from the sponsor and stakeholders to make sure the narrative effectively expresses the motives and benefits in the business case. Enterprise architecture: It is a description of an organization’s business processes. Expert judgment: It is used to determine the optimal business analysis approach. Expertise may be provided by a variety of sources, including stakeholders. Organizational process assets: They will be an important stakeholder topic. Once the needs have been more or less defined, potential solutions are elicited. During that process, the stakeholders and BA need to examine the risks, as well as the current capacity of the enterprise, to use its current assets (labor, equipment, and funding) to make the necessary changes. Often, outside-specialized vendors may be needed to fill the gaps in organizational capabilities. Organizational process assets include policies and procedures, forms that must be completed, suggested or prescribed methodologies, templates, and project authorization guidelines that are not an input to manage BA performance, but is an input to the others. The following are the outputs: Business analysis approach: It will describe the scope, budget, and timing, as well as the human resources required and the communication needs. There may be a methodology used to create the approach. This documentation may eventually be added to the enterprise’s process assets. Stakeholder list, roles, and responsibility designation: It is a list of stakeholders affected by a business need or proposed solution and a description of their participation in the project. Business analysis plan: It includes information such as scope of work, work breakdown structure, activity list, estimates for each activity and task, and information on how the plan should be changed in response to changing conditions. BA Communication Plan: It is a description of the types of communication the business analyst will perform during business anal¬ysis, the recipients of those communications, and the form in which the communications should occur. Requirements Management Plan: It is a description of the requirements management process. BA Process Assets: When the performance analysis of the business analysis work yields less than satisfactory results, it is helpful to review not only the results, but also the process that produced those results. This process analysis often results in recommendations for improvement to the business analysis process. The revised process and templates for business analysis deliverables should be analyzed and documented and the lessons learned should be recorded. These may be incorporated into Organizational Process Assets. BA Performance Assessment: It includes a comparison of planned versus actual performance, understanding the root cause of variances from the plan, and other information to help understand the level of effort required to complete business analysis work. In the next slide, we will discuss business analysis scenarios.

2.5 Business Analysis Scenarios

There are two distinct situations faced in Business Analysis. In the first situation, a client has determined what needs to be done for an enterprise, but the enterprise does not have the in-house expertise to implement the desired changes. In the second situation, the client is not sure of the changes that are to be done to improve the enterprise performance. The first situation is called a plan-driven analysis, while the second is called a change-driven analysis. In a plan-driven analysis, the general requirements are known and the implementation of required changes is well understood. For example, an enterprise may need a software application to help streamline a process or a procedure. An external software consulting company may need to be contacted to install the application. In this case, the Business Analyst needs to identify the situation and the best way to proceed with the requirements for installation. This is a low-risk scenario, in which the installation process is well understood, and is a routine implementation. The plan-driven analysis is less risky for both the enterprise and the contractor as the scope and cost estimation of the project are well understood. A change-driven analysis is carried out when a client is not sure of what needs to be done to make the required changes. There is a higher need for the Business Analyst to act like a detective and a problem solver than is required in a plan-driven project. The BA requires more time to analyze the entire operation and elicit more information before identifying problems and potential solutions. Change-driven analysis can be risky for the client, enterprise, and BA. What if the problem identified is not the root cause and the proposed solution does not solve the problem? How does the client react to the disruption and cost incurred for a non-solution? A change-driven plan may require several iterations of trial and error before finding the best solution. The risks are much higher in a change-driven analysis as the trial and error process can be very disruptive and costly for the client. Most of the middle-level and upper-level management are Business Analysts in a way or the other. They are continuously dealing with problems and solutions. However, the internal politics of an enterprise sometimes makes it more acceptable if a third party is contracted to present and help implement solutions. This allows for deniability by a sponsor or stakeholder if the solution is wrong. Moreover, a third party (BA) offers certain implications of objectivity and new perspectives. A BA is dedicated to the task of identifying problems, problem costs, and solutions that meet the identified needs of the client. The opportunity to gain experience in the analysis process can bring valuable insights and solutions to the process over time. By learning how to make the right changes and reducing the political risks, enterprise managers contribute toward the success of a project. For any BA, unraveling problems and offering successful solutions not only add value for the client but also for the profession of Business Analysis. Business Analysis is seen as a credible tool in any business evolution and development, and that fact demands each BA to represent the profession in a highly effective and ethical manner. We will begin with the walk-of the Planning and Monitoring tasks on the next slide. The first task is Plan the Business Analysis Approach. In the next slide, we will be discussing a plan business analysis approach task.

2.6 Plan Business Analysis Approach Diagram

To pass the CCBA certification exam, you must know the inputs, outputs, and techniques for each knowledge area and task. Many of the test questions specifically ask about these topics. Let us discuss these in detail. The following are the inputs on the left: Business Needs Expert Judgment Organizational Process Assets The following is the output on the right: Business Analysis Approach The following are the techniques: Decision Analysis examines and models consequences of different decisions. It attempts to make optimal decisions under risky situations. Process Modeling attempts to create a logical flow and sequencing of related activities or actions. Structured Walkthrough is a peer review of a deliverable or, in this case, the business analysis plan with the objective of finding errors or omissions. It is a form of quality assurance. We will now move to the next task in planning and monitoring.

2.7 Conduct Stakeholder Analysis Diagram

The following are the inputs on the left: Business Needs Enterprise Architecture Organizational Process Assets The following is the output on the right: Stakeholder List, Roles, and Responsibility Designation The following are the techniques: Acceptance and Evaluation Criteria Definition defines which stakeholders have sufficient authority to accept or reject the solution. Brainstorming is used to produce a broad or diverse set of options from a set of participants. Interviews are conducted to elicit information from a person by talking to the interviewee and asking relevant questions and documenting the responses. Organization Modeling is determining if there are any unique needs and knowing who are most affected by the changes. Requirements Workshops are structured meetings where stakeholders define or refine requirements with the guidance of a skilled facilitator. Risk Analysis is used to identify and manage areas of uncertainty that can affect an initiative, solution, or organization. Scenarios and Use Cases are modeling techniques that describe the actors (users) who interact with a system and the goals those actors have when using the system. Scope Modeling defines the boundaries of a business domain or solution. Surveys/Questionnaires are used to elicit information from many people in a relatively short period by providing questions and receiving agreement or disagreement from the responders. An RACI Matrix describes the roles of those involved in business analysis activities. A stakeholder Map is a visual diagram that depicts the relationship of stakeholders to the solution and to one another. We will now discuss Sponsor and Stakeholder Analysis in detail.

2.8 Performing Sponsor and Stakeholder Analysis

The following are the steps to be followed during sponsor and stakeholder analysis: A sponsor interview is the first step in the elicitation phase. Once the BA has a general understanding of the enterprise and its market, it is time to interview the sponsor. The sponsor is the person who is in charge of the potential project. Sometimes, the project is pre-approved. However, the BA should establish if the sponsor is the real decision maker or the actual decision process will be followed before a project is ready for implementation. The sponsor interview will provide the sponsor’s perception of what the business needs are and help the BA understand the sponsor’s expectations. The sponsor will also help the BA to get a better understanding of who the key stakeholders and SMEs (subject matter experts) are. The sponsor interview will also unveil the potential problems, risks, and project concerns. The BA should not automatically accept problems and solutions from the sponsor before they are validated by the completed analysis. However, understanding the sponsor’s concerns and expectations is very important for a successful project. Key stockholder and SME identification done during the sponsor interview will help the BA to chart out the organizational structure along with the associated stakeholders and SMEs (to be read as S M E’s) who play a key role in the processes to be examined. Preliminary needs and requirements form the output of the sponsor interview. They provide a good starting point for meeting the other stakeholders. They also confirm if the stakeholders and SMEs are in agreement with the sponsor. Key stakeholder evaluations are obtained verbally from the sponsor or from enterprise evaluations. Let us discuss the various roles and responsibilities in the planning and monitoring process.

2.9 Assigning Roles and Responsibilities

Identification of project roles in the pre-elicitation phase draws on prior documentation analysis and prior BA experience with similar situations. With the information gathered so far, the BA will have an idea of the requirements and potential solutions, and the presentation of the project. This preliminary idea can form the groundwork for identifying the required roles and responsibilities, which are subject to change as the process progresses. The following are the roles and responsibilities: An application architect helps to identify and design the solution structure. A business analyst is responsible for gathering requirements, planning, coordinating, and communicating with team members and stakeholders. A project manager is responsible for managing the implementation of the project and coordinating the project milestone activities. A database analyst reviews and analyzes the database resources and develops any new database policies and procedures. An end user is the person or persons who will use the new solution on a regular basis. We will continue our discussion on roles and responsibilities in the next slide.

2.10 Assigning Roles and Responsibilities(contd.)

An executive sponsor is usually the “champion” and decision maker for the project. An infrastructure analyst helps define, design, or adapt hardware and technical infrastructure. A quality assurance person is responsible for ensuring that the solutions meet the enterprise QC (quality control) policies and procedures. A solution owner is responsible for making sure that the functional requirements, such as project scope statement, solution validations, etc., are successful in meeting the solution deliverable. An SME is the subject matter expert who is responsible for expert advice, information, and related requirements for a particular solution. A trainer is responsible for training end users and others in properly using the new solutions. The Team RACI matrix documents the various roles, responsibilities, accountabilities, and communication requirements. Let us continue with the discussion of stakeholder’s roles and responsibilities.

2.11 Stakeholder’s Roles and Responsibilities

Stakeholder’s roles and responsibilities are also used to draw input and modifications. Following are the steps carried out during the formation of stakeholder’s roles and responsibilities: In stakeholder analysis, after the elicitation activities, a business need is identified and is ongoing. Authority levels describe the levels of authority that each role will have. Impact on stakeholders can be surprising if the stakeholder is not aware of what happens in a change related project. Let us discuss the RACI matrix in detail. It will help us understand the roles of those involved in business analysis activities.

2.11 Stakeholder’s Roles and Responsibilities

Stakeholder’s roles and responsibilities are also used to draw input and modifications. Following are the steps carried out during the formation of stakeholder’s roles and responsibilities: In stakeholder analysis, after the elicitation activities, a business need is identified and is ongoing. Authority levels describe the levels of authority that each role will have. Impact on stakeholders can be surprising if the stakeholder is not aware of what happens in a change related project. Let us discuss the RACI matrix in detail. It will help us understand the roles of those involved in business analysis activities.

2.12 Assigning Roles and Responsibilities RACI Matrix

The RACI matrix attempts to map who is responsible for which tasks within a task and who is informed if not involved directly. One of the most frustrating and demanding tasks is communicating and updating all the stakeholders. The RACI matrix goes a long way in helping keep the information loop intact and up-to-date. Let us discuss the different types of stakeholders in the next slide.

2.13 Stakeholder Onion Diagram

In the image on the slide, the concentric rings represent the impact of changes on stakeholders. The farther a ring is from the solution delivery, the less direct impact it has on stakeholders in the particular section. For example, customers are stakeholders, but are usually less affected than those employee stakeholders who are actually implementing the solutions. The organization or enterprise may only experience the impact in a certain department, product, or service. The affected organizational unit is much more directly affected, particularly the users of the new solution. The most direct effect is on the implementers of the solution scope as they have completed their assigned task. However, a real solution positively affects all stakeholders but to different degrees. Let us move on to the next task in planning and monitoring.

2.14 Plan BA Activities Diagram

The following are the inputs on the left: Business Analysis Approach Business Analysis Performance Assessment Organizational Process Assets Stakeholder List, Roles, and Responsibilities The following is the output on the right: Business Analysis Plans The following are the techniques: Estimation is performed with the expertise of the project manager and other team members. It makes use of the templates available in many organizations to determine estimates. Functional Decomposition is breaking down of the processes, functional areas, or deliverables in a product or a product into its component parts to estimate the tasks. Risk Analysis identifies risks that might affect the business analysis plan. In the next slide, we will be discussing requirements planning.

2.15 Requirements Planning

To create an overview of requirements planning, the business must be focused on obtaining consensus agreement from the key stakeholders and SMEs on needs, potential solutions, and requirements. This consensus is what creates a solution that will be successfully implemented to solve the business problem. A plan should be created to optimize the activities around the stated goals. Potential risks, assumptions, and constraints must be identified and analyzed. All the information must be documented and presented, including a tentative list of needs, potential solutions, and requirements, to help move quickly into the elicitation process. Next, we will cover the distribution of stakeholders.

2.16 Geographic Distribution of Stakeholders

Project teams could be collocated or dispersed. Collocated stakeholders are located in the same local geographic area. Dispersed stakeholders are located in different geographic regions or countries with different time zones, cultures, and languages. The communications required for dispersed teams will be very different from that of collocated teams. These arrangements will affect communication and implementation plans. In the next slide, we will discuss risk analysis and management.

2.17 Risk Analysis and Management

Risks are uncertain events or conditions. If they occur, the goals or objectives of a proposed change will be affected. In risk analysis and management, we perform a first pass at identifying potential risks and constraints. By gaining information from stakeholders, we can understand how to manage potential risks and constraints. The next step is to prioritize risks and constraints, and finally, determine how risks and constraints can affect the list of prioritized requirements as this will affect the goals or objectives of a proposed solution. Let us move on to the next task in planning and monitoring.

2.18 Plan BA Communication Diagram

The following are the inputs: Business Analysis Approach Business Analysis Plan Organizational Process Assets Stakeholder List, Roles, and Responsibilities The following is the output on the right: Business Analysis Communication Plan The following are the techniques: Structured Walkthrough In the next slide, we will be discussing the next step in planning and monitoring.

2.19 Plan Requirements Management Process Diagram

The following are the inputs: Business Analysis Approach Business Analysis Plan Organizational Process Assets The following is the output on the right: Requirements Management Plan The following are the techniques: Decision Analysis is an approach to decision making that examines the possible consequences of different decisions. The BA tries to make an optimal decision. Problem Tracking is used to track possible changes and ensure that a decision is reached. Risk Analysis was discussed previously. In the next slide, we will be discussing requirements attributes.

2.20 Requirements Attributes

The following are the requirements attributes: Absolute Reference is a unique identifier. The Author of the Requirement is documented so that the author can be located for clarification. Complexity is the difficulty level of the requirements to be implemented. Ownership states the person who will be the business owner after the project is released and implemented. Priority tells which requirements need to be implemented first. Risks are associated with meeting or not meeting the requirements Source of the Requirement notes who initiated the requirement and has the authority to define a particular set of requirements. Stability refers to how mature the requirement is. Status could include attributes like proposed, accepted, verified, postponed, cancelled, or implemented. Urgency indicates how soon the requirement is needed. The next topic is requirements prioritization and change management. Let us discuss it in detail.

2.21 Requirements Prioritization and Change Management

Prioritization focuses on determining which requirements should be investigated first based on elements of risk, cost, time, resource constraints, or other factors. There are three factors that affect prioritization—formality, process, and planning the participation of those who are involved with the prioritization. Change Management is an inevitable process in every project or effort. The BA needs to plan ways to deal with a change in an organized and efficient manner. According to the BABOK® Guide, there needs to be a process for requesting changes, deciding who will authorize changes, determining impact, and planning the wording of the request. Let us look at the last task in planning and monitoring in the next slide.

2.22 Manage BA Performance Diagram

The following are the inputs on the left: Business Analysis Performance Metrics Business Analysis Plan Organizational Performance Standards Requirements Management Plan The output on the right is: Business Analysis Process Assets The following are the techniques: Interviews Lessons Learned Metrics and Key Performance Indicators Problem Tracking Process Modeling Root Cause Analysis Survey/Questionnaire Variance Analysis This is the last step in the Business Analysis Planning and Monitoring knowledge area. Now, let us go through a few questions to check your understanding of the concepts discussed.

2.24 Summary

In this lesson, we have learned that the planning and monitoring knowledge area focuses on the planning of collection, documentation, and management of the requirements. In a plan-driven analysis, the stakeholders create formal documentation for business needs, requirements, and solution approach. In a change-driven analysis, the stakeholders work with the team to create requirements and perform development in short iterations. The sponsor authorizes the product development by paying for the project. The project manager is responsible for managing the project scope, time, and cost. The business analyst is responsible for gathering requirements from the stakeholders, and recommending solutions that meet the business needs. Two techniques for evaluating stakeholders are RACI Matrix and Stakeholder Onion Diagram.

2.25 Thank You

In the next lesson, we will learn about elicitation and the techniques used to elicit requirements.

2.11 Stakeholder’s Roles and Responsibilities

Stakeholder’s roles and responsibilities are also used to draw input and modifications. Following are the steps carried out during the formation of stakeholder’s roles and responsibilities: In stakeholder analysis, after the elicitation activities, a business need is identified and is ongoing. Authority levels describe the levels of authority that each role will have. Impact on stakeholders can be surprising if the stakeholder is not aware of what happens in a change related project. Let us discuss the RACI matrix in detail. It will help us understand the roles of those involved in business analysis activities.

  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

Request more information

For individuals
For business
Name*
Email*
Phone Number*
Your Message (Optional)
We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Email*
Phone Number*
Company*
Job Title*