CBAP Planning the Analysis Approach Tutorial

2.2 Planning the Analysis Approach

Hello and welcome to the second module of Certified Business Analysis Professional™ (CBAP) (To be read as C-BAP) certification course offered by Simplilearn. This module deals with planning the analysis approach. In the first module we were introduced to CBAP. In this module, we will discuss the first step in the analysis process and the approach to plan the analysis. During this important step in analysis, the BA needs to gather enough information to get an idea of the company, its history, markets, competition, and organization. Before meeting the project sponsor and other stakeholders, he or she also needs to examine how the organization operates. In other words, clients like to see the BA up and running as quickly as possible. Another important point to be kept in mind 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 into the agenda of this module in the next slide.

2.3 Agenda

This slide provides an overview of what will be covered in this module. The topics dealt with are a part of the normal document and action plan preparations for pre-elicitation process. We will be discussing the two general types of business analysis scenarios. Then we will move to document analysis, which the BA needs to review prior to elicitation. We will also look into a review of the enterprise analysis; followed by an analysis of the sponsor and stakeholders; defining of roles and responsibilities; and the pre-elicitation action planning. Once all these documents have been set up, the BA will be ready to develop the output of elicitation phase. These outputs will then be the inputs to the development of a formalized documentation for identifying the business needs; developing a solution scope, building the all-important business case; and formalizing stakeholder’s roles and responsibilities. Throughout the Business Analysis process same inputs can be used many times. These inputs can be updated as new information is gathered during the progress of the analysis. In other words, at this preliminary information gathering stage, the items in the agenda will morph over time and can be used in multiple iterations throughout the process. Let us discuss the general business analysis scenarios in the next slide.

2.4 General Business Analysis Scenarios

There are two distinct situations faced in Business Analysis. In the first situation, a client has determined what has to be done for a company, but the company does not have the in-house expertise to implement the desired changes. In the second situation, client is not sure of the changes that are to be done to improve the company performance. The first situation is referred to as a plan-driven analysis while the second is called a change-driven analysis. In a plan-driven analysis, the general requirements are known, and implementation of needed changes is well understood. For example, a company may need a software application to help streamline a process or a procedure. An outside 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 usually 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 company and the contractor as the scope and cost estimation of the project are well understood. Change-driven analysis is carried out when a client is not sure of what needs to be done to make the required changes. The Business Analyst acts more 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, company, 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 some way or the other. They are continuously dealing with problems and solutions. However, the internal politics of a company 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 implication of objectivity and new perspective. 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 over time bring valuable insights and solutions to the process. Learning how to make the right changes and reducing the political risks, company managers contribute towards 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 Analyst. Business Analysis is seen as a credible tool in any business evolution and development, and that fact demands that each BA represent the profession in a highly effective and ethical manner. We will look into document analysis in the next slide.

2.5 Document Analysis

Once a potential client expresses interest in a project, the BA should ask for documentation to understand the business. Most companies will require a Non-Disclosure Agreement (NDA) for confidentiality, before sending or communicating any important or proprietary information, or documentation. Once the BA reviews the documentation, it helps to facilitate an in-depth elicitation from the sponsor and stakeholders. An effective BA should be able to ask the right questions. Studying the documentation is the first step in pre-elicitation. The following are the standard documents for review. At this stage, the BA tries to review the documents without disturbing the potential client. In general terms, a business plan is an important document that is developed to help the company document its goals, strategies, and tactics to reach those stated goals. Some business plans are very detailed and cover many areas that would be found in separate documentation. The business plan should be the first document to be reviewed. Usually, the business plan will be for the current year. It is also important to find out if the business plan is being used to benchmark the actual performance towards stated goals. Strategic plan is about the strategies the company plans to use to compete in the market place, as well as positioning products into certain market segments, penetration into new markets, or introducing new products or services and defensive competitive positioning. Marketing plan focuses on sales and marketing activities. It strategizes on gaining new customers and retaining the existing customer base. Larger companies are structured into Strategic Business Units (SBUs) and each unit has its own marketing plan for its market segment. Importantly, the marketing plan usually contains budgeting, and important benchmarks and metrics to constantly monitor performance. We will continue our discussion on the standard documents to be reviewed in the next slide.

