SIX KNOWLEDGE AREAS OF BUSINESS ANALYSIS

Transcription

1 THE BABOK SIX KNOWLEDGE AREAS OF BUSINESS ANALYSIS

2 PRESENTER Tomette J. Kirk, CBAP Business Consultant, Humana Health Care Reform 2

3 BUSINESS ANALYSIS THE BASICS What do they have? What do they need? What do they want? Why? Why? Why Why? Why? 3

4 BAS ARE EVERYWHERE Found in engineering, software, finance, food service, manufacturing, hospitality, staffing. People doing business analysis might not be called a BA. They may also include: business systems analysts systems analysts requirements engineers process analysts product managers product owners enterprise analysts business architects management consultants People who are titled a BA might not be doing business analysis. 4

5 WHAT IS THE PROCESS OF BA? Is there a Process in Business Analysis? What are the essential fundamentals of Business Analysis? Do BAs need to be SMEs? How does it help? How does it hinder? 5

6 THE IIBA BODY OF KNOWLEDGE SIX KNOWLEDGE AREAS FOCUS ON REQUIREMENTS EXCELLENCE 6

7 THE IIBA MODEL OF BUSINESS ANALYSIS IIBA International Institute of Business Analysis Website: The Business Analysis Body of Knowledge (BABOK ) outlines six Knowledge Areas in the BA Life Cycle: Business Analysis Planning and Monitoring Elicitation Requirements Management and Communication Enterprise Analysis Requirements Analysis Solution Assessment and Validation IIBA, the IIBA logo, BABOK and Business Analysis Body of Knowledge are registered trademarks owned by International Institute of Business Analysis. These trademarks are used with the express permission of International Institute of Business Analysis. 7

8 SIX KEY KNOWLEDGE AREAS 8

9 BABOK RELATIONSHIPS -IIBA Business Analysis Body of Knowledge 9

10 BUSINESS ANALYSIS PROCESSES Changes happen quickly. This diagram depicts how and where to respond to them. RavenFlow Webinar: Agile Business Analysis Presentation by: Mary Gerush, 10

11 FOCUS ON REQUIREMENTS Whether the solution involves processes, policies, or systems, the Requirements must be identified for successful implementation. Elicit Analyze Validate Manage Communicate Requirements are key, whether the solution idea(s) are: System development Process improvements Organizational change -IIBA Business Analysis Body of Knowledge 11

12 BUSINESS ANALYSIS PLANNING AND MONITORING Plan for Greatness Monitor Outcomes 12

13 ABOUT BUSINESS ANALYSIS PLANNING & MONITORING BA planning and monitoring involves: Estimating BA tasks, time, effort, resources, approach. Identifying stakeholders; defining roles. Defining and selecting BA tasks and activities. Planning how the BA will communicate with stakeholders. Determining the deliverables the BA will produce. Monitoring the BA work and effectiveness. Reporting on BA work to ensure effort is producing expected outcomes. -IIBA Business Analysis Body of Knowledge *Each of these variables will change depending on the type and methodology of the project. 13

14 DOING BA PLANNING & MONITORING Learn the answers to questions such as: What is the culture of the organization? What type of project / solution is being assessed? Is it a software solution, business process evaluation, or a needs analysis? What is the scope of the solution (to avoid requirements creep)? What is the complexity of each phase of the project? What are the skills of the group? What is the planned development methodology to be used? What deliverables are expected? How will the requirements be presented? Different activities are appropriate for each stage of requirements management. Different kinds of activities must be tailored for the type of project and team. 14

15 EXERCISE: IDENTIFY STAKEHOLDERS, ROLES, & USERS Stakeholder Analysis Plan: List identified Stakeholders. Identify Actors (stakeholders who are actual users of the solution). Group users who interact with the solution into the same role (for example, Management). Stakeholders Roles User? Gro CEO Sponsor mg Engagement Mgr Sponsor mg Director of HR Approver mg Executive Assistant Admin1 adm Operations Manager Admin2 mg Employees Employees ee Contractors Employees ee QuickBooks System Vendor(s) External Org Bank External Org 15

