BABoK V2 Business Analysis Planning and Monitoring (BAPM)

1,776 views

Published on

An overview of Business Analysis Planning and Monitoring (BAPM) Knowledge Areas from IIBA BABoK version 2.

Published in: Business, Technology

BABoK V2 Business Analysis Planning and Monitoring (BAPM)

  1. 1. A Guide to the Business Analysis Body of Knowledge (BABoK®) – Knowledge Area Business Analysis Planning & Monitoring By – Amjad Shaikh
  2. 2. What is Business Analysis Planning & Monitoring all about?
  3. 3. “The Business Analysis Planning & Monitoring (BAP&M) knowledge area describes the tasks, activities and techniques that are required for successful definition and planning of business analysis project phase to achieve controlled start”
  4. 4. “By failing to prepare, you are preparing to fail.” ― Benjamin Franklin
  5. 5. Enterprise Analysis Business Analysis Planning & Monitoring Requirements Elicitation Requirements Analysis Solution Assessment & Validation Underlying Competency Requirements Management & Communication Techniques Concepts (BABoK) BABoK®Version2Release2009
  6. 6.  Defining and determining business analysis processes  Identifying stakeholders  Defining roles and responsibilities of stakeholders in the business analysis effort  Developing estimates for business analysis tasks  Planning how the business analyst will communicate with stakeholders  Planning how requirements will be approached, traced, and prioritized  Determining the deliverables that the business analyst will produce  Determining the metrics that will be used for monitoring business analysis work
  7. 7. [2.1] Plan Business Analysis Approach [2.2] Conduct Stakeholder Analysis [2.3] Plan Business Analysis Activities [2.4] Plan Business Analysis Communication [2.5] Plan Requirement Management Process [2.6] Monitor Business Analysis Performance TasksInputs Business Need Enterprise Architect Organizational Process Asset Expert Judgment Business Analysis Performance Metrics Outputs [2.1] Business Analysis Approach [2.2] Stakeholder list, roles and responsibilities [2.3] Business Analysis Plan [2.4] Business Analysis Communication Plan [2.5] Requirement Management Plan [2.6] Business Analysts Performance Assessment [2.7] Business Analysis Process Assets Tasks Providing Inputs 5.1 Tasks Using Outputs 2.3 2.5 2.3 2.4 3.1 4.1 6.1 2.4 2.5 2.6 2.6 3.2 4.1 4.2 6.1 2.3 Organizational Process Assets 4.4 4.5 Input sources are external to BABOK V2 Overview map of Knowledge Area Refer appendix for overview of BABOK V2 task layout to understand the numbering system
  8. 8. TASKS
  9. 9. The Purpose of the task Identify the stakeholders Describe the overall process for work on a given initiative How and when tasks will be performed The techniques used and deliverables produced
  10. 10. Layout of the task  Business Need  Expert Judgement  Organisational Process Assets Input Plan Business Analysis Approach Task  Business Analysis Approach Output Techniques  Decision Analysis  Structured Walkthrough  Process Modelling Stakeholders  Customer  Project Manger  Regulator  Sponsor  Subject Mater Expert  Tester  End User
  11. 11. Key Elements
  12. 12. Plan Driven Change Driven
  13. 13. Impact of Plan Vs Change on Business Analysis
  14. 14. When to perform business analysis? Plan Driven Change Driven  Most BA Work at the beginning Or during one specific phase  Initial list of high-level requirements (requirements envisioning)  Product backlog updated throughout project  Prioritized and reprioritized  Highest priority will have detailed requirements
  15. 15. Level of details in the deliverables? Plan Driven Change Driven  Significant amount of formality and detail  Formal document/s  Standard template  Relevant stakeholders approve documents before work starts  Defining requirements through team interaction  Gathering feedback on a working solution  Often limited to a prioritized requirements list  Additional documentation is discretionary  Often produced after solution is implemented
  16. 16. How change is managed? Plan Driven Change Driven  Changes only occur when they are genuinely necessary  Clearly justified  Mini Project  Impacts solution and project scope  Formal process  Normally increase near end of project  Presume difficult to identify all requirements  No separate change management process  Changes simply prioritized as per normal list items
  17. 17. When & How to communicate with stakeholders? Plan Driven Change Driven  Rely on formal communication methods  In writing and pre-defined forms  All documentation normally archived as project history  Focus on frequency of communication  Less formal communication takes precedence  Official communication in writing  Frequently occurs after implementation
  18. 18. Key Techniques Note: Only covering few technique in this presentation – Planning for complete presentation on techniques
  19. 19. Using Decision Analysis for Business Analysis Approach - Example Business Analysis Approach Agile Approach Waterfall Approach Change in Requirements Stable Requirements Change in Requirements Stable Requirements Rework (at least 70%) Min Rework (10%) Min Rework (10%) Waste Deliverables (10%) Min Rework (20%) Waste Deliverables (10%)Probability – 90% Probability – 90% Probability – 10% Probability – 10%
  20. 20. Know people side of change Identify Stakeholders Analyze Stakeholders Devise Stakeholders Management Plan Review/Revise Stakeholder Management Strategies Complete this during Approach Definition Project Inception Phase Project Execution Phase
  21. 21. Layout of the task  Business Need  Enterprise Architecture  Organisational Process Assets Input Conduct Stakeholder Analysis Task  Stakeholder List, Roles, and Responsibilities Output Techniques  Acceptance and Evaluation Criteria Definition  Brainstorming  Interviews  Organization Modeling  RACI Matrix  Stakeholder Map  Process Modelling  Requirements Workshops  Risk Analysis  Scenarios and Use Cases  User Stories  Scope Modeling  Survey/Questionnaire Stakeholders  Customer  Project Manger  Subject Mater Expert  Regulator  End User
  22. 22. Customer End User Sponsor Implementation SME Regulator Business Analyst Operation Support Project Manager Tester Domain SME Supplier
  23. 23. Categorization of stakeholders Meet their needs Key player Least important Show consideration PowerOfInfluence Interest Stakeholder Stake in the project Potential impact on Project What does the Project expect the Stakeholder to provide? Perceived attitudes and/or risks Stakeholder Management Strategy Responsibility Additional Information that you might want to capture about each stakeholder
  24. 24. Assign responsibilities and accountability – RACI Matrix Responsible This is the person or role responsible for creating or developing the product or performing the task. In Figure, for example, a business analyst is responsible for creating the interview notes. Accountable This is the person or role who will ‘carry the can’ for the quality of the product or task. The project sponsor, for instance, must ultimately be accountable for the business case for a project. This is the person or role responsible for creating or developing the product or performing the task. In Figure, for example, a business analyst is responsible for creating the interview notes. Consulted These stakeholders are informed about a product or task, although they may not have contributed directly to it. For example, the project sponsor has the right to be kept informed about any of the products created during the project Informed
  25. 25. Key Elements
  26. 26. The points while performing stakeholder analysis Complexity of Stakeholder Group Attitude and Influence Authority Levels For Business Analysis Work
  27. 27. The Purpose of the task Scope of Business Analysis work Deliverables required Estimate effort to complete the work by scheduled dates Identify management tools required to measure progress of work and deliverables
  28. 28. Layout of the task  Business Analysis Approach  Stakeholder Lists, Roles and Responsibilities  Business Analysis Performance Assessment  Organizational Process Assets Input Plan Business Analysis Activities Task  Business Analysis Plans Output Techniques  Estimation  Functional Decomposition  Risk Analysis Stakeholders  Customer  Project Manger  Subject Mater Expert  Regulator  End User  Operation Support
  29. 29. Key Elements
  30. 30. Review following aspect while planning Business Analysis activities Geographic Distribution of Stakeholders Type of Project or Initiative Business Analysis Deliverables
  31. 31. Key Techniques Note: Only covering few technique in this presentation – Planning for complete presentation on techniques
  32. 32. Example of Functional Decomposition Define Detail Requirements Elicit Requirements Conduct Workshop Document Requirements Business Process Maps Create FSDDefine NFR Prioritize Requirements Conduct JAD Session Define Usecase
  33. 33. The Purpose of the task What needs to be communicated? When the communication should occur? Who is the appropriate audience? How message will be delivered?
  34. 34. Layout of the task  Business Analysis Approach  Business Analysis Plan  Organizational Process Assets  Stakeholders List, Role and Responsibilities Input Plan Business Analysis Communication Task  Communication Plan Output Techniques  Prepare Requirements Package  Communicating Requirements (Skill)  Structured Walk Through Stakeholders  Customer  Project Manger  Tester  Subject Mater Expert  Regulator  End User  Operation Support
  35. 35. Key Techniques Note: Only covering few technique in this presentation – Planning for complete presentation on techniques
  36. 36. Create packages based on the need, project type & audience Executive/ Non-Technical End User Developer/ Testers  Presentation  Prototype  Business Process  High-level Usecase  Detail Usecase  Workflows  UML Diagrams  Data Models  Presentation  Prototype  Functional Usecase  UAT Test cases/ Scenarios Only an example
  37. 37. The Purpose of the task Determine the appropriate requirements process Determining whether and how requirements are changed Determine what attributes to be captured for requirement Determine tracking mechanism for requirements
  38. 38. Layout of the task  Business Analysis Approach  Business Analysis Plan  Organizational Process Assets Input Plan Requirements Management Process Task  Requirements Management Plan Output Techniques  Decision Analysis  Risk Analysis  Problem Tracking Stakeholders  Customer  Project Manger  Tester  Subject Mater Expert  Regulator  End User  Operation Support
  39. 39. Key Elements
  40. 40. Elements to consider when planning requirements management Repository of requirements Traceability Select requirements attributes for capturing process Requirements prioritization methods/ process Change management process
  41. 41. Key Considerations Note: Only covering few technique in this presentation – Planning for complete presentation on techniques
  42. 42. Key considerations Process for requirements change Assess need for requirements traceability Requirements Attributes
  43. 43. Example Requirement Identifier Date Captured/ Stated Source of Requirement StatusDependencies Priority Category Author Updated By/Date
  44. 44. This is how requirements looks like when in requirements management tool (RTM) Requirements repository within RTM Requirements attributes
  45. 45. The Purpose of the task Determine metrics for business analysis performance measure Identify performance issue and plan corrective actions Business analysis process & performance improvement
  46. 46. Layout of the task  Business Analysis  Performance Metrics  Business Analysis Plan(s)  Organizational Performance Standards  Requirements Management Plan Input Business Analysis Planning & Monitoring Task Business Analysis Performance Assessment  Business Analysis Process Assets Output Techniques  Interviews  Lessons Learned  Metrics & Key Performance Indicator  Process Modelling  Root Cause Analysis  Survey & Questionnaire  Problem Tracking  Variance Analysis Stakeholders  Customer  Project Manger  Subject Mater Expert  Regulator  End User
  47. 47. Metrics for measuring business analysis performance
  48. 48. Knowledge area summary • Stakeholders, Types of requirements, Organization’s standards formality Identify • Stakeholder roles and responsibilities Define • Estimates to complete required business analysis tasks Develop • Stakeholder communication • How requirements will be approached, traced and prioritized Plan
  49. 49. BABoK®Version2Release2009 BABOK V2 - Business Analysis Knowledge Areas & Tasks Layout [2] Business Analysis Planning & Monitoring [3] Elicitation [4] Requirements Management & Communication [5] Enterprise Analysis [6] Requirement Analysis [7] Solution Assessment & Validation [2.1] Plan Business Analysis Approach [3.1] Prepare for Elicitation [4.1] Manage Solution Scope and Requirements [5.1] Define Business Need [6.1] Prioritize Requirements [7.1] Assess Proposed Solution [2.2] Conduct Stakeholder Analysis [3.2] Conduct Elicitation Activity [4.2] Manage Requirement Traceability [5.2] Assess Capability Gap [6.2] Organize Requirements [7.2] Allocate Requirements [2.3] Plan Business Analysis Activities [3.3] Document Elicitation Results [4.3] Maintain Requirement for Re [5.3] Determine Solution Approach [6.3] Specify and Model Requirements [7.3] Assess Organization Readiness [2.4] Plan Business Analysis Communication [4.4] Prepare Requirement Package [5.4] Define Solution Scope [6.4] Define Assumptions & Constraints [7.4] Define Transition Requirements [2.5] Plan Requirement Management Process [4.5] Communicate Requirements [5.5] Define Business Case [6.5] Verify Requirements [7.5] Validate Solution [2.6] Manage Business Analysis Performance [6.6] Validate Requirements [7.6] Evaluate Solution Performance [3.4] Confirm Elicitation Results

×