2.6 Document Analysis(contd.)

Business rules, procedures, and policies are usually found in the company policies and procedures manual where there is a detailed description of standard operating procedures (SOPs), and acceptable parameters for day-to-day operations. Process flow is often difficult to understand if it is not clearly explained in the policies and procedures, usually in the form of a process flow chart. However, an experienced BA should have an idea of industry-specific functions and it is up to him/her to understand the process flows in the client’s industry. Enterprise architecture is another name for company organization chart. This helps to detail the processes, the chain of command, and the areas of responsibility and accountability. However, what is on paper may not be the reality. This is one of the first findings to be looked for once the BA is in the elicitation phase of the project. The BA has to assess the company assets and abilities to be able to make the required changes; otherwise, an outside vendor may be required. We will look into some more standard documents to be reviewed in the following slide.

2.7 Document Analysis(contd.)

Job descriptions are a more detailed aspect of the organization. In a fully documented organization plan, job descriptions should match each category of employees along with their responsibilities and accountabilities. Job descriptions will help the BA identify the subject matter experts and other stakeholders. Trouble shooting documents are not always available in most companies. However, if a company has a formalized quality control program like Six Sigma or ISO 9000, there normally is a good paper trial on operational problems and traceability of the solutions. Financial reports are generally the most confidential and are not disclosed without a signed NDA unless the company’s CFO is tasked with providing performance metrics. In case of some less sophisticated companies, the BA might have to develop quantitative measures for benchmarking and performance analysis. These metrics will require information from the company’s operating statements and balance sheets. IT system description schematic is important for a specific software requirement and solution. Even if the project is not software related, the BA should have a good understanding of how the internal IT and communications function. , Let’s move on to enterprise analysis in the next slide.

2.8 Enterprise Analysis

Enterprise analysis describes how Business Analysts identify plans to extract the business needs and help in defining a solution scope that can easily be implemented by the business. As enterprise analysis is the pre-elicitation phase of the project, it becomes more refined during the process of elicitation. However, most projects will have an idea of what the perceived needs of the client are and what the associated problems might be. As the enterprise analysis is a knowledge area, it will be discussed in detail later in the course. At this preliminary stage, the BA needs to start forming a general idea of what will be found at the company. The following are the general ideas to be formed by the BA during a preliminary enterprise analysis: Defining the problems and opportunities is a premature stage; however, an experienced BA can generally forecast what will be found on-site at the company. Assessing organizational capacities and gaps can be found by looking at the current organizational structure and what may be needed to install the possible solutions. Forming the first phase of the solution scope is also premature, but an experienced BA will have a good estimate from past experience of what potential solutions might be. In the pre-elicitation stage, it can help to have some pre-conceived ideas to test to see if they could be problems. When the BA asks if a common situational problem exists, and it does, it can help to rapidly build trust by demonstrating that the BA has some relevant experience right at the start of the project. Developing a business case for proposed solutions is a natural outcome of the prior research items. Again, at this stage, the BA is setting the ground work so the relevant questions can be asked during the elicitation phase. The business case is a document that provides the narrative reasoning for the project. It is the key document to obtain the go ahead for the implementation of the project; however, that comes later when there is validated information to form the best solutions. Let us understand sponsor and stakeholder analysis in the next slide.

2.9 Sponsor and Stakeholder Analysis

Following are the steps to be followed during sponsor and stakeholder analysis: Sponsor interview is the first step in the elicitation phase. Once the BA has a general understanding of the company 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 has been pre-approved. However, the BA should establish if the sponsor is the real decision maker, or what the actual decision process will be before a project is ready for implementation. The sponsor interview will provide the sponsor’s perception of what the business needs are, and helps to 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 as given, until 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 provided during the Sponsor interview will help the BA to chart out the organizational structure along with the associated stakeholders and SME’s (to be read as S M E’s) who play a key role in the processes to be examined. Preliminary needs and requirements are the output of the sponsor interview. This provides a good starting point for meeting the other stakeholders. It also confirms if the stakeholders and SMEs are in agreement with the sponsor. Key stakeholder evaluations are obtained verbally from the sponsor, or from company evaluations. Let us find out the roles and responsibilities in the next slide.