16 BA PLANNING: CHOOSE APPROPRIATE ACTIVITIES Individuals Individual Interviews Observation Groups Focus Groups In/Out Diagram Writing Surveys / Questionnaires Delphii Analysis (series of 3 anonymous polls) Blog / Wiki Electronic Bulletin Board or Cork Bulletin Board 16

17 BUSINESS ANALYSIS MONITORING Evaluate the success of the activities. Formally Informally Establish metrics to measure the effectiveness of the business analysis activities and outcomes. Review, review, review. Conduct a formal or informal lessons learned. Report Journal 17

18 ELICITATION Asking the Useful Questions 18

19 ABOUT ELICITING REQUIREMENTS Elicit defined: Draw forth or bring out (something latent or potential). Call forth or draw out (as information or a response). Engage the stakeholders actively to define requirements. Requirements must be complete, clear, correct, and consistent because the requirements serve as the foundation for the solution to the business needs. They are a contract. The solution in question may be a business system, an automated system or both. The scope of the Elicitation work may be a new system or an enhancement to an existing system. -IIBA Business Analysis Body of Knowledge 19

20 EXERCISE: WHY GAME BAs: the world s tallest 3 year olds. (Dave DeBruine) In Partners: Tell about something you bought recently. Use the three why cards to keep the questions going. Do it again This time, try to think of three ways to ask Why? without using the word why? 20

21 ELICITATION: INTERVIEW PREPARATION Identify the stakeholders to be interviewed. Consider in advance: Where to conduct the interview, How to establish rapport with the stakeholder, How to handle interruptions, How to handle difficult situations. Schedule the interview and arrange the logistics for the meeting. Prepare an agenda. Send the agenda and questions in advance. 21

22 ELICITATION: HOW TO INTERVIEW Do: Remember your 7th Grade English Composition Skills. Ask: Who? What? When? Where? How? Why? Ask open ended questions (ask very few yes/no ). Get the history (current state). Ask about the future state. Plan ahead. Write out the key questions. Treat the interviewee as the expert of the hour. Openly accept everything the interviewee says. Don't: Don t ask What are your requirements? Don t let it turn into a complaint or a can t session. Don t discount the way it s been done in the past. Don t limit your interview to the script (but do stick to the goals). Don t make one person the expert of the project. Don t take sides or make promises. Don t argue just absorb. 22

23 ELICITATION: E-LISTEN-TATION It is better to listen in order to understand than to listen in order to reply. 23

24 ELICITATION ACTIVITY IDEAS FROM GROUPS Workshops Focus Groups In/Out Diagram Parking Lots Written Input Surveys / Questionnaires Delphii Analysis (series of 3 anonymous polls) Blog / Wiki Bulletin Board (electronic, or just ol fashioned cork) Idea Box 24

25 REPEAT THAT AGAIN, PLEASE? Eliciting the requirements is just the first step. Now all the knowledge is in your hands. Remember, your project team has not heard what you have heard be prepared to repeat, repeat, repeat. Set the expectations with your interviewees that you may need to revisit the same content again, once you have regrouped with the project team. Prepare stakeholders that you may need to repeat, repeat, repeat, even though they have told you information. 25

26 REQUIREMENTS MANAGEMENT AND COMMUNICATION Socialize the Discoveries 26

27 ABOUT REQUIREMENTS MANAGEMENT & COMMUNICATION Manage and communicate requirements to a broad and diverse audience. Ensure all stakeholders have a shared understanding of the nature of a solution, Ensure stakeholders with approval authority are in agreement as to the requirements, assumptions, and constraints for the solution. Communicate requirements to bring the stakeholders to a common understanding. Stakeholders represent people from different backgrounds and business domains, Communication is both challenging and critical to the success of any initiative. Assist with understanding the effects of change. Link business goals and objectives to the actual solution that is constructed and delivered. -IIBA Business Analysis Body of Knowledge 27

