Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Business Analysis 2.0: Beyond the Basics


Published on

A brief overview of BABOK 2.0 and its implications for Business Analysts. This presentation also shows the importance for all stakeholders - Product teams, Executives, Project Managers, etc. to understand everything that goes into Business Analysis and technology development. The focus is primarily on technology/software development, but the concepts apply to all types of product & service delivery

Published in: Business, Technology

Business Analysis 2.0: Beyond the Basics

  1. 1. BABOK 2.0D. Berglund Beyond the Basics of Business Analysis
  2. 2. So What is a Business Analyst2  A Business Analyst can be defined a few different ways:  BABOK 1.6: “Works as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems…”  BABOK 2.0: “Is any person who performs business analysis activities, no matter what their job title or organizational role may be…”  Traditionally, a Business Analyst works as a liaison among stakeholders in order to elicit, analyze, communicate, and validate requirements for changes to business processes, policies, and information systems.  My Definition  A Business analyst works toenable the organization to achieve its goals opportunities and recommends solutions that understand business problems, gaps, and via clearly defined requirements (capabilities). Solutions may include IT systems, process improvements, or other organizational changes.
  3. 3. The Need for Business Analysts3 Business Analysts help decision-makers determine the best way to meet the business‟ needs through an understanding of 1. How an organization accomplishes its goals/objectives 2. Why the business exists (its purpose) 3. How users perform their roles This grounding in business needs, provides clarity into the right solutions that allow the business to more effectively meet its objectives and goals.
  4. 4. What‟s the BABOK?4 The BABOK is a standard, encompassing multiple knowledge areas, tasks and activities, and best-practices that helps BAs understand the sum of knowledge that is used within the Business Analysis profession. Defining a set of standards (the BABOK) provides the following benefits:  Creates a shared understanding of business analysis  so we‟re all on the same page  It defines the Business Analyst role and activities  so we know what to do!  It describes the techniques that a Business Analyst should be able to perform  so we get the job done  It describes the competencies that are required to be effective  So we get the job done well
  5. 5. What Else is the BABOK?5  It‟s not just for software/application requirements  It‟s not a “How-to Guide”: it‟s a discipline  It‟s Methodology-neutral  You can use: PESTLE, HEPTALYSIS, MOST, SWOT, Five Why‟s, etc.  It‟s scalable to all projects regardless of their size and complexity  It‟s compatible with various Lifecycles: Iterative, Agile, Waterfall, etc.
  6. 6. So you want to be certified? Certification Requirements:  5 years (7,500 hours) of business analysis work in the last 10 years  “Acceptable” activities include:  Hands-on business analysis activities (as described in BABOK)  Coaching or mentoring Business Analysts with respect to business analysis activities  Development of an organization‟s business analysis methodology and/or best practices (coming up with new/better ways to do BA work)  Development of business analysis training courses  Demonstrated experience and expertise in at least 4 of the 6 BABOK Knowledge Areas (we‟ll get to these)  At least a high school diploma or equivalent  21 hours of BA professional development in the last 4 years  2 professional references (not your aunt Margaret)
  7. 7. Don‟t you mean PMBOK?7  Think of PMBOK as the Project Management version of BABOK.  PMBOK main focus is on project parameters  BABOK main focus is on the product parameters  Instead of focusing on knowledge areas, the PMBOK defines 5 main stages/processes involved in a project: 1. Initiating 2. Planning 3. Executing 4. Controlling 5. Closing  When combined, the PMBOK and BABOK:  Complement each other with standardized definitions and terms for PM and BA activities  This helps us all get along.  Create local communities of PM and BA professionals to meet and discuss common experiences  Provide certification models that establish consistent best practices and industry standards  Provide a common understanding of knowledge and skills for PM and BA professions
  8. 8. Origins of PMBOK/BABOK8  Project Management Body of Knowledge (PMBOK)  First published in 1987 by the Project Management Institute (PMI)  A framework that defines project management and related concepts, describes the project management life cycle, and outlines related processes  Written with Project Managers in mind – PMP certification  Business Analysis Body of Knowledge (BABOK)  First published in 2006 by the International Institute of Business Analysis (IIBA)  A framework that describes Business Analysis areas of knowledge, their associated activities and tasks and the skills necessary to be effective in their execution  Written with Business Analysts in mind – CBAP certification
  9. 9. Let‟s work Together9 PMs and BAs: Dynamic Duos Strong PM Weak PM A roaring success, great Too much time developing Strong BA balance between getting requirements, project falls behind accurate and thorough schedule, “scope creep” often requirements and moving occurs project along Requirements aren‟t well Project failure! Weak BA constructed, some may be missed, rework needed late in the process, schedule and budget suffers
  10. 10. BA‟s Contribution to DeliveryBeing a Business Analyst requires multiple skills and to be truly successful, you need to look beyond what‟s in front of you and dig deeper. As a Business analyst expect to: Influence scoping and prioritization of features, sprints, and stories Unfold the architecture, requirements, & business rules Identify business opportunity and define the Business Architecture Ensure that the solution meets the requirements Collaborate with business and technical SME‟s Manage requirements repository Identify Product Risk
  11. 11. Effective Business AnalysisAn Effective BA will go beyond checking boxes. To be truly effective a BA will:• Analyze & solve problems (meaning you need to dig in and research)• Understand the business (do you really know how the company makes money from the project?)• Communicate effectively (write & speak clearly)• Manage customer/client relationships• Lead/Facilitate discussions• Negotiate & build consensus (from bottom up and top down)• Prototype data & processes• Plan & manage activities• Facilitate & develop business strategy• Understand & manage organizational change• Influence joint planning at all levels
  12. 12. Let‟s Define a Few Things Each knowledge area describes the tasks performed by business analyst to accomplish the purpose of that knowledge area. What‟s a task?  Formal or informal, universally applicable  Necessary components of a given Knowledge Area  Not limited to one knowledge area  Creates a completed output that has value  Becomes an input to another task  Can be completed numerous times for one project  Has consistently defined inputs and outputs
  13. 13. Techniques How about a Technique?  Describes how tasks are performed under specific circumstances.  A task may have none, one, or more related techniques.  BABOK techniques cover the most common and widespread uses  Techniques may evolve, change with time Methodology  Determines which tasks and techniques are used to solve a business problem  Generally affects all tasks performed in a project  BABOK acknowledges methodologies, but... Neither defines nor prescribes methodologies  Typically owned by individual authors
  14. 14. Techniques: ModelsA few examples of Techniques Class Model CRUD matrix (access rights) Data dictionary Entity relationship diagrams Process / Flow models Use cases More...
  15. 15. Here‟s an Example Your Task: Conduct Requirement Elicitation Possible Techniques:  Brainstorming: you know…anything goes idea generation  Requirements Workshop: scoping, discovering, defining, prioritizing  Interview  Prototyping: my favorite – map it out; construct/create to show others how the product might function
  16. 16. The Big Daddy DefinitionRequirement are…A documented representation of a condition or capability that iseither: 1. needed by a stakeholder to solve a problem or achieve an objective. 2. that must be met or possessed by a solution to satisfy a contract, standard, specification, or other formally imposed documents.
  17. 17. Making A Shift Towards Excellence If you want to do more, then start working on the following behaviors.  Expand from facilitating and transferring to visioning  Don‟t just accept face value. Question facts until you can model them and gain consensus from all stakeholders.  Link Analysis: How do the pieces fit together? Does this make sense?  Empower your communication with collaboration  Rather than specialize, expand your sphere of knowledge.  Move from managing change to embracing change  Abandon your space and be face-to-face  Leadership: Recognize the future and influence stakeholders  Organize: It‟s not just the Project Manager‟s responsibility to be organized. You‟ll never be successful if you can‟t stay on top of things.
  18. 18. Realize Your Opportunity For Success Unfold requirements iteratively by coupling with the implementation of the business and the technical designers – make sure both groups see the same things Lead as an Analyst. Assume no one else will pick up the pieces. You may be the only one trying to tying everything together. Leverage the power of prototyping. Create visual representations to ensure everyone is on the same page (process flows, maps, prototypes, etc). Business rules are pervasive – seek them out, document them and re-check. Are there exceptions? Adapt how you organize and characterize the requirements. Businesses are a fluid beast – during a storm it‟s better to be in a boat than on a dock. Get out there and see which way the tides are flowing. Take on the Product perspective: Look at the business case, consider the consumer, and recognize how the output will be used.
  19. 19. Four BA Fundamentals1. Basic Skills • Analysis, business / domain / IT knowledge,2. Advanced Skills • Meeting management, presentation, decision-making, conflict, negotiation3. Leadership Skills 1. Coaching, motivating, interviewing4. Peripheral Skills (e.g. sales)
  20. 20. Who is involved in Business Analysis? Implementation Project SME Manager Domain SME Tester Supplier RegulatorCustomer Business Sponsor Analyst
  21. 21. Knowledge Area OverviewIdentify business problem, Influence scoping and prioritizationopportunity or unmet need and of features, springs, and stories Unfold the architecture,define Business Architecture requirements, & business rules Business Analysis Planning Solution Enterprise Requirement Elicitation Assessment Analysis Analysis and Validation Requirements Management and Communication Fundamentals Collaborate with business and technical Mange repository of Ensure the solution meets SME’s requirements the stated requirements
  22. 22. BABOK 2.0 Knowledge Areas
  23. 23. BA Planning and Monitoring:What do I need to do?  Goal: Determine which activities are necessary to perform and complete as part of a given business request. Purpose BABOK Definition “This knowledge area “defines the resources Identify tasks and tasks associated with the planning and management of requirements gathering and activities throughout the requirements process” stakeholders The Value Story •Understand who you need to engage and what you need to accomplish •Track progress & provide input to project plan •Coordinate/align with teammates
  24. 24. Requirements Planning & Management:Realizing the Opportunity You should plan to work in an iterative fashion to continuously deliver value  Just like a startup, plan to fail quickly. This is the idea that the consulting firm Continuum touts. Why? Because it works! Shorten planning time so you have more time for drafts, trials, and tests. You learn much more by doing than by thinking of doing. Assemble a team of stakeholders you trust. This may include BAs, Product Managers, Project Managers, User Testing Specialists, etc. As they say at Home Depot – each link in a fence is a potential place for a squirrel to eat your flowers. Welcome change. Business needs and priorities will shift and your requirements will need to do the same.
  25. 25. Requirements Planning & Management:Realizing the Opportunity Before you get started with a project, ensure you understand and promote the Business Analyst skills.  You should be able to teach others the basics of BABOK. Plus, mentoring counts as experience towards your certification!  Teaching others on your project team will let them know more about your strategy and expectations. Skills are more important than roles  To be successful modeBA, you‟ll need to do more than just roles POV. write requirements. Go beyond listening as a and examine the issues from other collect and Identify and estimate the work  Why wait for others to tell you how have athings good idea of what longrelative values are in when you‟re buying a house, you should much fairly will cost and how the it will take? Just like your field. Each time you estimate, you‟ll perfect your ability to project into the future. Commit to the highest priority work  You‟ve got limited resources from a project perspective, andworknot just money to consider. You need to know leadership expectations regarding prioritizing it‟s so you can do the same. Manage the scope of the work incrementally  You can‟t build a boat in the water, and similarly state. until you‟ve gotten a good picture of the current you shouldn‟t start working on solution analysis Dynamically respond to product and project change  The product teams may need to adjust their product release strategy based on numerous factors. Be ready to move as needed to keep the core product alive and on the road to market.
  26. 26. Requirements Planning & Management: Basicsof Agile Development One popular method for technology development is known as „Agile‟ – at its core, agile development is a set of methods based on iterative and incremental changes where requirements evolve through collaboration between cross-functional teams. It‟s rapid, flexible and promotes an adaptive mindset that can respond to changes quickly. Re-prioritize features for the Product Backlog throughout iterations Assign capabilities/features to a sprint A sprint is an iteration of work Decompose capabilities into stories A story is a unit of business value Prioritize and commit to stories to be completed within a sprint Image from
  27. 27. Requirements Planning & Management1. Introduction: set the stage for the project. Very high level discussion2. Understand Team Roles for the Project: who is assigned to work on the project?3. Define BA WorkDivision Strategy: If there are multiple BAs, you need to establish boundaries for workload planning.4. Define Requirements Risk Approach: What are potential fail points? What are impacts of missing requirements?5. Determine Planning Considerations: Pull out the GANTT chart and figure out your timing and dependencies! Look into cross-project coordination as necessary – dollars and resources are finite in an organization so you need to know how you‟re all connected.6. Select Requirements Activities: Figure out all steps needed to create requirements7. Manage Requirements Scope/Estimations: Ensure stakeholders realize when scope is beyond capacity. It doesn‟t mean you‟ll remove requirements, but you should draw a line in the sand for what is in an out of scope for that release.8. Measure & Report Requirements Activity: Keep track of conversations, metrics and other critical information so you have a paper trail that shows your successes and so you can learn from mistakes.9. Manage Requirements Change: Change happens so expect it. Keep track of all changes and ensure stakeholders have visibility into changes.
  28. 28. Requirements Elicitation: Setting the Stage BABOK definition: “Provide a cohesive solution to a business problem”  Your goal in this phase is to translate stakeholder needs – even those they don‟t recognize.  You will “Own the problem, define the need.” When considering the requirements you‟ll write – remember that stories are units business value so they are written in the voice of the business user. Don‟t lose sight of the business case. This knowledge area describes “how stakeholder needs are analyzed, structured, andaspecified business analysis because and “Eliciting requirements is key task in for use in the design implementation of aserve as the foundation for the solution to the the requirements solution.” business needs it is essential that the requirements be complete, clear, correct, and consistent.” - BABOK 2.0
  29. 29. Requirements Elicitation• So what‟s the purpose of elicitation? • Elicitation answers the question: “What do stakeholders need?”• Your goal: Explore, identify and document stakeholder needs • When you meet, be sure to describe how you your to work with various stakeholders. Explaining plan understanding of the stakeholder list will give you an opportunity to validate the organizational model you‟ve established. • Ensure you have a complete understanding of their needs – restate what they told you. It sounds redundant, but it works.
  30. 30. Elicitation: Ins and Outs• Inputs: • Business Case / Business Need • It is absolutely critical you understand the fundamentals of the business to create the „right‟ solution. Get to know your business model and the needs you plan to address through this project. • Organizational Process Assets required to Implement • This may start as an informed guess. Be sure to validate this with stakeholders.• Output will be Requirements. We‟ll cover those next.
  31. 31. BABOK Requirements Elicitation TasksTasks:1. Structure Requirements Packages2. Create Business Domain Model3. Analyze User Requirements4. Analyze Functional Requirements5. Analyze Quality of Service Requirements6. Determine Assumptions & Constraints7. Determine Requirements Attributes8. Document Requirements9. Validate Requirements10. Verify Requirements
  32. 32. Tips for Requirements Elicitation Use the right elicitation technique at the right time with just the right amount of rigor Consider how much is known, how much still needs to be discovered, and when the team needs the specificsWait, what is Elicitation? Working with stakeholders to identify and understand their needs and concerns, and understand the environment in which they work. The purpose is to ensure that a stakeholder‟s actual underlying needs are understood and captured. Sometimes the stakeholder doesn‟t know them, it‟s up to you to get to the latent needs.
  33. 33. Requirement Management and CommunicationDescribes how BAs manage conflicts, issues and changes in orderto ensure stakeholders an the project team remain in agreement Manage Solution Scope andon the solution scope, how requirements are to be communicated Requirementsto stakeholders, and how knowledge gained by Bas is maintainedfor future use. ManagePurpose Answers the Question Requirements TraceabilityCommunicate the Does everyone Maintainoutcome; Identify and understand and Requirements for Re-usemanage change agree? PrepareThe Value Story Requirements PackageBring stakeholders to a common understanding; Communicateformalizes the structure of communication Requirements
  34. 34. Requirement Elicitation: Realize the Opportunity Co-locate with the Business:  Remember that the most efficient and effective method of conveying information to and within a development team is through a face-to-face conversation  If possible interact daily with the business and the development team. Walk by your teammates desk, use teleconferencing, or any other way to have face time with project team. Building relationships and a common understanding is vital to your success.  Keep in mind that the best requirements come from self-organized teams Create an adaptable approach to documentation to welcome changing requirements, even late in development  But…sync up with the rest of the team to ensure evolving requirements and potential designs remain in alignment across the board. In other words, verify to cover yourself. Only elicit requirements that lead to satisfying the customer through early and continuous delivery
  35. 35. Requirement Management and CommunicationGoal: Ensure stakeholders have access to BA work products Communications of all doc types and updates  Present the requirements in a format appropriate for the intended audience.  Don‟t plan with them.VP aasking them the format they‟d likeWalk it through it to send a Try 34 page requirement document. to see in. Ensure stakeholder agreement with solution scope (written sign-off!)  AKA Bring stakeholders to a common understanding Approvals (get it in writing) Manage conflicts, issues and changes Re-Use: facilitate enterprise consistency/efficiency (no sense in re-inventing the wheel)
  36. 36. Requirements Communication Per the BABOK  This knowledge area is “the collection of activities and considerations for expressing the output of the requirements analysis and documentation to a broad and diverse audience.”BABOK Tasks: 1. Create Requirements Communication Plan 2. Manage Requirements Conflicts 3. Determine Appropriate Requirements Format 4. Create a Requirements Package 5. Conduct a Requirements Presentation 6. Conduct Formal Requirements Review 7. Obtain Requirements Signoff
  37. 37. Product Backlog The Product Backlog is a set of features not yet completed but still desired A feature is functionality driven by business value Prioritize the unmet features for the Product Backlog  Keep this organized because you‟ll probably come back to it eventually.
  38. 38. Enterprise Analysis Per the BABOK Define Business This knowledge area describes “the Business Analysis activities Need that take place for organizations to (1) identify business opportunities, (2) build their Business Architecture framework, and (3) determine the optimum project investment path for the Assess Capability enterprise, including implementation of new business and Gaps technical system solutions.”Purpose Answers the Question DetermineUnderstand the big Why are we even Solution Approachpicture doing this project? Define Solution ScopeThe Value Story Define BusinessProvides the necessary context and Casefoundation on which you will evaluate allfuture issues and challenges.
  39. 39. Enterprise Architecture: Applying AgilePrinciples Your goal in this stage is to propose projects that meet strategic needs Envision an Enterprise Architecture that harnesses change for the customers competitive advantage Elicit input from motivated individuals who welcome change While developing the Enterprise Architecture and Business Case, pull in all of the necessary experts as a self-organized team Give the Enterprise Architecture effort the support needed to get the key activities done
  40. 40. Enterprise Architecture: Setting the StageEnterprise Architecture: Realizing the Opportunity Create vision of future business capabilities Develop the Business Case  Build the case for the requirements you put together. Make sure business leaders support them, or don‟t expect them to see the light of day. Facilitate portfolio investment decision making Identify implementation priorities Advocate that the most valuable projects launch first  Consider customer perspective. Where do you make the most revenue or what will allow the business to capture the most value? Advise release packaging  What‟s the best way to compile requirements? Think about what‟s actually being done or what‟s expected to work when a user is utilizing the finished product. Would it make sense to have button Z in release one if we don‟t have button X? If not, find a new package of requirements that works together.
  41. 41. Enterprise Architecture: Applying AgilePrinciples Envision an Enterprise Architecture that harnesses change for the customers competitive advantage.  Change is always going to occur in the business world. Businesses may try to be at the forefront of change or they may wait for change to come to them, but in either case the processes, technology, and products will have to be modified to incorporate what‟s happening outside the business.  Customers (or the company you work for) are constantly looking for ways to capture and maintain value. Staying agile and harnessing change will make YOU valuable. Elicit input from motivated individuals who welcome change While developing the Enterprise Architecture and Business Case, pull in all of the necessary experts as a self-organized team Give the Enterprise Architecture effort the support needed to get the key activities done
  42. 42. Requirements AnalysisGoal: Progressively elaborate, validate, verify stated requirements Prioritize Requirements  Validate requirements meet business need  Enable solution definition Organize Requirements Specify and Model Purpose Answers the Question RequirementsAnalyze the Data What does the solution HAVE to Define Assumptions and Constraints do? VerifyThe Value Story Requirements ValidateTransforms the business need into clearly defined Requirementscapabilities.
  43. 43. Requirements Analysis and Documentation Types of requirements:  Functional  Non-functional You‟ll need to: Identify gaps, ensure feasibility of capabilities Your capabilities inform/define the solution to be implemented Remember, your documentation is the basis for project estimating and planning and if it‟s not written down, it‟s not going to happen. Just like goal-setting, your Requirements should be SMART  Specific  Measureable  Achievable (no sense in wasting others time here, determine what is feasible)  Results-Oriented (describe an end-state)  Time-Related (define parameters of time as necessary)
  44. 44. Criteria for Assessing Requirements QualityBeyond just being SMART, make sure your requirements are: Allocatable  Unambiguous Attainable  Understandable Complete  Verifiable Correct  Not design-specific: Pay continuous attention to technical excellence Testable  Feasible Necessary  Measurable Traceable
  45. 45. Solution Assessment & Validation Goal: Assess solutions to ensure that strategic goals are met and requirements are satisfied Assess ProposedPurpose Answers the Question SolutionMake sure that the best Does the solution do Allocate Requirementssolution is chosen by what it‟s SUPPOSED tobusiness. do? Assess Organizational Readiness Define TransitionThe Value Story RequirementsEvaluate and choose among options; assess Validate Solutiontradeoffs and alternatives. Evaluate Solution Performance
  46. 46. Solution Assessment/Scoping Understanding Scope  Solution Scope  The set of capabilities required to meet a business need  Project Scope  The work required to implement the solution scope Business analysis is required to define solution scope.  Assess and select from proposed solutions  Assess deployed solutions to see how they met the original need Per the BABOK: This knowledge area “covers the business analysis tasks necessary to ensure that the solution meets the stakeholder objectives, is thoroughly tested, and is implemented smoothly.”
  47. 47. Solution Assessment & Verification Each story must have validation criteria  You need to make sure the completed product is, in fact, complete.  You don‟t know if you‟re done, if you don‟t say what‟s a finished product. To track story effort, give each story an assigned point value estimated based on complexity and the time it will take to GTD (get to done)  This is a useful way to explain to stakeholders how the project schedule will align with technical deliverables and accompanying business value In the Agile world, working versions of software are typically the primary measure of progress “Production ready” solution – what does it look like? You better get sign off from stakeholders ahead of time so developers know when their finished building.
  48. 48. Solution Assessment & Verification Emphasize that solution delivery must satisfy the client with valuable software/outcomes Pay continuous attention to technical excellence of the product  Does it perform the way Now isn‟t the time to accept high standards and your customer will be happy. it was requested? Maintain a solution design that you wouldnt be happy using. Now that you‟ve seen how it fits together, is it all essential? Perform regular self-assessment to reflect on how to become more effective Check in with stakeholders to see if their objectives are met completely Complete a usability check – this is critical! You‟re going to have many different types of users and you need to make sure it works for people beyond the people who built it. Support QA and testing. Be available to answer questions and ensure that testing gets done right. Manage problems, validate changes
  49. 49. Solution Assessment & Verification Propose alternative solutions  Not happy with a recommendation? Provide your own! Ensure product fit and integrity  Does the recommendation fit with the style of the product? Make sure that the solution aligns not just with the technical requirements, but with the design as well. Verify that the solution fulfills envisioned business capabilities Assess impact of solution on business operations  How? Ask them! Have your operations staff use the product and see how it works for a pilot client. Simulate future business processes
  50. 50. Underlying Competencies All of the past slides require the below underlying competencies. The skills are in you, now get to work and show them off. Analytical Behavioral Business Communication Software Thinking and Interaction Skills Characteristics Knowledge Skills ApplicationProblem Solving Creative Business Thinking Principles and Oral Facilitation and Ethics Practices Communication Negotiation General Purpose Decision Making Applications Industry Knowledge Personal Leadership and Learning Teaching Organization Influencing Organizational Knowledge Problem Solving Specialized Applications Written Trustworthiness Solution Teamwork Systems Communication Knowledge Thinking