2.10 Roles and Responsibilities

Identifying project roles in the pre-elicitation phase is derived from 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 what the project may look like. This preliminary idea can form the ground work for identifying the roles and responsibilities required, which are subject to change as the process progress. Following are the roles and responsibilities: Application architect helps to identify and design the solution structure. Business Analyst is responsible for gathering requirements, planning, coordinating, and communicating with team members and stakeholders. Project manager is responsible for managing the implementation of the project and coordinating the project milestone activities. Database analyst reviews and analyzes the database resources and develops any new database policies and procedures. 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.11 Roles and Responsibilities(contd.)

Executive sponsor is usually the “champion” and decision maker for the project. Infrastructure analyst helps define, design, or adapt hardware and technical infrastructure. Quality assurance person is responsible for ensuring that the solutions meet the company QC (quality control) policies and procedures. 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.SME is the subject matter expert who is responsible for expert advice, information, and related requirements for a particular solution. Trainer is responsible for training end users and others in properly using the new solutions. Team RACI matrix documents the various roles, responsibilities, accountabilities, and communication requirements. Let us understand RACI Matrix in the next slide.

2.12 RACI Matrix

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

2.13 Pre-Elicitation Planning Considerations

The BA should now have a general idea of what the company needs and requirements are. In addition, the BA should have an idea of who the key stakeholders and SMEs are, along with how the business functions. With this preliminary information, it’s time to set up the next phase of the analysis process – the elicitation of detailed information. This information comes from a mix of activities aimed at clearly identifying the needs and requirements from the key employees and stakeholders. This happens in multiple ways to gain a consensus of those needs and requirements with the intent of developing the solution scope. The inputs for mobilizing the elicitation process are made up of the following documents that were started during this pre-elicitation phase: The business case until this point in the analysis process has been developed by the BA mainly through documents analysis and the sponsor interview. This document is used as a guide to elicit responses from stakeholders and SMEs. Business needs are also made available for discussion to gather more input and consensus. Solution scope is based on preliminary information and is used to evoke other ideas for solutions and the possible risks and problems from the people who work in the process every day. Stakeholder’s roles and responsibilities are also used to draw input and modifications. The more or less speculative pre-elicitation phase will be accomplished by focusing on the numerous opinions and experiences with the specifics of the company’s situation. This adds substance and depth to the preliminary analysis gathered so far. As the analysis progresses, more detail is added to the planning documentation. Until the project is complete, the analysis is in-progress proposition. Choosing the elicitation activities depends on the scope of the project. If the need and requirements are confined to a segment or department of the business, much of the elicitation can be done in one-to-one confidential interview. However, if the project is to be more expansive, it makes sense to use more group activities. At all times, the BA must be sensitive and realize that many employees are reluctant to speak freely in groups unless some measure of confidentiality is assured. For group activities, this issue can be handled by using anonymous responses written on paper. The different types of elicitation activities are: Brainstorming is a free flow of sharing ideas. Its focus is on creative thinking and allowing new and different perceptions to be shared with others. Being correct is not important, as the ideas and different perspectives is the goal. We will continue our discussion of pre-elicitation considerations in the next slide.

2.14 Pre Elicitation Planning Considerations(contd.)

