logging in or signing up introduction to babok- business analysis, planning & monitoring mcomtraining Download Post to : URL : Related Presentations : Share Add to Flag Embed Email Send to Blogs and Networks Add to Channel Uploaded from authorPOINT lite Insert YouTube videos in PowerPont slides with aS Desktop Copy embed code: (To copy code, click on the text box) Embed: URL: Thumbnail: WordPress Embed Customize Embed The presentation is successfully added In Your Favorites. Views: 349 Category: Education License: All Rights Reserved Like it (0) Dislike it (0) Added: September 24, 2010 This Presentation is Public Favorites: 1 Presentation Description No description available. Comments Posting comment... Premium member Presentation Transcript Introduction to BABOKTM : Introduction to BABOKTM IT BUSINESS ANALYSIS LECTURE 2 Business Analysis Planning & Monitoring Slide 2: A Guide to the Business Analysis Body of Knowledge (BABOK) is the written guide to the collection of business analysis knowledge reflecting current best practice, providing a framework that describes the areas of knowledge, with associated activities and tasks and skills required The business analysis body of knowledge defines 6 knowledge areas, which group together related sets of tasks and techniques. Each of these tasks and techniques describes the typical knowledge, skills, processes, and deliverables that the business analyst requires to be able to perform those tasks competently. While a flow of tasks and processes is suggested by these knowledge areas, the BABOK is deliberately not setting out a prescribed methodology. IT BUSINESS ANALYST : IT BUSINESS ANALYST IT BUSINESS ANALYST : IT BUSINESS ANALYST IT BUSINESS ANALYST : IT BUSINESS ANALYST Domains A domain is the area undergoing analysis. It may correspond to the boundaries of an organization or organizational unit, as well as key stakeholders outside those boundaries and interactions with those stakeholders. Solutions A solution is a set of changes to the current state of an organization that are made in order to enable that organization to meet a business need, solve a problem, or take advantage of an opportunity. The scope of the solution is usually narrower than the scope of the domain within which it is implemented Requirements A requirement1 is: A condition or capability needed by a stakeholder to solve a problem or achieve an objective. A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents. A documented representation of a condition or capability as in (1) or (2). IT BUSINESS ANALYST : IT BUSINESS ANALYST Tasks Each knowledge area describes the tasks performed by business analysts to accomplish the purpose of that knowledge area. Techniques Each task contains a listing of relevant techniques. Some techniques are specific to the performance of a single task, while others are relevant to the performance of a large number of tasks IT BUSINESS ANALYST : IT BUSINESS ANALYST Input An input represents the information and preconditions necessary for a task to begin. Inputs may be: Explicitly generated outside the scope of business analysis (e.g., construction of a software application). Generated by a business analysis task. IT BUSINESS ANALYST : IT BUSINESS ANALYST Output An output is a necessary result of the work described in the task. Outputs are created, transformed or change state as a result of the successful completion of a task. Although a particular output is created and maintained by a single task, a task can have multiple outputs. An output may be a deliverable or be a part of a larger deliverable. The form of an output is dependent on the type of initiative underway, standards adopted by the organization, and best judgment of the business analyst as to an appropriate way to address the information needs of key stakeholders. IT BUSINESS ANALYST : IT BUSINESS ANALYST Stakeholders Each task includes a listing of generic stakeholders who are likely to participate in the execution of that task or who will be affected by it. A generic stakeholder represents a class of people that the business analyst is likely to interact with in a specific way. IT BUSINESS ANALYST : IT BUSINESS ANALYST Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring AN INTRODUCTION Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring The Business Analysis Planning and Monitoring Knowledge Area defines the tasks associated with the planning and monitoring of business analysis activities Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Approach Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Approach Purpose This task describes how to select an approach to performing business analysis, which stakeholders need to be involved in the decision, who will be consulted regarding and informed of the approach, how and when tasks will be performed, the techniques that will be used, and the deliverables that should be produced. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Approach Key Points There are multiple established ways to approach business analysis / business process improvement work (waterfall approach, RUP, agile techniques, Lean, Six Sigma, as well as many proprietary and in-house methodologies, customs, and practices.) Elements from different approaches may be combined; however only a subset of all possible combinations will be viable for the particular organizational environment in which an initiative is being performed. In order to plan the business analysis approach, the business analyst must understand the organizational process needs and objectives that apply to the initiative. The business analysis approach is often based on or related to the project approach, but in some cases they may be independently determined (for example, an organization may use a plan-driven approach to define its business processes and then use a change-driven approach to build the supporting software applications). Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Approach INPUTS Business Need: The business analysis approach will be shaped by the problem or opportunity faced by the organization. It is generally necessary to consider the risks associated with it, the timeframe in which the need must be addressed, and how well the need is understood. This will help determine whether a plan-driven or change-driven approach is appropriate. Expert Judgment: Used to determine the optimal business analysis approach. Expertise may be provided from a wide range of sources including stakeholders in the initiative, organizational Centers of Competency, consultants, or associations and industry groups. Organizational Process Assets: Include the elements of existing business analysis approaches in use by the organization. Organizational process assets that may be useful in defining the business analysis approach include methodologies for process change or software development, tools or techniques that are in use or understood by stakeholders, corporate governance standards and templates for deliverables. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Almost all Business Analysis methodologies fit somewhere along a spectrum between plan-driven and change-driven approaches. Plan-driven approaches focus on minimizing up-front uncertainty and ensuring that the solution is fully defined before implementation begins in order to maximize control and minimize risk. Change-driven 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. The performance of this task is dependent on where the selected approach falls on this spectrum. Plan Business Analysis Approach Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Approach Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Approach TECHNIQUES Decision Analysis : May be used to rate available methodologies against the organizational needs and objectives. Process Modeling : Process Models can be used to define and document the business analysis approach. Structured Walkthrough: This can be used as a means of validating a created, selected, or tailored business analysis approach. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Approach Decision Analysis Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Approach Decision Analysis Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Approach PROCESS MODELLING Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Approach PROCESS MODELLING Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Approach PROCESS MODELLING Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Approach PROCESS MODELLING Without a Unified Notation, there is Chaos Unified Modelling Language Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Approach PROCESS MODELLING Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Approach PROCESS MODELLING INTRO TO UML : INTRO TO UML Activity Diagrams INTRO TO UML : INTRO TO UML Activity Diagrams INTRO TO UML : INTRO TO UML Activity Diagrams INTRO TO UML : INTRO TO UML Activity Diagrams ACTIVITY INITIAL STATE END STATE FLOW DECISION SWIMLANE TRANSITION Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Approach Structured Walkthrough Structured walkthroughs are working sessions that are performed to communicate, verify and validate requirements. Invited participants review and discuss a set of requirements. Participants are required to ask questions, and make comments and suggestions. Other issues may also be identified during the session. All questions, comments, concerns, and suggestions are recorded. A walkthrough may result in revised requirements as well as issues that require investigation. A walkthrough may also be referred to as a requirements review. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Approach Structured Walkthrough Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Approach Structured Walkthrough Rational Unified Process : Rational Unified Process RUP : RUP Where YOU go Tomorrow Depends on Where do YOU want to go Today - Bill Gates of Microsoft RUP : RUP Where YOU are Today Is all because of Where YOU didn’t go yesterday - Murphy of Murphy’s Law RUP : RUP Waterfall Model RUP : RUP System Development Life Cycle - SDLC RUP : RUP Iterative Development Model RUP : RUP Iterative Development Model RUP : RUP Iterative Development Model Iteration #1 Iteration #1 Iteration #3 Iteration #2 RUP : RUP RUP : RUP RUP : RUP What are the two approaches in Business Analysis Planning? RUP : RUP RUP is a method of managing OO Software Development It can be viewed as a Software Development Framework which is extensible and features: Iterative Development Requirements Management Component-Based Architectural Vision Visual Modeling of Systems Quality Management Change Control Management RUP : RUP Online Repository of Process Information and Description in HTML format Templates for all major artifacts, including: RequisitePro templates (requirements tracking) Word Templates for Use Cases Project Templates for Project Management Process Manuals describing key processes Process Structure : Process Structure Two dimensions. Horizontal axis represents time and shows the lifecycle aspects of the process as it unfolds. Vertical axis represents core process workflows, which group activities logically by nature. Phases : Phases Inception Elaboration Construction Transition Two dimensions of RUP : Two dimensions of RUP RUP : RUP RATIONAL UNIFIED PROCESS Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis Purpose This task covers the identification of stakeholders who may be affected by a proposed initiative or who share a common business need, identifying appropriate stakeholders for the project or project phase, and determining stakeholder influence and/or authority regarding the approval of project deliverables. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis Key Points Stakeholder analysis is performed as soon as a business need is identified Is usually an ongoing activity as long as business analysis continues. Stakeholder analysis begins with identifying stakeholders who may be affected by the business need or a new solution. Stakeholders may be grouped into categories that reflect their involvement or interest in the initiative. The roles, responsibilities, and authority over the requirements for each stakeholder or stakeholder group must be clearly described. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis Key Points (continued) Stakeholder analysis also involves understanding stakeholder influence on and attitude towards the initiative, and assessing positive and negative attitudes and behaviors which may affect the outcome of the initiative and acceptance of the solution Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis INPUTS Business Need: The business analysis approach will be shaped by the problem or opportunity faced by the organization. It is generally necessary to consider the risks associated with it, the timeframe in which the need must be addressed, and how well the need is understood. This will help determine whether a plan-driven or change-driven approach is appropriate. Enterprise Architecture: Describes the organizational units that exist, their interactions with other organizational units, customers, and suppliers, their responsibilities within the organization, and the roles and relationships within each organizational unit. Organizational Process Assets: Include the elements of existing business analysis approaches in use by the organization. Organizational process assets that may be useful in defining the business analysis approach include methodologies for process change or software development, tools or techniques that are in use or understood by stakeholders, corporate governance standards and templates for deliverables. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis TECHNIQUES Acceptance and Evaluation Criteria Definition Brainstorming Interviews Organization Modeling Process Modeling Requirements Workshops Risk Analysis Scenarios and Use Cases Scope Modeling Survey/Questionnaire RACI Matrix Stakeholder Map Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis Acceptance and Evaluation Criteria Definition MoSCoW is a prioritization technique used in business analysis and software development to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement - also known as MoSCoW prioritization or MoSCoW analysis. The capital letters in MoSCoW stand for: M - MUST have this. S - SHOULD have this if at all possible. C - COULD have this if it does not affect anything else. W - WON'T have this time but WOULD like in the future. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis Organization Modeling Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis Risk Analysis Risk analysis can help identify and manage areas of uncertainty that can impact an initiative, solution, or organization ELEMENTS OF RISK Risk Tolerance A key factor in determining the response that a person or organization will select in regards to a risk is to understand their tolerance for risk. There is no correct or ideal response—a general strategy must be adapted to each particular circumstance. The three general categories of risk tolerance are: Risk-Aversion Neutrality Risk-Seeking An individual or organization may exhibit different risk tolerances at different times. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis Risk Analysis ELEMENTS OF RISK (CONTD.) Assessment Assessment involves determining the probability that the risk will occur and the impact if it does occur. Each of these factors is assessed on a common scale (High, Medium and Low, a number from 1–5, and so forth). This enables analysis to focus on the most important risks. Response Response strategies determine how the organization will deal with a risk. For negative risks, strategies include: Acceptance Transfer Avoidance Mitigation For positive risks, acceptance is also a viable strategy. Other strategies include: Share Enhance Exploit Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis Scenarios and Use Cases Scenarios and use cases are written to describe how an actor interacts with a solution to accomplish one or more of that actor’s goals, or to respond to an event. While the terms scenario and use case are often used loosely, a scenario is generally understood to describe just one way that an actor can accomplish a particular goal, while a use case describes all the possible outcomes of an attempt to accomplish a particular goal that the solution will support. Scenarios are written as a series of steps performed by actors or by the solution that enable an actor to achieve a goal. A use case describes several scenarios in the form of primary and alternate flows. The primary or basic flow represents the simplest way to accomplish the goal of the use case. Special circumstances and exceptions that result in a failure to complete the goal of the use case are documented in alternate flows. INTRO TO USE CASES : INTRO TO USE CASES USE CASE Use cases describe the system from the user's point of view. Use cases describe the interaction between a primary actor (the initiator of the interaction) and the system itself, represented as a sequence of simple steps. Actors are something or someone which exists outside the system under study, and that take part in a sequence of activities in a dialogue with the system to achieve some goal. Actors may be end users, other systems, or hardware devices. Each use case is a complete series of events, described from the point of view of the actor. INTRO TO USE CASES : INTRO TO USE CASES Use case Diagrams INTRO TO UML : INTRO TO UML Use case Diagrams INTRO TO UML : INTRO TO UML Use case Diagrams ACTOR USE CASE Generalization DEPENDENCY Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Approach Scope Modeling Scope models are used to describe the scope of analysis or the scope of a solution There are many different standards for scope modeling. In general, the scope model selected will depend on the analysis techniques selected to further explore the scope. Examples Context Diagrams Use Case Diagrams Business Process Rational Rose : Rational Rose Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis Survey/Questionnaire A survey is a means of eliciting information from many people, sometimes anonymously, in a relatively short period of time. A survey can collect information about customers, products, work practices and attitudes. A survey may also be referred to as a questionnaire. Questions in a survey are of two types: Closed: The respondent is asked to select from available responses. This is useful when the range of user’s responses is fairly well understood, but the strength of each response category needs to be determined. The responses to closed questions are easier to analyze than those gained from open-ended questions, because they can be tied to numerical coefficients. Open-ended: The respondent is free to answer the questions as they wish. Useful when the issues are known but the range of user responses to them is not. The responses to open-ended questions may provide more detail and a wider range of responses than those gained from closed-ended questions. However, open-ended questions are more difficult to quantify and summarize as they often include qualitative, rather than quantitative, language. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis Survey/Questionnaire (contd.) Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis RACI Matrix The RACI matrix describes the roles of those involved in business analysis activities. It describes stakeholders as having one or more of the following responsibilities for a given task or deliverable: [R]esponsible▶ does the work, [A]ccountable▶ is the decision maker (only one) [C]onsulted ▶ must be consulted prior to the work and gives input [I]nformed ▶ means that they must be notified of the outcome Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis Stakeholder Map Stakeholder maps are visual diagrams that depict the relationship of stakeholders to the solution and to one another. There are many forms of stakeholder map, but two common ones include: A matrix mapping the level of stakeholder influence against the level of stakeholder interest 2. An onion diagram indicating how involved the stakeholder is with the solution (which stakeholders will directly interact with the solution or participate in a business process, which are part of the larger organization, and which are outside the organization) Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis Stakeholder Map Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis Stakeholder Map Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis Stakeholder Map The first step in building any stakeholder map is to develop a categorized list of the members of the stakeholder community. Once the list is reasonably complete it is then possible to assign priorities in some way, and then to translate the ‘highest priority’ stakeholders into a table or a picture. The potential list of stakeholders for any project will always exceed both the time available for analysis and the capability of the mapping tool to sensibly display the results, the challenge is to focus on the ‘right stakeholders’ who are currently important and to use the tool to visualize this critical sub-set of the total community. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis Stakeholder Map Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis Stakeholder Map J.A.D SESSIONS : J.A.D SESSIONS AN INTRODUCTION J.A.D SESSIONS : J.A.D SESSIONS J.A.D SESSIONS : J.A.D SESSIONS PROPERTIES OF A J.A.D MEETING Every JAD session has a sponsor 2. Every meeting participant other than the sponsor is invited to play a role in the sponsor’s project vision JAD sessions have a well defined agenda 4. The Business Analyst is responsible for Facilitating, Moderating and recording the meeting J.A.D SESSIONS : J.A.D SESSIONS Typical Makeup of a JAD Session J.A.D SESSIONS : J.A.D SESSIONS Typical Flow of a JAD Session J.A.D SESSIONS : J.A.D SESSIONS Tips for conducting a successful JAD Session Lay out the ground rules that everyone will listen and respect each other's position, even if they might disagree on fundamentals. Stay on time. Schedule the meeting with realistic time frames and respect everyone's position and time within the company. End on time, not a minute later. Designate one area of the room as the parking lot for ideas or comments that were brought up that are on a tangent with the problem at hand. You will come back to the lot either later if there is time or will call another meeting with only those involved at a later date to discuss the parking lot items. Do not let office politics play a part in this meeting. Everyone is on a level playing field in here. Control the conversation and don't let a single person dominate discussion. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities Purpose Determine the activities that must be performed and the deliverables that must be produced, estimate the effort required to perform that work, and identify the management tools required to measure the progress of those activities and deliverables. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities Key Points Identify business analysis deliverables Determine the scope of work for the business analysis activities Determine which activities the business analyst will perform and when Develop estimates for business analysis work. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities INPUTS Business Analysis Approach: Defines the lifecycle, deliverables, templates, and tasks that should be included. Plan-driven approaches seek to define requirements as early as possible to reduce uncertainty, while change-driven approaches encourage requirements to be defined as close to implementation as possible. These differences will lead to different deliverables and tasks being identified as well as different sequences and dependencies of tasks. The approach will also determine how the planning process is performed. Business Analysis Performance Assessment: The business analyst must use prior experiences on this initiative or on others to determine the effort involved in performing business analysis work. Organizational Process Assets: The organizational standards and process assets in place may mandate certain deliverables. Lessons learned from previous initiatives, as well as from currently ongoing business analysis activities, may be used in the development of business analysis plans. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities TECHNIQUES Estimation Functional Decomposition Risk Analysis Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities Estimation Estimating techniques forecast the cost and effort involved in pursuing a course of action. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities Estimation Estimating techniques forecast the cost and effort involved in pursuing a course of action. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities Estimation (contd.) Types of Estimation Techniques Analogous Estimation Use of a similar project as the basis for developing estimates for the current project. It is used when little is known. Analogous estimating is often used to develop a rough order of magnitude (ROM) estimate, and is also known as “top-down” estimating. This is usually done at the beginning of the project or project phase and more detailed estimates follow as more is known. Parametric Estimation The use of parameters, multiplied by the number of hours. For parametric estimating to be usable, enough history has to be available to be used as a basis of comparison. With this type of estimating, the business analyst has done enough work to determine which parameters can be used and how many there will be. For example, the business analyst has determined that there will be ten use cases developed. The business analyst also has history that indicates for each use case the total hours that will be spent, in this case will be 20 hours. Using this technique, the business analyst can multiply 10 x 20 to get a total, or 200 hours. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities Estimation (contd.) Types of Estimation Techniques (contd.) Bottom-up Estimation Using this technique the business analyst has collected the deliverables, activities, tasks, and estimates from all the involved stakeholders and rolls them up to get a total for all the activities and tasks. Because it is normally easier to estimate smaller items than larger items, bottom-up estimating can produce the most accurate and defensible estimates. Rolling Wave This is a technique involving refinement of estimates. Estimate the details for activities in the current iteration or increment and provide an analogous estimate for the entire scope of work. As the end of the iteration approaches, estimates for the next iteration can be made and the initial estimate for all activities is refined. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities Estimation (contd.) Types of Estimation Techniques (contd.) Three-point Estimation Uses scenarios for: The most optimistic estimate, or best-case scenario The most pessimistic estimate, or worst-case scenario The most likely estimate Historic Analysis Uses history as a basis for estimating. It is similar to analogous estimation, but is used not only for the top-down estimate, but for the detailed tasks as well. Historic estimates require prior project records, whether maintained formally in a project repository or informally in individual project documentation. Expert Judgment Estimating relies on the expertise of those who have performed the work in the past. These experts can be internal or external to the project team or to the organization. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities Estimation (contd.) Types of Estimation Techniques (contd.) Delphi Estimation This technique uses a combination of expert judgment and history. There are several variations on this process, but they all include individual estimates, sharing the estimates with experts, and having several rounds until consensus is reached. An average of the three estimates is used. Sometimes the average is weighted by taking the optimistic, pessimistic and four times the most likely, dividing by six to get the average. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities Functional Decomposition Functional decomposition involves breaking down a large problem into smaller functions or deliverables. The primary goal of functional decomposition is to ensure that the problem is separated into sub-problems that are as independent as possible, so that work can be assigned to different groups. This provides the ability to scale and manage larger projects. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Communication Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Communication Purpose A business analysis communications plan describes the proposed structure and schedule for communications regarding business analysis activities. Record and organize the activities to provide a basis for setting expectations for business analysis work, meetings, walkthroughs, and other communications. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Communication Key Points Requirements can be presented in various formats. This task describes the work required to decide which format(s) are appropriate for a particular initiative and its stakeholders. Considerations for the business analysis communications plan include: ▶ what needs to be communicated; ▶ what is the appropriate delivery method; ▶ who is the appropriate audience; ▶ and when the communication should occur (Project Phase, Geography, Time zone) Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Communication INPUTS Business Analysis Approach: May include standards and templates used for communication, and expectations regarding when and how communication should occur. Business Analysis Plan(s): Determines when work will be performed and the deliverables that will be produced, and which need to be communicated. Organizational Process Assets: May include a defined set of templates for use in business analysis communication, including presentation formats, requirements documentation templates, and others. Stakeholder List, Roles, and Responsibilities: Used to identify the stakeholders who will require information regarding business analysis work, determine when information needs to be provided, and how a stakeholder is expected to use that information. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Communication TECHNIQUES Structured Walkthrough Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Requirements Management Process Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Requirements Management Process Purpose Define the process that will be used to approve requirements for implementation and manage changes to the solution or requirements scope. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Requirements Management Process Key Points A requirements repository is a method of storing requirements, including those under development, those under review, and approved requirements. The system for adding, changing and deleting requirements should be consistent and clearly understood by the team. File or component naming standards will assist with categorizing and maintaining requirements. Requirements should be traceable. Tracing requirements adds considerable overhead to business analysis work and must be done correctly and consistently to have value. Requirements attributes provide information about requirements, such as the source of the requirement, the importance of the requirement, and other metadata. Attributes aid in the ongoing management of the requirements throughout the project lifecycle. They need to be planned for and determined, along with the requirement themselves, but are not in themselves part of the solution definition. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Requirements Management Process Key Points (contd.) Requirements do not all deliver the same value to stakeholders. Requirements prioritization focuses effort on determining which requirements should be investigated first, based on the risk associated with them, the cost to deliver them, the benefits they will produce, or other factors. Timelines, dependencies, resource constraints, and other factors influence how requirements are prioritized. Planning the requirement prioritization process helps ensure that stakeholders determine and understand how requirements will be prioritized throughout and at the end of the business analysis effort. Depending on the organization / project / specific scenario, a Change management process may or may not be in place. The business analyst should at all times be aware of the impact that changing requirements can have on a project. REQUIREMENTS MANAGEMENT : REQUIREMENTS MANAGEMENT AN INTRODUCTION REQUIREMENTS : REQUIREMENTS What is a Requirement? -> What a system must do, referred to as a Functional Requirement -> how a system is supposed to be, referred to as a Non-Functional Requirement -> Constraints REQUIREMENTS : REQUIREMENTS Requirements Tree Traceability Tree REQUIREMENTS : REQUIREMENTS Use Case Model Use Case Specification Activity Diagram Sequence Diagrams REQUIREMENTS : REQUIREMENTS What makes a Good Requirement? Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Requirements Management Process INPUTS Business Analysis Approach: Defines the lifecycle, deliverables, templates, and tasks that should be included. Plan-driven approaches seek to define requirements as early as possible to reduce uncertainty, while change-driven approaches encourage requirements to be defined as close to implementation as possible. These differences will lead to different deliverables and tasks being identified as well as different sequences and dependencies of tasks. The approach will also determine how the planning process is performed. Business Analysis Plan(s): The business analysis plan(s) define which deliverables are to be produced and when. Deliverables cannot be managed until they are created. Organizational Process Assets: The organizational standards and process assets in place may mandate certain deliverables. Lessons learned from previous initiatives, as well as from currently ongoing business analysis activities, may be used in the development of business analysis plans. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Requirements Management Process TECHNIQUES Decision Analysis Problem Tracking Risk Analysis Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Requirements Management Process Problem Tracking Problem tracking provides an organized approach to tracking, management, and resolution of defects, issues, problems, and risks throughout business analysis activities. Management of issues is important so that they can be resolved in a timely manner to ensure success. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Requirements Management Process Problem Tracking (contd.) Problems may include issues, questions, risks, defects, conflicts, or other concerns that need to be tracked to resolution. A problem tracking system ensures that issues are not simply neglected or lost. For each problem, the tracking tool may include an identification of the problem, status updates, assigning of related actions that are required to team members and tracking expected resolution dates, resolution results, actions and decisions taken, priority, and impacts. The current status of problems should be communicated to all relevant stakeholders. Ensure problem tracking leads to: ▶ Resolution of problems in a timely manner that eliminate or minimize negative impacts. ▶ Allocation of resources to resolve problems. ▶ Identification of root causes of problems. Requisite Pro : Requisite Pro Next: Conducting Stakeholder Analysis : Next: Conducting Stakeholder Analysis Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Manage Business Analysis Performance Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Manage Business Analysis Performance Purpose To manage the performance of business analysis activities to ensure that they are executed as effectively as possible. This task covers determining which metrics will be used to measure the work performed by the business analyst. It includes how to track, assess, and report on the quality of the work and take steps to correct any problems that may arise. This may feed into the development of future business analysis plans. The selected metrics are defined and described in the organizational process assets or the business analysis plans. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Manage Business Analysis Performance Key Points Performance measures are used to set expectations regarding what constitutes effective business analysis work in the context of a particular organization or initiative. Performance measures may be based on deliverable due dates as specified in the business analysis plan, metrics such as the frequency of changes to requirements or the number of review cycles required, or qualitative feedback from stakeholders and peers of the business analyst. Reports can be in written format to provide for archival and tracking, or they can be informal and verbal, based on the needs of the project. The business analyst should assess the performance measures to determine where problems in executing business analysis activities are occurring or opportunities for improving the business analysis process exist. Once this assessment is complete the business analyst should engage the necessary stakeholders to identify the correct preventative or corrective actions. Preventative or corrective action is likely to result in changes to the business analysis plan. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Manage Business Analysis Performance INPUTS Business Analysis Performance Metrics: Actual performance measures are captured, analyzed, and become 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 Analysis Plan(s): These plans describe deliverables, activities, tasks, and estimates for all business analysis work. Conformance to these plans may be the primary metric used to judge performance. Organizational Performance Standards: May include mandated performance metrics or expectations for business analysis work. Requirements Management Plan: The requirements management plan may also set expectations for the frequency of changes to requirements and the work involved in managing that change. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Manage Business Analysis Performance TECHNIQUES Interviews Lessons Learned Process Metrics and Key Performance Indicators Problem Tracking Process Modeling Root Cause Analysis Survey/Questionnaire Variance Analysis Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities Lessons Learned Process The purpose of the lessons learned process is to compile and document successes, opportunities for improvement, failures, and recommendations for improving the performance of future projects or project phases. Lessons learned sessions can include any format or venue that works for the key stakeholders identified as participants in these sessions. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities Metrics and Key Performance Indicators A metric is a quantifiable level of an indicator that an organization uses to measure progress. An indicator identifies a specific numerical measurement that represents the degree of progress toward achieving a goal, objective, output, activity or further input. A Key Performance Indicator is one that measures progress towards a strategic goal or objective. Reporting is the process of informing stakeholders of metrics of indicators in specified formats at specified intervals. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities Root Cause Analysis Root cause analysis is a structured examination of the aspects of a situation to establish the root causes and resulting effects of the problem. A critical element of root cause analysis is to ensure that the current business thinking and processes are challenged. That is, do they still make sense or provide good business value in light of current realities? Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities Root Cause Analysis (Contd.) A fishbone diagram (also known as an Ishikawa or cause-and-effect diagram) is used to identify and organize the possible causes of a problem. This tool helps to focus on the cause of the problem versus the solution and organizes ideas for further analysis. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities Root Cause Analysis (Contd.) Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities Root Cause Analysis (Contd.) The Five Whys is a question-asking process to explore the nature and cause of a problem. The Five Whys approach repeatedly asks questions in an attempt to get to the root cause of the problem. This is one of the simplest facilitation tools to use when problems have a human interaction component. To use this technique: ▶Write the problem on a flip chart of white board. ▶Ask: “Why do you think this problem occurs?” and capture the idea below the problem ▶Ask: “Why?” again and capture that idea below the first idea Continue with step 3 until you are convinced the actual root cause has been identified. This may take more or less than five questions—the technique is called the five whys because it often takes that many to reach the root cause, not because the question must be asked five times. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities Root Cause Analysis (Contd.) Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities Root Cause Analysis (Contd.) END OF SECTION : END OF SECTION Q&A : Q&A You do not have the permission to view this presentation. In order to view it, please contact the author of the presentation.
introduction to babok- business analysis, planning & monitoring mcomtraining Download Post to : URL : Related Presentations : Share Add to Flag Embed Email Send to Blogs and Networks Add to Channel Uploaded from authorPOINT lite Insert YouTube videos in PowerPont slides with aS Desktop Copy embed code: (To copy code, click on the text box) Embed: URL: Thumbnail: WordPress Embed Customize Embed The presentation is successfully added In Your Favorites. Views: 349 Category: Education License: All Rights Reserved Like it (0) Dislike it (0) Added: September 24, 2010 This Presentation is Public Favorites: 1 Presentation Description No description available. Comments Posting comment... Premium member Presentation Transcript Introduction to BABOKTM : Introduction to BABOKTM IT BUSINESS ANALYSIS LECTURE 2 Business Analysis Planning & Monitoring Slide 2: A Guide to the Business Analysis Body of Knowledge (BABOK) is the written guide to the collection of business analysis knowledge reflecting current best practice, providing a framework that describes the areas of knowledge, with associated activities and tasks and skills required The business analysis body of knowledge defines 6 knowledge areas, which group together related sets of tasks and techniques. Each of these tasks and techniques describes the typical knowledge, skills, processes, and deliverables that the business analyst requires to be able to perform those tasks competently. While a flow of tasks and processes is suggested by these knowledge areas, the BABOK is deliberately not setting out a prescribed methodology. IT BUSINESS ANALYST : IT BUSINESS ANALYST IT BUSINESS ANALYST : IT BUSINESS ANALYST IT BUSINESS ANALYST : IT BUSINESS ANALYST Domains A domain is the area undergoing analysis. It may correspond to the boundaries of an organization or organizational unit, as well as key stakeholders outside those boundaries and interactions with those stakeholders. Solutions A solution is a set of changes to the current state of an organization that are made in order to enable that organization to meet a business need, solve a problem, or take advantage of an opportunity. The scope of the solution is usually narrower than the scope of the domain within which it is implemented Requirements A requirement1 is: A condition or capability needed by a stakeholder to solve a problem or achieve an objective. A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents. A documented representation of a condition or capability as in (1) or (2). IT BUSINESS ANALYST : IT BUSINESS ANALYST Tasks Each knowledge area describes the tasks performed by business analysts to accomplish the purpose of that knowledge area. Techniques Each task contains a listing of relevant techniques. Some techniques are specific to the performance of a single task, while others are relevant to the performance of a large number of tasks IT BUSINESS ANALYST : IT BUSINESS ANALYST Input An input represents the information and preconditions necessary for a task to begin. Inputs may be: Explicitly generated outside the scope of business analysis (e.g., construction of a software application). Generated by a business analysis task. IT BUSINESS ANALYST : IT BUSINESS ANALYST Output An output is a necessary result of the work described in the task. Outputs are created, transformed or change state as a result of the successful completion of a task. Although a particular output is created and maintained by a single task, a task can have multiple outputs. An output may be a deliverable or be a part of a larger deliverable. The form of an output is dependent on the type of initiative underway, standards adopted by the organization, and best judgment of the business analyst as to an appropriate way to address the information needs of key stakeholders. IT BUSINESS ANALYST : IT BUSINESS ANALYST Stakeholders Each task includes a listing of generic stakeholders who are likely to participate in the execution of that task or who will be affected by it. A generic stakeholder represents a class of people that the business analyst is likely to interact with in a specific way. IT BUSINESS ANALYST : IT BUSINESS ANALYST Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring AN INTRODUCTION Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring The Business Analysis Planning and Monitoring Knowledge Area defines the tasks associated with the planning and monitoring of business analysis activities Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Approach Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Approach Purpose This task describes how to select an approach to performing business analysis, which stakeholders need to be involved in the decision, who will be consulted regarding and informed of the approach, how and when tasks will be performed, the techniques that will be used, and the deliverables that should be produced. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Approach Key Points There are multiple established ways to approach business analysis / business process improvement work (waterfall approach, RUP, agile techniques, Lean, Six Sigma, as well as many proprietary and in-house methodologies, customs, and practices.) Elements from different approaches may be combined; however only a subset of all possible combinations will be viable for the particular organizational environment in which an initiative is being performed. In order to plan the business analysis approach, the business analyst must understand the organizational process needs and objectives that apply to the initiative. The business analysis approach is often based on or related to the project approach, but in some cases they may be independently determined (for example, an organization may use a plan-driven approach to define its business processes and then use a change-driven approach to build the supporting software applications). Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Approach INPUTS Business Need: The business analysis approach will be shaped by the problem or opportunity faced by the organization. It is generally necessary to consider the risks associated with it, the timeframe in which the need must be addressed, and how well the need is understood. This will help determine whether a plan-driven or change-driven approach is appropriate. Expert Judgment: Used to determine the optimal business analysis approach. Expertise may be provided from a wide range of sources including stakeholders in the initiative, organizational Centers of Competency, consultants, or associations and industry groups. Organizational Process Assets: Include the elements of existing business analysis approaches in use by the organization. Organizational process assets that may be useful in defining the business analysis approach include methodologies for process change or software development, tools or techniques that are in use or understood by stakeholders, corporate governance standards and templates for deliverables. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Almost all Business Analysis methodologies fit somewhere along a spectrum between plan-driven and change-driven approaches. Plan-driven approaches focus on minimizing up-front uncertainty and ensuring that the solution is fully defined before implementation begins in order to maximize control and minimize risk. Change-driven 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. The performance of this task is dependent on where the selected approach falls on this spectrum. Plan Business Analysis Approach Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Approach Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Approach TECHNIQUES Decision Analysis : May be used to rate available methodologies against the organizational needs and objectives. Process Modeling : Process Models can be used to define and document the business analysis approach. Structured Walkthrough: This can be used as a means of validating a created, selected, or tailored business analysis approach. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Approach Decision Analysis Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Approach Decision Analysis Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Approach PROCESS MODELLING Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Approach PROCESS MODELLING Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Approach PROCESS MODELLING Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Approach PROCESS MODELLING Without a Unified Notation, there is Chaos Unified Modelling Language Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Approach PROCESS MODELLING Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Approach PROCESS MODELLING INTRO TO UML : INTRO TO UML Activity Diagrams INTRO TO UML : INTRO TO UML Activity Diagrams INTRO TO UML : INTRO TO UML Activity Diagrams INTRO TO UML : INTRO TO UML Activity Diagrams ACTIVITY INITIAL STATE END STATE FLOW DECISION SWIMLANE TRANSITION Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Approach Structured Walkthrough Structured walkthroughs are working sessions that are performed to communicate, verify and validate requirements. Invited participants review and discuss a set of requirements. Participants are required to ask questions, and make comments and suggestions. Other issues may also be identified during the session. All questions, comments, concerns, and suggestions are recorded. A walkthrough may result in revised requirements as well as issues that require investigation. A walkthrough may also be referred to as a requirements review. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Approach Structured Walkthrough Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Approach Structured Walkthrough Rational Unified Process : Rational Unified Process RUP : RUP Where YOU go Tomorrow Depends on Where do YOU want to go Today - Bill Gates of Microsoft RUP : RUP Where YOU are Today Is all because of Where YOU didn’t go yesterday - Murphy of Murphy’s Law RUP : RUP Waterfall Model RUP : RUP System Development Life Cycle - SDLC RUP : RUP Iterative Development Model RUP : RUP Iterative Development Model RUP : RUP Iterative Development Model Iteration #1 Iteration #1 Iteration #3 Iteration #2 RUP : RUP RUP : RUP RUP : RUP What are the two approaches in Business Analysis Planning? RUP : RUP RUP is a method of managing OO Software Development It can be viewed as a Software Development Framework which is extensible and features: Iterative Development Requirements Management Component-Based Architectural Vision Visual Modeling of Systems Quality Management Change Control Management RUP : RUP Online Repository of Process Information and Description in HTML format Templates for all major artifacts, including: RequisitePro templates (requirements tracking) Word Templates for Use Cases Project Templates for Project Management Process Manuals describing key processes Process Structure : Process Structure Two dimensions. Horizontal axis represents time and shows the lifecycle aspects of the process as it unfolds. Vertical axis represents core process workflows, which group activities logically by nature. Phases : Phases Inception Elaboration Construction Transition Two dimensions of RUP : Two dimensions of RUP RUP : RUP RATIONAL UNIFIED PROCESS Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis Purpose This task covers the identification of stakeholders who may be affected by a proposed initiative or who share a common business need, identifying appropriate stakeholders for the project or project phase, and determining stakeholder influence and/or authority regarding the approval of project deliverables. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis Key Points Stakeholder analysis is performed as soon as a business need is identified Is usually an ongoing activity as long as business analysis continues. Stakeholder analysis begins with identifying stakeholders who may be affected by the business need or a new solution. Stakeholders may be grouped into categories that reflect their involvement or interest in the initiative. The roles, responsibilities, and authority over the requirements for each stakeholder or stakeholder group must be clearly described. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis Key Points (continued) Stakeholder analysis also involves understanding stakeholder influence on and attitude towards the initiative, and assessing positive and negative attitudes and behaviors which may affect the outcome of the initiative and acceptance of the solution Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis INPUTS Business Need: The business analysis approach will be shaped by the problem or opportunity faced by the organization. It is generally necessary to consider the risks associated with it, the timeframe in which the need must be addressed, and how well the need is understood. This will help determine whether a plan-driven or change-driven approach is appropriate. Enterprise Architecture: Describes the organizational units that exist, their interactions with other organizational units, customers, and suppliers, their responsibilities within the organization, and the roles and relationships within each organizational unit. Organizational Process Assets: Include the elements of existing business analysis approaches in use by the organization. Organizational process assets that may be useful in defining the business analysis approach include methodologies for process change or software development, tools or techniques that are in use or understood by stakeholders, corporate governance standards and templates for deliverables. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis TECHNIQUES Acceptance and Evaluation Criteria Definition Brainstorming Interviews Organization Modeling Process Modeling Requirements Workshops Risk Analysis Scenarios and Use Cases Scope Modeling Survey/Questionnaire RACI Matrix Stakeholder Map Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis Acceptance and Evaluation Criteria Definition MoSCoW is a prioritization technique used in business analysis and software development to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement - also known as MoSCoW prioritization or MoSCoW analysis. The capital letters in MoSCoW stand for: M - MUST have this. S - SHOULD have this if at all possible. C - COULD have this if it does not affect anything else. W - WON'T have this time but WOULD like in the future. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis Organization Modeling Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis Risk Analysis Risk analysis can help identify and manage areas of uncertainty that can impact an initiative, solution, or organization ELEMENTS OF RISK Risk Tolerance A key factor in determining the response that a person or organization will select in regards to a risk is to understand their tolerance for risk. There is no correct or ideal response—a general strategy must be adapted to each particular circumstance. The three general categories of risk tolerance are: Risk-Aversion Neutrality Risk-Seeking An individual or organization may exhibit different risk tolerances at different times. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis Risk Analysis ELEMENTS OF RISK (CONTD.) Assessment Assessment involves determining the probability that the risk will occur and the impact if it does occur. Each of these factors is assessed on a common scale (High, Medium and Low, a number from 1–5, and so forth). This enables analysis to focus on the most important risks. Response Response strategies determine how the organization will deal with a risk. For negative risks, strategies include: Acceptance Transfer Avoidance Mitigation For positive risks, acceptance is also a viable strategy. Other strategies include: Share Enhance Exploit Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis Scenarios and Use Cases Scenarios and use cases are written to describe how an actor interacts with a solution to accomplish one or more of that actor’s goals, or to respond to an event. While the terms scenario and use case are often used loosely, a scenario is generally understood to describe just one way that an actor can accomplish a particular goal, while a use case describes all the possible outcomes of an attempt to accomplish a particular goal that the solution will support. Scenarios are written as a series of steps performed by actors or by the solution that enable an actor to achieve a goal. A use case describes several scenarios in the form of primary and alternate flows. The primary or basic flow represents the simplest way to accomplish the goal of the use case. Special circumstances and exceptions that result in a failure to complete the goal of the use case are documented in alternate flows. INTRO TO USE CASES : INTRO TO USE CASES USE CASE Use cases describe the system from the user's point of view. Use cases describe the interaction between a primary actor (the initiator of the interaction) and the system itself, represented as a sequence of simple steps. Actors are something or someone which exists outside the system under study, and that take part in a sequence of activities in a dialogue with the system to achieve some goal. Actors may be end users, other systems, or hardware devices. Each use case is a complete series of events, described from the point of view of the actor. INTRO TO USE CASES : INTRO TO USE CASES Use case Diagrams INTRO TO UML : INTRO TO UML Use case Diagrams INTRO TO UML : INTRO TO UML Use case Diagrams ACTOR USE CASE Generalization DEPENDENCY Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Approach Scope Modeling Scope models are used to describe the scope of analysis or the scope of a solution There are many different standards for scope modeling. In general, the scope model selected will depend on the analysis techniques selected to further explore the scope. Examples Context Diagrams Use Case Diagrams Business Process Rational Rose : Rational Rose Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis Survey/Questionnaire A survey is a means of eliciting information from many people, sometimes anonymously, in a relatively short period of time. A survey can collect information about customers, products, work practices and attitudes. A survey may also be referred to as a questionnaire. Questions in a survey are of two types: Closed: The respondent is asked to select from available responses. This is useful when the range of user’s responses is fairly well understood, but the strength of each response category needs to be determined. The responses to closed questions are easier to analyze than those gained from open-ended questions, because they can be tied to numerical coefficients. Open-ended: The respondent is free to answer the questions as they wish. Useful when the issues are known but the range of user responses to them is not. The responses to open-ended questions may provide more detail and a wider range of responses than those gained from closed-ended questions. However, open-ended questions are more difficult to quantify and summarize as they often include qualitative, rather than quantitative, language. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis Survey/Questionnaire (contd.) Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis RACI Matrix The RACI matrix describes the roles of those involved in business analysis activities. It describes stakeholders as having one or more of the following responsibilities for a given task or deliverable: [R]esponsible▶ does the work, [A]ccountable▶ is the decision maker (only one) [C]onsulted ▶ must be consulted prior to the work and gives input [I]nformed ▶ means that they must be notified of the outcome Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis Stakeholder Map Stakeholder maps are visual diagrams that depict the relationship of stakeholders to the solution and to one another. There are many forms of stakeholder map, but two common ones include: A matrix mapping the level of stakeholder influence against the level of stakeholder interest 2. An onion diagram indicating how involved the stakeholder is with the solution (which stakeholders will directly interact with the solution or participate in a business process, which are part of the larger organization, and which are outside the organization) Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis Stakeholder Map Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis Stakeholder Map Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis Stakeholder Map The first step in building any stakeholder map is to develop a categorized list of the members of the stakeholder community. Once the list is reasonably complete it is then possible to assign priorities in some way, and then to translate the ‘highest priority’ stakeholders into a table or a picture. The potential list of stakeholders for any project will always exceed both the time available for analysis and the capability of the mapping tool to sensibly display the results, the challenge is to focus on the ‘right stakeholders’ who are currently important and to use the tool to visualize this critical sub-set of the total community. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis Stakeholder Map Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Conduct Stakeholder Analysis Stakeholder Map J.A.D SESSIONS : J.A.D SESSIONS AN INTRODUCTION J.A.D SESSIONS : J.A.D SESSIONS J.A.D SESSIONS : J.A.D SESSIONS PROPERTIES OF A J.A.D MEETING Every JAD session has a sponsor 2. Every meeting participant other than the sponsor is invited to play a role in the sponsor’s project vision JAD sessions have a well defined agenda 4. The Business Analyst is responsible for Facilitating, Moderating and recording the meeting J.A.D SESSIONS : J.A.D SESSIONS Typical Makeup of a JAD Session J.A.D SESSIONS : J.A.D SESSIONS Typical Flow of a JAD Session J.A.D SESSIONS : J.A.D SESSIONS Tips for conducting a successful JAD Session Lay out the ground rules that everyone will listen and respect each other's position, even if they might disagree on fundamentals. Stay on time. Schedule the meeting with realistic time frames and respect everyone's position and time within the company. End on time, not a minute later. Designate one area of the room as the parking lot for ideas or comments that were brought up that are on a tangent with the problem at hand. You will come back to the lot either later if there is time or will call another meeting with only those involved at a later date to discuss the parking lot items. Do not let office politics play a part in this meeting. Everyone is on a level playing field in here. Control the conversation and don't let a single person dominate discussion. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities Purpose Determine the activities that must be performed and the deliverables that must be produced, estimate the effort required to perform that work, and identify the management tools required to measure the progress of those activities and deliverables. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities Key Points Identify business analysis deliverables Determine the scope of work for the business analysis activities Determine which activities the business analyst will perform and when Develop estimates for business analysis work. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities INPUTS Business Analysis Approach: Defines the lifecycle, deliverables, templates, and tasks that should be included. Plan-driven approaches seek to define requirements as early as possible to reduce uncertainty, while change-driven approaches encourage requirements to be defined as close to implementation as possible. These differences will lead to different deliverables and tasks being identified as well as different sequences and dependencies of tasks. The approach will also determine how the planning process is performed. Business Analysis Performance Assessment: The business analyst must use prior experiences on this initiative or on others to determine the effort involved in performing business analysis work. Organizational Process Assets: The organizational standards and process assets in place may mandate certain deliverables. Lessons learned from previous initiatives, as well as from currently ongoing business analysis activities, may be used in the development of business analysis plans. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities TECHNIQUES Estimation Functional Decomposition Risk Analysis Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities Estimation Estimating techniques forecast the cost and effort involved in pursuing a course of action. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities Estimation Estimating techniques forecast the cost and effort involved in pursuing a course of action. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities Estimation (contd.) Types of Estimation Techniques Analogous Estimation Use of a similar project as the basis for developing estimates for the current project. It is used when little is known. Analogous estimating is often used to develop a rough order of magnitude (ROM) estimate, and is also known as “top-down” estimating. This is usually done at the beginning of the project or project phase and more detailed estimates follow as more is known. Parametric Estimation The use of parameters, multiplied by the number of hours. For parametric estimating to be usable, enough history has to be available to be used as a basis of comparison. With this type of estimating, the business analyst has done enough work to determine which parameters can be used and how many there will be. For example, the business analyst has determined that there will be ten use cases developed. The business analyst also has history that indicates for each use case the total hours that will be spent, in this case will be 20 hours. Using this technique, the business analyst can multiply 10 x 20 to get a total, or 200 hours. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities Estimation (contd.) Types of Estimation Techniques (contd.) Bottom-up Estimation Using this technique the business analyst has collected the deliverables, activities, tasks, and estimates from all the involved stakeholders and rolls them up to get a total for all the activities and tasks. Because it is normally easier to estimate smaller items than larger items, bottom-up estimating can produce the most accurate and defensible estimates. Rolling Wave This is a technique involving refinement of estimates. Estimate the details for activities in the current iteration or increment and provide an analogous estimate for the entire scope of work. As the end of the iteration approaches, estimates for the next iteration can be made and the initial estimate for all activities is refined. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities Estimation (contd.) Types of Estimation Techniques (contd.) Three-point Estimation Uses scenarios for: The most optimistic estimate, or best-case scenario The most pessimistic estimate, or worst-case scenario The most likely estimate Historic Analysis Uses history as a basis for estimating. It is similar to analogous estimation, but is used not only for the top-down estimate, but for the detailed tasks as well. Historic estimates require prior project records, whether maintained formally in a project repository or informally in individual project documentation. Expert Judgment Estimating relies on the expertise of those who have performed the work in the past. These experts can be internal or external to the project team or to the organization. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities Estimation (contd.) Types of Estimation Techniques (contd.) Delphi Estimation This technique uses a combination of expert judgment and history. There are several variations on this process, but they all include individual estimates, sharing the estimates with experts, and having several rounds until consensus is reached. An average of the three estimates is used. Sometimes the average is weighted by taking the optimistic, pessimistic and four times the most likely, dividing by six to get the average. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities Functional Decomposition Functional decomposition involves breaking down a large problem into smaller functions or deliverables. The primary goal of functional decomposition is to ensure that the problem is separated into sub-problems that are as independent as possible, so that work can be assigned to different groups. This provides the ability to scale and manage larger projects. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Communication Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Communication Purpose A business analysis communications plan describes the proposed structure and schedule for communications regarding business analysis activities. Record and organize the activities to provide a basis for setting expectations for business analysis work, meetings, walkthroughs, and other communications. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Communication Key Points Requirements can be presented in various formats. This task describes the work required to decide which format(s) are appropriate for a particular initiative and its stakeholders. Considerations for the business analysis communications plan include: ▶ what needs to be communicated; ▶ what is the appropriate delivery method; ▶ who is the appropriate audience; ▶ and when the communication should occur (Project Phase, Geography, Time zone) Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Communication INPUTS Business Analysis Approach: May include standards and templates used for communication, and expectations regarding when and how communication should occur. Business Analysis Plan(s): Determines when work will be performed and the deliverables that will be produced, and which need to be communicated. Organizational Process Assets: May include a defined set of templates for use in business analysis communication, including presentation formats, requirements documentation templates, and others. Stakeholder List, Roles, and Responsibilities: Used to identify the stakeholders who will require information regarding business analysis work, determine when information needs to be provided, and how a stakeholder is expected to use that information. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Communication TECHNIQUES Structured Walkthrough Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Requirements Management Process Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Requirements Management Process Purpose Define the process that will be used to approve requirements for implementation and manage changes to the solution or requirements scope. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Requirements Management Process Key Points A requirements repository is a method of storing requirements, including those under development, those under review, and approved requirements. The system for adding, changing and deleting requirements should be consistent and clearly understood by the team. File or component naming standards will assist with categorizing and maintaining requirements. Requirements should be traceable. Tracing requirements adds considerable overhead to business analysis work and must be done correctly and consistently to have value. Requirements attributes provide information about requirements, such as the source of the requirement, the importance of the requirement, and other metadata. Attributes aid in the ongoing management of the requirements throughout the project lifecycle. They need to be planned for and determined, along with the requirement themselves, but are not in themselves part of the solution definition. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Requirements Management Process Key Points (contd.) Requirements do not all deliver the same value to stakeholders. Requirements prioritization focuses effort on determining which requirements should be investigated first, based on the risk associated with them, the cost to deliver them, the benefits they will produce, or other factors. Timelines, dependencies, resource constraints, and other factors influence how requirements are prioritized. Planning the requirement prioritization process helps ensure that stakeholders determine and understand how requirements will be prioritized throughout and at the end of the business analysis effort. Depending on the organization / project / specific scenario, a Change management process may or may not be in place. The business analyst should at all times be aware of the impact that changing requirements can have on a project. REQUIREMENTS MANAGEMENT : REQUIREMENTS MANAGEMENT AN INTRODUCTION REQUIREMENTS : REQUIREMENTS What is a Requirement? -> What a system must do, referred to as a Functional Requirement -> how a system is supposed to be, referred to as a Non-Functional Requirement -> Constraints REQUIREMENTS : REQUIREMENTS Requirements Tree Traceability Tree REQUIREMENTS : REQUIREMENTS Use Case Model Use Case Specification Activity Diagram Sequence Diagrams REQUIREMENTS : REQUIREMENTS What makes a Good Requirement? Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Requirements Management Process INPUTS Business Analysis Approach: Defines the lifecycle, deliverables, templates, and tasks that should be included. Plan-driven approaches seek to define requirements as early as possible to reduce uncertainty, while change-driven approaches encourage requirements to be defined as close to implementation as possible. These differences will lead to different deliverables and tasks being identified as well as different sequences and dependencies of tasks. The approach will also determine how the planning process is performed. Business Analysis Plan(s): The business analysis plan(s) define which deliverables are to be produced and when. Deliverables cannot be managed until they are created. Organizational Process Assets: The organizational standards and process assets in place may mandate certain deliverables. Lessons learned from previous initiatives, as well as from currently ongoing business analysis activities, may be used in the development of business analysis plans. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Requirements Management Process TECHNIQUES Decision Analysis Problem Tracking Risk Analysis Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Requirements Management Process Problem Tracking Problem tracking provides an organized approach to tracking, management, and resolution of defects, issues, problems, and risks throughout business analysis activities. Management of issues is important so that they can be resolved in a timely manner to ensure success. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Requirements Management Process Problem Tracking (contd.) Problems may include issues, questions, risks, defects, conflicts, or other concerns that need to be tracked to resolution. A problem tracking system ensures that issues are not simply neglected or lost. For each problem, the tracking tool may include an identification of the problem, status updates, assigning of related actions that are required to team members and tracking expected resolution dates, resolution results, actions and decisions taken, priority, and impacts. The current status of problems should be communicated to all relevant stakeholders. Ensure problem tracking leads to: ▶ Resolution of problems in a timely manner that eliminate or minimize negative impacts. ▶ Allocation of resources to resolve problems. ▶ Identification of root causes of problems. Requisite Pro : Requisite Pro Next: Conducting Stakeholder Analysis : Next: Conducting Stakeholder Analysis Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Manage Business Analysis Performance Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Manage Business Analysis Performance Purpose To manage the performance of business analysis activities to ensure that they are executed as effectively as possible. This task covers determining which metrics will be used to measure the work performed by the business analyst. It includes how to track, assess, and report on the quality of the work and take steps to correct any problems that may arise. This may feed into the development of future business analysis plans. The selected metrics are defined and described in the organizational process assets or the business analysis plans. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Manage Business Analysis Performance Key Points Performance measures are used to set expectations regarding what constitutes effective business analysis work in the context of a particular organization or initiative. Performance measures may be based on deliverable due dates as specified in the business analysis plan, metrics such as the frequency of changes to requirements or the number of review cycles required, or qualitative feedback from stakeholders and peers of the business analyst. Reports can be in written format to provide for archival and tracking, or they can be informal and verbal, based on the needs of the project. The business analyst should assess the performance measures to determine where problems in executing business analysis activities are occurring or opportunities for improving the business analysis process exist. Once this assessment is complete the business analyst should engage the necessary stakeholders to identify the correct preventative or corrective actions. Preventative or corrective action is likely to result in changes to the business analysis plan. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Manage Business Analysis Performance INPUTS Business Analysis Performance Metrics: Actual performance measures are captured, analyzed, and become 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 Analysis Plan(s): These plans describe deliverables, activities, tasks, and estimates for all business analysis work. Conformance to these plans may be the primary metric used to judge performance. Organizational Performance Standards: May include mandated performance metrics or expectations for business analysis work. Requirements Management Plan: The requirements management plan may also set expectations for the frequency of changes to requirements and the work involved in managing that change. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Manage Business Analysis Performance TECHNIQUES Interviews Lessons Learned Process Metrics and Key Performance Indicators Problem Tracking Process Modeling Root Cause Analysis Survey/Questionnaire Variance Analysis Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities Lessons Learned Process The purpose of the lessons learned process is to compile and document successes, opportunities for improvement, failures, and recommendations for improving the performance of future projects or project phases. Lessons learned sessions can include any format or venue that works for the key stakeholders identified as participants in these sessions. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities Metrics and Key Performance Indicators A metric is a quantifiable level of an indicator that an organization uses to measure progress. An indicator identifies a specific numerical measurement that represents the degree of progress toward achieving a goal, objective, output, activity or further input. A Key Performance Indicator is one that measures progress towards a strategic goal or objective. Reporting is the process of informing stakeholders of metrics of indicators in specified formats at specified intervals. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities Root Cause Analysis Root cause analysis is a structured examination of the aspects of a situation to establish the root causes and resulting effects of the problem. A critical element of root cause analysis is to ensure that the current business thinking and processes are challenged. That is, do they still make sense or provide good business value in light of current realities? Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities Root Cause Analysis (Contd.) A fishbone diagram (also known as an Ishikawa or cause-and-effect diagram) is used to identify and organize the possible causes of a problem. This tool helps to focus on the cause of the problem versus the solution and organizes ideas for further analysis. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities Root Cause Analysis (Contd.) Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities Root Cause Analysis (Contd.) The Five Whys is a question-asking process to explore the nature and cause of a problem. The Five Whys approach repeatedly asks questions in an attempt to get to the root cause of the problem. This is one of the simplest facilitation tools to use when problems have a human interaction component. To use this technique: ▶Write the problem on a flip chart of white board. ▶Ask: “Why do you think this problem occurs?” and capture the idea below the problem ▶Ask: “Why?” again and capture that idea below the first idea Continue with step 3 until you are convinced the actual root cause has been identified. This may take more or less than five questions—the technique is called the five whys because it often takes that many to reach the root cause, not because the question must be asked five times. Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities Root Cause Analysis (Contd.) Business Analysis Planning & Monitoring : Business Analysis Planning & Monitoring Plan Business Analysis Activities Root Cause Analysis (Contd.) END OF SECTION : END OF SECTION Q&A : Q&A