28 CHANGE MANAGEMENT: DECIDE ON A PROCESS Identify if the client has a change process in place. Choose and agree upon a change process with PM and stakeholders. Use the change process faithfully, especially after the Requirements Document has been signed. No under the table changes. 28

29 MANAGE CHANGES TO REQUIREMENTS Capture any requirements changes identified by the project stakeholders or project team. Identify all the areas the Req. change will impact before agreeing to the change (traceability). Document assumptions around requirements. Document issues around complexity, completion, or understanding of requirements by stakeholders. 29

30 PLAN FOR CHANGE BEFORE IT HAPPENS One cosmic truth is Change Happens. Plan on it. Iterative, agile development methodologies (frequent client review, prototyping examples) are helpful when new requirements are anticipated to be discovered throughout the project (i.e. when working with human beings, especially in an unfamiliar domain). Few people have the skill to envision something intangible. Expect people to change their minds once they finally get their hands on the end product. 30

31 Low Project Influence High REQUIREMENTS COMMUNICATION MATRIX Different types of communication happen based on the different types of stakeholders. The Communication Matrix rates stakeholders by project influence and solution user. The Communication Plan helps schedule how often to communicate with the various project stakeholders. Chart by solution use / project influence. CEO Eng. Mgr Management Goal: Keep them satisfied Communication Plan: High Level; Basics; Positive Fringe Stakeholders (may be Negative Stakeholders) Vendor Goal: Bank Monitor closely QuickBooks Low Communication Plan: General announcements Keep your friends close, keep your enemies closer. Dir HR Admin2 Customer Users Admin1 Employees Goal: Manage closely Contractor Communication Plan: Regular meetings; face-to face; frequent; ; details developer Team Members PM Goal: BA Keep them informed Testers Communication Plan: Regular meetings; ; need to be kept in the loop of communication High Solution User 31

32 REQUIREMENTS COMMUNICATION TIPS Do: Know your audience and target communication type needed. Vary the types of communication you use. Keep copies of your communication. Proofread before sending. Include your project manager in regular updates. Don't: Don't assume communication has happened. Don't use for: official approval, sign-offs, expressing frustration, requesting behavior change, humor, esp. sarcasm. 32

33 ENTERPRISE ANALYSIS Know the Context 33

34 ABOUT ENTERPRISE ANALYSIS Identify a business need, problem, or opportunity. Define the nature of a solution that meets that need. Justify the investment necessary to deliver a solution. Provide context to requirements analysis and solution identification for a given initiative or for long-term planning. Identify and document business rules and business requirements. Know the culture of the organization or department. -IIBA Business Analysis Body of Knowledge 34

35 BIG NEED, OR SMALL NEED? 35

36 REVIEW COMPANY DOCUMENTS Input READ: Company Profiles Company Mission Statement Goals/Objectives Current Project plans 36

37 ENTERPRISE ANALYSIS ACTIVITIES Determine the Business Need(s) Help write a Business Case Identify existing requirements Define Project Scope Assess Capability Gaps -IIBA Business Analysis Body of Knowledge 37

38 REQUIREMENTS ANALYSIS Making Sense of the Input 38

39 ABOUT REQUIREMENTS ANALYSIS Define and describe the characteristics of an acceptable solution to a business problem so the project team has a clear understanding of how to design and implement it. Create documentation to structure the raw data collected during Elicitation. Analysis, not merely stenography, is crucial to identify gaps in the information and to define the capabilities of the solution. Resist providing solutions or code. Keep the requirements broad and let the developers be specific. Develop estimates for the time, resources, and budget required to support or define a solution or solutions that will fulfill the requirements. -IIBA Business Analysis Body of Knowledge 39

40 DOCUMENTATION: THE OUTCOME OF ANALYSIS Rule #1: If a requirement is not documented, it is not a requirement. Requirements documentation may be: Use Cases Document or Diagram Requirements Document Specifications Document Requirements Change Form Context Diagram Story cards (Scrum) Different methodologies use different types of requirements documentation. An dialogue is not documentation. 40