Focus groups can be effective for brainstorming as it allows for cross pollination of ideas from other departments and draws on a wider range of experiences. Focus groups are also good when specific problems or solutions are being considered. Prototyping is building a simulation either in word or material to test a certain hypothesis. Observations are when the BA directly observes the areas of concern or remains hidden so as to not influence the outcome or behavior of employees. Requirements workshops are very effective when gathering information from a group for a consensus on all the important aspects of needs and requirements. Surveys and questionnaires are a good method to seek input on specific written questions from a large population of employees. This important technique taps into the pervasive informal rumors that can expose, and add validity to problems that may be politicized, or buried in the higher levels of the company. Interface analysis can be very important at junctures in new process, procedures or software where the new implementation will affect adjoining processes or procedures. This can be very important during the implementation of new software solutions with existing legacy systems. Two SMEs from the adjoining departments affected by new implementations are usually very effective in identifying interface problems. Scheduling can be very costly to the client if the elicitation activities interfere with the orderly flow of the company’s business. It is important for the BA to coordinate the elicitation schedule with management to establish the best times and places for the elicitation events to take place. Documentation is important in supporting the elicitation findings; however, confidentiality must be protected and the elicitation participants must be convinced of this if honest input is to be gathered. If the stakeholders and SMEs have a different perception from the sponsor, it will be important for the BA to have some credible data to help support any of the conflicting ideas. Let us look at the pre-elicitation diagram in the next slide.

2.15 Pre Elicitation Planning

This slide depicts a diagram that explains the inputs that go into preparing for the elicitation process. The box on the upper left contains the documents like business case, documents analysis, business needs, solution scope, and stakeholder’s roles and responsibilities that need to be prepared. The box below pre-elicitation planning displays the various activities like brainstorming, focus groups, interviews, observations, prototyping, requirements workshops, surveys and questionnaires, risk analysis, and identify key stakeholders to employ during the elicitation process. All of these items should be documented and ready for input from the elicitation. These are required to conduct elicitation activities. Moreover, using the schematic provides structure for the elicitation process. Let us discuss developing the business needs in the next slide.

2.16 Developing the Business Needs

Developing the business needs is a continuation of the identification, verification, and narrative of the business needs that bring about the project requirements, which then lead to the solutions and deliverables. Up to this point, the business needs have been assumed, stated, or presented in the sponsor interview. The elicitation activities will add new depth to the cursory assumptions. The BA should appoint a team member to take notes to document key points as well as identify contributors. The following are the key inputs: The elicitation analysis is based on stakeholder and SME input on business needs, requirements, and potential solutions. The results will add more detailed information to what has already been gathered prior to the elicitation activities. The new information should verify what the sponsor has already stated and may provide additional needs that may be stand alone or a subset of the first pass at the needs. Moreover, as the needs were elicited, the BA can determine from the elicitation documentation which stakeholder or SME is the real expert and what roles might be assigned during solution and installation phases. Documentation analysis will be reviewed again to take a look at the accumulated information on business needs and determine if the needs fit within the context of the company’s stated goals and strategies. The BA again reviews the existing processes, procedures, and policies to see how the potential solutions might impact the company. Sponsor needs should be more or less in agreement with those that will be presented by the elicitation activities to come. However, if there are significant divergences or levels of complexity, the BA will need to prepare for a new interview with the sponsor to help reconcile and work for consensus. A second meeting on needs may help define who exactly the decision maker(s) is. Stakeholder needs can confirm, deny, or redirect the perceived sponsor needs. It is also important for the BA to keep in mind that stakeholder political factors can play an important role in defining what they see as needs. Organizational assets capabilities 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 company to use its current assets (manpower, equipment, and funding) to make the necessary changes. Often, outside specialized vendors may be needed to fill the gaps in organizational capabilities. Building the narrative is the goal of the business needs document. In the future, it becomes an important part of the business case that presents a story of how the project will benefit the company. The business case is usually the formal document that provokes the project’s formal approval and funding. Let us understand the planned elicitation outputs diagram in the next slide.

2.17 Planned Elicitation Outputs Diagram

This diagram demonstrates that the results from the elicitation are once again subjected to the same processes and tasks used in the elicitation. This is to review the results and put them through another filtering process to distill the results further. The output box represents the desired outputs like confirming business needs and requirements, identify risks and constraints, prioritize requirements, identify transition requirements, identify key stakeholders, start formation of solution scope, add depth and breadth to business case, and assess organizational capabilities and readiness as a result of the post-elicitation review. Again, the analysis process is a series of repeating events that help refine and validate the needs, requirements, and solutions. Let us discuss developing a solution scope in the next slide.

