Before we can start building a business solution, we need to know what the users of that solution want it to do for them! Thus, the business analyst's most important role is to ensure that what the users (and other stakeholders) want is carefully captured, documented, analyzed, and then transmitted unambiguously to the people who are actually going to implement it. In many cases, the term "business solution" implies an information technologies (IT) solution with a software application as one of the end products. However, a solution can involve other technologies as well, or it might even encompass a simple business process improvement project with no new technology added. Business Analysis Planning and Monitoring The project manager and project team rely on the business analyst to provide well-defined and documented requirements. This requires a disciplined and methodical approach to requirements elicitation, documentation, and communication. The Business Analysis Planning and Monitoring Knowledge Area in Chapter 2 of the BABOK® focuses on this topic, presenting specific tasks that the business analyst should carry out in order to achieve high-quality, unambiguous, and actionable requirements. This planning process allows the business analyst to However, before any work is done, the Business identify both tasks and people (including project team Analyst needs to carefully plan the work to be done, members and stakeholders) that are instrumental for which deliverables to produce, identify the effective requirements elicitation. The success of the stakeholders involved (and how he will communicate requirements elicitation process and the quality of the with them), and how to monitor whether the BA efforts requirements themselves depend on quality work, for are on course with the overall project. These tasks are which an effective plan addressing tasks and overall described in the Business Analysis Planning and process management is quite important. Monitoring Knowledge Area. Deliverables As it turns out, the well-documented techniques of project management are well-suited to defining how business analysis activities are going to be performed in the context of the project. In some ways, you might consider this planning process as a mini-project within the scope of the "actual" or overlying project. If the project were to be developed sequentially, business analysis planning would begin after the enterprise analysis has been completed. In reality, of course, you may need to start planning your requirements gathering even before all the enterprise analysis is finished. The deliverables of BA Planning and Monitoring include lists of: Identified stakeholders associated with the project, along with their roles and responsibilities. Deliverables to be produced along with the templates, standards, etc. used by the organization. Specific tasks for requirements gathering along with the people responsible for those tasks. Techniques used to perform the elicitation and communication activities, as well as to estimate the amount of BA work required. Metrics used to assess the BA work and estimates on the duration of BA tasks. Upon completing this lesson, you should be able to: Identify the stakeholders for a particular project or initiative. Define the roles and responsibilities for the different stakeholders as they pertain to the current project. Determine the approach to be selected for performing BA work, including the SDLC methodology to be used. Develop a Business Analysis Plan, which includes the planned BA activities, estimates to complete required business analysis tasks, and deliverables that the BA will produce. Develop a communication plan for the BA effort. Develop a plan to manage requirements implementation (i.e., how requirements are approached, traced and prioritized), as well as define a process for requirements change. Define the metrics to be used in assessing the business analysis work effort and the process used to determine if the BA effort needs preventive or corrective action. Plan Business Analysis Approach Carrying out the project-related business analysis activities requires a carefully assembled plan. Developing this plan is the responsibility of the project manager working with the business analyst. Without a good plan, there is a danger of not capturing all the requirements or defining them poorly, which could lead ultimately to a final product that doesn't meet the users' acceptance criteria. Some industries or organizations have specific methodologies for building their products. For instance, software development has the System Development Life Cycle (SDLC) and Project Life Cycle (PLC) methodologies. Since these kinds of methodologies usually include requirements elicitation, a business analyst working for a company that has adopted such a methodology will need to follow it in developing a requirements process plan. Additional factors to consider during this planning stage include: Stakeholder expectations Organization or industry standards (that may govern how projects are implemented) Do the business analysis planning activities need to be tailored for a particular project or initiative? Steps to Implementation The first step is to identify all the stakeholders from whom the business analyst will elicit requirements. These stakeholders include anyone who has an interest in the functional aspects of the final product. For example, the user of a software package definitely has an interest in how the package works. However, an upper-level manager who only wants to see reports (printed on paper) generated by that software package may not care how the software works. She only wants to see the reports! At this point, the business analyst must decide how to approach the relevant stakeholders. Some may be physically remote and require travel or teleconference sessions while others are local and amenable to in-person meetings. Next, the analyst must determine which specific methods of eliciting requirements are appropriate both for the stakeholder being interviewed and the type of information that needs to be acquired. Details of these methods are presented in Lesson 4. After the business analyst has captured and compiled all the requirements, he must decide upon an appropriate approach for analyzing these requirements and determine the best approach for documenting them. Along with documentation, communication plays a critical role. No matter how well requirements are written down, they are not very useful unless the business analyst can communicate them effectively to various decision makers and the technical personnel who will implement them. These activities are covered in Lessons 5 and 6. Finally, business analysts must work with a project delivery team to identify implementation tasks in the form of a work breakdown structure (WBS) and formalize a means of evaluating how well the solution meets stakeholders' needs. This is covered in Lesson 7. The Business Analysis Approach According to the BABOK,® a Business Analysis Approach describes the set of processes, templates and activities that will be used to perform business analysis in a specific context (i.e., a project or initiative). There are many ways to approach business analysis work. One approach is to use established methodologies for software development (Waterfall/Agile) or business process improvement (Lean/Six-Sigma). An organization can also use a proprietary methodology or in-house practices and process. The Organizational Process Assets defines the standards, templates and deliverables regarding how business analysis is done in the organization and how it fits into a project and other activities. Other factors to consider when planning the BA approach are: the Business Need - the problem of opportunity faced by the organization (and the reason for the project!) and Expert Judgment - the BA expertise either from within the organization and/or the industry at large BA Methodologies A plan-driven methodology emphasizes Change-driven methodology focuses on rapid planning and formal documentation of the delivery of solution capabilities in an processes used to accomplish a project and of incremental fashion (i.e., Agile) and direct the results of the project. This methodology is involvement of stakeholders to gather feedback concerned about reducing upfront risk and on the solution's performance. This having control over outcomes over the delivery methodology will accept a higher degree of of a solution. This approach is preferred when uncertainty (risk) regarding the overall delivery requirements can effectively be defined in of the solution in exchange for the flexibility to advance of implementation and the risk of an manage requirement changes. incorrect implementation is unacceptably high (think medical equipment or an oil refinery), or when managing stakeholder interactions presents significant challenges. Plan-driven vs. Change-driven Methodologies Almost all methodologies fit along a spectrum between Plan-driven and Change-driven methodologies. 1. Which one of the following activities is not part of the Plan Business Analysis Approach task? a. Abiding to regulatory standards and federal guidelines. b. Understanding the problems or opportunities facing the organization. c. Developing a marketing plan to promote the product in the local market. d. Using the standard document templates mandated by the organization. 2. According to the BABOK,® Organizational Process Assets is an input to all of the tasks in the Business Analysis Planning