41 FORMAL REQUIREMENTS DOCUMENT BASICS A typical requirement shall have: unique name unique number, priority, brief summary, and rationale. NUMBER STAKEHOLDER METHOD DEFINE PRIORITY REQUIREMENT TRACES Req-# For traceability Name Interview, survey, RFP, Company Profile Terms in the REQ which need further explanation. Put these in a glossary. High Med Low Description of requirement. When possible, use User- Action-Thing syntax Trace to Req# and section. 41

42 ANALYZE THE PRIORITY OF FEATURES: MOSCOW RANKING MEANING PRIORITY WHEN? MUST Inclusion is mandatory. The solution is not acceptable or is unusable without it. These are the true requirements. High Now SHOULD Important, but not necessary. Without the feature, there will be significant loss of user utility or market share. Although this feature would enhance the solution, the product is still acceptable in its absence. High/Med Later COULD Customers and users can live without this feature if it is going to cost too much or cause a delay in delivery of Must features. Delivery of these features can be postponed. Med/Low Later WON T This feature will not be considered for the solution at this time (or at all). OUT OF SCOPE Low/None Never 42

43 WHICH INTERPRETATION FITS THE NEED? Mary had a little lamb. It was Mary s lamb, not Tom s, Nancy s nor Harry s. Mary had a little lamb. She no longer has the lamb. Mary had a little lamb. She had only one lamb, not several. Mary had a little lamb. It really was surprisingly small. Mary had a little lamb. She didn t have a dog, cat or goat. Mary had a little lamb. John still has his little lamb. Mary had a little lamb. She had a rather large cow, though. Donald C. Gause and Gerald M. Weinberg, Exploring Requirements: Quality Before Design. 43

44 APPLY SIX QUALITY CHARACTERISTICS Does the requirement meet the customer s need? Is it clearly worded? Is the format straightforward? Is it singular? Is it tied to a higher level REQ? Is it fleshed out? Unambiguous REQUIREMENT FIT FOR USE Traceable *Scott Stribney, Right Requirements, Right Now 44

45 SOLUTION ASSESSMENT AND VALIDATION Measure Twice, Cut Once 45

46 ABOUT SOLUTION ASSESSMENT & VALIDATION The BA is one of the most knowledgeable team members regarding the business needs and requirements, and can help assess how proposed solutions would impact the business and users. Once the requirements are defined, the BA may be involved in selecting or designing an appropriate solution. An implementation plan for the project is needed. It will include: Business worker training and creation of new employee procedure manuals, Conversion of existing information, and User acceptance testing (UAT) of any software/ hardware component of the solution. -IIBA Business Analysis Body of Knowledge 46

47 ...can affect (C,R,U,D) this process. This user type DEFINE SECURITY AND ACCESSIBILITY CRUD = Create, Review, Update, Delete A CRUD Matrix can help determine security access to objects. A CRUD Matrix is also one of the best tools for finding missing requirements Look for : Blank Rows or Columns Data and Processes need each other A blank row or column indicates a gap. Look for Cs is the data created? CRUD Security Matrix Time Reports PTO Bucket Employee C,R,U,D R Admin1 C,R,U,D C,R,D R R Admin2 C,R,U,D C,R,D R,U C,R,U,D Approver R R R CRUD Functional Matrix This object Employee Admin1 Admin2 Approver Enter Time C,R,U,D C,R,U,D C,R,U,D Run Report C,R C,R Review PTO R R Assign Bucket R R C,R,U,D Approve Time R C,R,U All use cases could be listed here, if desired....can access (C,R,U,D) this object in this way. 47

48 SUPPORT THE IMPLEMENTATION OF THE SOLUTION Testing Identify user testers. Write test scenarios for users. Report issues to developers. Document results. Training May conduct training for individuals or groups of users. Create training materials and presentations. Create instruction manuals and tip sheets for users. 48

49 BABOK TOC: SIX KNOWLEDGE AREAS 49

50 Thank You! Thank you for attending the chapter meeting tonight We hope you enjoyed the Six Knowledge Areas: A Foundation for Business Analysis Please complete the evaluation forms before leaving. Remember: Baseball game interest? Register for chapter membership for 2013! 50