2.18 Developing a Solution Scope

Solution scope is based on preliminary information, and is used to evoke other ideas for solutions, and the possible risks and problems from the people who work in the process every day. Following are the points to be kept in mind while developing a solution scope: The purpose of the solution scope is to help conceptualize solution in enough detail to enable the stakeholders to understand which new business capabilities and new process, or IT business solution will deliver. The solution scope attempts to create a shared vision. For enterprise projects, the scope statement is often written based on the possible positive and negative impacts on people, processes, and technologies as found in the business case narrative. The most important challenge in developing a solution scope is making it clear enough for stakeholders and sponsors to understand. The solution scope is built on the shoulders of the needs and requirements. Requirements management plan is usually developed after the business needs have been elicited. Once the needs have been prioritized during elicitation, the requirements to meet the needs are also defined and prioritized through consensus. The solutions depend on the requirements. If the requirements change, so does the solution scope and for this reason, the BA should document the requirements and when they are changed, validated and the part t requirements play in the solution scope. Stakeholder consensus is required on what solutions are needed, and what will be the next order of business during the elicitation phase. Although the details of each solution will not be the focus, the general idea of the fixes required is noted, and a general discussion of potential risks to the solution are discussed in general to be more clearly defined, along with the actual solution tasks later in the project. Organizational capabilities assessment will be studied after the stakeholder consensus solutions, to ascertain if the company will need to outsource certain capabilities. If it is seen that outsourcing will be needed, RFQs, RFPs, or RFIs will need to be sent out to the identified vendors. We will continue our discussion on developing a solution scope in the next slide.

2.19 Developing a Solution Scope (contd.)

Stakeholder’s roles and responsibilities are temporarily assigned according to the direct level of experience with a particular solution. Ownership of the solution will be assigned later in the process. Conflict management will be a concern as differing perceptions, solutions, and ideas concerning roles and responsibilities can cause knee jerk reactions. The BA will need to assure the stakeholder participants that during the elicitation phase, nothing will be set in stone and there will be opportunities for changes and amendments. Conflict management is a key capability for any BA and can, in some cases, mean the difference for a successful project. Following are the anticipated output from the elicitation planning: Requirements management lists are the link between needs and solutions. Any one of the three can require a new solution. During the process, needs and requirements can change and these will directly affect the solutions scope. Therefore, needs, requirements, and solutions require traceability along with explanations for changes. Solutions proposals from the stakeholders form the base of the project. The stakeholders and SMEs are the onsite experts and fully understand the current situation and how changes may affect the effectiveness and complexities of installing the proposed solutions. Usually, as requirements are more closely defined, solutions will also change. Therefore, the solutions scope can be altered throughout the process. Solutions proposals refer to the formal and informal solutions proposals. For example, once there is a consensus, the BA may either write up the proposal, or to save time, call the stakeholder or sponsor to get their opinions. This helps save time but informal proposals should at least be noted in a daily journal, if not formally proposed. Company outsourcing needs add considerable expense to the project but may be unavoidable. If the stakeholder consensus is that the company does not have the assets or skills to make the necessary changes, request for quotes (RFQs), or request for information (RFI) from vendors will help form an estimate of how outsourcing will impact the project. If the sponsor is not aware of the need for outsourcing, they should be notified immediately. Let us look at solution scope development diagram in the next slide.

2.20 Solution Scope Development Diagram

This diagram demonstrates the inputs needed to help manage the solution scope and requirements. The input box to the left uses information from the stated documents. The box underneath shows the tasks required for input into the solution scope and requirements document. The output is submitted for validation from stakeholders, SMEs, and sponsor. Another input into the validated requirements is based on prior ideas and experiments to help in the validation process. In the next slide, let us learn developing the business case.

2.21 Developing a Business Case

The business case is a document used as a guide to elicit responses from stakeholders and SMEs. Following are the points to be kept in mind while developing the business case: The purpose of the business case is to describe the justification for the proposed project in terms of cost-benefit to business, as a result of the installed solution. It tells the story of how the needs justify the needed changes and how those changes are within the company’s goals and objectives. Normally, the business case is presented to the board of directors for budgetary and implementation approvals. The elicitation will help provide needed depth and history for the narrative to be developed. An important part of the business case is presenting a cost benefit analysis of the project that will require detailed budgeting, cash flow analysis, and return on investment for the project. Assumptions and constraints focus on the underlying assumptions of what is causing the need. The elicitation will draw on the daily experience of the stakeholders and SMEs to make sure the assumptions are valid. An important aspect of verifying the assumptions is to get input from any tangential departments or processes that may be affected by proposed solutions based on the assumptions. Sometimes there are unforeseen consequences of change. Once the assumptions are validated, the potential risks need to be assessed. In the process of prioritizing requirements and solutions, the associated risks can play an important role in whether certain needs will be mitigated, circumvented, or assumed. Business needs will be a major focus of the elicitation phase and needs 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. Solution scope evolves as the project progresses but the elicitation phase goes a long way in providing depth and breadth to the project. Moreover, during the elicitations, key stakeholders, and SMEs can be identified for specific roles in further development of the solutions and their implementation. Stakeholder concerns need to be clearly identified, assessed, and de-politicized as much as possible. The BA needs to remain neutral on any political issues and only interested in serving the consensus needs of the company and sponsor. As mentioned, this pre-elicitation planning phase helps prepare the BA to elicit the proper areas of concern as well as start the project documentation process. Chief among them is the business case. As the results of the elicitation become known and documented, the documentation begins to expand in content as well as adding task and technique details. Let us move on to the stakeholder’s roles and responsibilities.

2.22 Stakeholder's Roles and Responsibilities

Stakeholder’s roles and responsibilities are used to draw input and modifications. Following are the steps carried out during the formation of stakeholder’s roles and responsibilities: A stakeholder analysis takes place after the elicitation activities have taken place. It is performed as soon as a business need is identified and will usually be an ongoing activity as long as the Business Analysis continues. Stakeholder analysis begins with identifying stakeholders who may be affected by the business need or a new solution. The analysis will try to identify the best stakeholder(s) to assume ownership of proposed solutions in their domain. Later in the process, stakeholders will be queried as to their interest and ability of assuming key roles in the development and implementation of solutions in their domains. Stakeholder attitude may require more time and investigation post the elicitation activities. However, it is important for the BA and sponsor. The human nature is to resist changes to routines and procedures; particularly if there is nothing “in it” for the stakeholder. Negative attitudes about the sponsor, company management, and other internal issues can greatly affect the success of the project. If the BA detects negative attitude towards the project, it is imperative to find out the reasons and how the attitude can be improved. This is important when the selection of key stakeholders for the solution and implementation of changes is being made. While it might seem obvious that an SME be placed in a position of responsibility, it must be determined if that person is interested in assuming responsibility and if they have the leadership skills to assume a key position. So, once key stakeholder roles and responsibilities have been initially established, due diligence on attitude and ability is required. Authority levels describe what levels of authority each role would have. A good idea is to provide a job description for the key stakeholder that specifies what authority and responsibility comes with the role. For example, will the stakeholder have the authority to change the design of the solution? Will they be able to override the quality assurance member of the team? Will there be a designated chain of command for the responsibility of the task? Use of the RACI matrix can help define in a brief table who is responsible for what actions and who reports to whom. There should also be an established protocol for any changes that are contemplated before making any actual change. The impact on stakeholders can be surprising if the stakeholder is not aware of what happens in a change related project. The BA can expect more pressure during the formation of stakeholder’s roles and responsibilities. The next slide explains the impact on stakeholder with the help of the onion skin diagram.

2.22 Stakeholder's Roles and Responsibilities

Stakeholder’s roles and responsibilities are used to draw input and modifications. Following are the steps carried out during the formation of stakeholder’s roles and responsibilities: A stakeholder analysis takes place after the elicitation activities have taken place. It is performed as soon as a business need is identified and will usually be an ongoing activity as long as the Business Analysis continues. Stakeholder analysis begins with identifying stakeholders who may be affected by the business need or a new solution. The analysis will try to identify the best stakeholder(s) to assume ownership of proposed solutions in their domain. Later in the process, stakeholders will be queried as to their interest and ability of assuming key roles in the development and implementation of solutions in their domains. Stakeholder attitude may require more time and investigation post the elicitation activities. However, it is important for the BA and sponsor. The human nature is to resist changes to routines and procedures; particularly if there is nothing “in it” for the stakeholder. Negative attitudes about the sponsor, company management, and other internal issues can greatly affect the success of the project. If the BA detects negative attitude towards the project, it is imperative to find out the reasons and how the attitude can be improved. This is important when the selection of key stakeholders for the solution and implementation of changes is being made. While it might seem obvious that an SME be placed in a position of responsibility, it must be determined if that person is interested in assuming responsibility and if they have the leadership skills to assume a key position. So, once key stakeholder roles and responsibilities have been initially established, due diligence on attitude and ability is required. Authority levels describe what levels of authority each role would have. A good idea is to provide a job description for the key stakeholder that specifies what authority and responsibility comes with the role. For example, will the stakeholder have the authority to change the design of the solution? Will they be able to override the quality assurance member of the team? Will there be a designated chain of command for the responsibility of the task? Use of the RACI matrix can help define in a brief table who is responsible for what actions and who reports to whom. There should also be an established protocol for any changes that are contemplated before making any actual change. The impact on stakeholders can be surprising if the stakeholder is not aware of what happens in a change related project. The BA can expect more pressure during the formation of stakeholder’s roles and responsibilities. The next slide explains the impact on stakeholder with the help of the onion skin diagram.

2.23 The Impact on Stakeholders The Onionskin Diagram

In the image in the slide, the concentric rings represent the impact of changes on stakeholders; the further out from the solution delivery, the less direct impact on stakeholders in the particular section. For example, customers are stakeholders but are usually less affected than those employee stakeholders 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 at different degrees. We have come to an end of this module. Let us summarize what was covered so far in the next slide.

2.24 Summary

In this module, we have discussed a broad introduction to the planning of the general business analysis process. Many documents used in the planning phase are developed as the process progresses. They usually start as just a template that build up layers of information as each step in the process is executed. We start with the preliminary document analysis, to help give the BA some preliminary information about the company history, goals, mission statement, policies and procedures, and reports used in the operation. Enterprise analysis describes how Business Analysts identify plans to extract the business needs and help in defining a solution scope that can easily be implemented by the business. Documents such as the enterprise architecture (organization chart), provides names, positions, and responsibilities of stakeholders and studied before starting the face-to-face interpersonal part of the sponsor and stakeholder analysis. This preliminary information is necessary to enable the BA to develop the pre-elicitation plan and to ask relevant questions of the stakeholders, SMEs and sponsor. The pre-elicitation plan also develops the elicitation activities to allow stakeholder consensus on needs, requirements, solutions, and perceived risks. Once there is a prioritized list of needs, requirements and solutions, the BA will have the information to piece together the business needs, the solution scope, and the business case. Then, roles and responsibilities of stakeholders can be assigned for the teams that will be responsible for the development and implementation of the Solution Scope. Once the business case has been documented, the BA presents the consensus findings to the decision making process of the company for approval or amendments. Up to this point, no implementation has taken place. Now, let us go through a few questions to check your understanding on the concepts discussed. In the next module we will understand elicitation.

Find our CBAP®-Certified Business Analysis Professional Online Classroom training classes in top cities:


Name Date Place
CBAP®-Certified Business Analysis Professional 20 Oct -11 Nov 2018, Weekend batch Your City View Details
CBAP®-Certified Business Analysis Professional 24 Nov -16 Dec 2018, Weekend batch Your City View Details
  • 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*