Lesson Three: Business Analysis Planning and Monitoring BANA 110 Analyzing Business Needs and Requirements Planning Gary Mesick and Shelly Lawrence, Instructors
YOU ARE HERE Analysis and the Decision to Act Discovery/ Dialogue Entry/Contracting Define the Problem/ Opportunity Assess the Current Situation Plan the Work/ Begin Business Case Elicit the Requirements Develop the Solution/ Improvement Sell the Solution Contract Contract Business Case Project Plan Model Engagement/ Implementation Extension/ Recycle/ Termination Implement the Solution Stabilize Improve Fall Winter Contract Spring Project Plan
Business Analysis Planning & Monitoring INPUTS OUTPUTS TASKS * 5.1 2.1 2.4 2.6 BUSINESS ANALYSIS PERFORMANCE METRICS BUSINESS NEED 2.1 PLAN BUSINESS ANALYSIS APPROACH 2.2 CONDUCT STAKEHOLDER ANALYSIS BUSINESS ANALYSIS APPROACH BA COMMUNICATIONS PLAN BA PERFORMANCE ASSESSMENT 2.3 PLAN BA ACTIVITIES 2.4 PLAN BA COMMUNICATION 2.3 2.6 2.5 ENTERPRISE ARCHITECTURE EXPERT JUDGMENT 2.5 PLAN REQ TS MGT. PROCESS 2.6 MANAGE BA PERFORMANCE BUSINESS ANALYSIS PLAN(S) BA PROCESS ASSETS 2.2 REQUIREMENTS MANAGEMENT PLAN ORGANIZATIONAL PROCESS ASSETS STAKEHOLDER LIST, ROLES, AND RESPONSIBILITIES
Business Analysis Planning & Monitoring INPUTS TRIGGER OUTPUTS TASKS * 5.1 2.1 2.4 2.6 BUSINESS ANALYSIS PERFORMANCE METRICS BUSINESS NEED 2.1 PLAN BUSINESS ANALYSIS APPROACH 2.2 CONDUCT STAKEHOLDER ANALYSIS BUSINESS ANALYSIS APPROACH BA COMMUNICATIONS PLAN BA PERFORMANCE ASSESSMENT 2.3 PLAN BA ACTIVITIES 2.4 PLAN BA COMMUNICATION 2.3 2.6 2.5 ENTERPRISE ARCHITECTURE EXPERT JUDGMENT 2.5 PLAN REQ TS MGT. PROCESS 2.6 MANAGE BA PERFORMANCE BUSINESS ANALYSIS PLAN(S) BA PROCESS ASSETS 2.2 REQUIREMENTS MANAGEMENT PLAN ORGANIZATIONAL PROCESS ASSETS STAKEHOLDER LIST, ROLES, AND RESPONSIBILITIES
Business Analysis Planning & Monitoring INPUTS FIRST DECISION OUTPUTS TASKS * 5.1 2.1 2.4 2.6 BUSINESS ANALYSIS PERFORMANCE METRICS BUSINESS NEED 2.1 PLAN BUSINESS ANALYSIS APPROACH 2.2 CONDUCT STAKEHOLDER ANALYSIS BUSINESS ANALYSIS APPROACH BA COMMUNICATIONS PLAN BA PERFORMANCE ASSESSMENT 2.3 PLAN BA ACTIVITIES 2.4 PLAN BA COMMUNICATION 2.3 2.6 2.5 ENTERPRISE ARCHITECTURE EXPERT JUDGMENT 2.5 PLAN REQ TS MGT. PROCESS 2.6 MANAGE BA PERFORMANCE BUSINESS ANALYSIS PLAN(S) BA PROCESS ASSETS 2.2 REQUIREMENTS MANAGEMENT PLAN ORGANIZATIONAL PROCESS ASSETS STAKEHOLDER LIST, ROLES, AND RESPONSIBILITIES
2.1 BA Approach: Plan-driven or Change-driven? Consideration Plan-Driven Change-Driven General Timing of BA Work Ensure solution is fully developed before implementation Maximize control, minimize risk Front-loaded or during a specific phase (requirements) Multiple, short iterations Trade uncertainty for speed Begins early, then updated during subsequent iterations Formality and Level of Detail of BA Deliverables Requirements Prioritization Significant formality, detail Goes through formal approval processes Requirements gathered and prioritized all at once Often limited to prioritized requirements list May also include models Usually approved through team interaction Small-scope iterations puts greater pressure on effective methods to prioritize
2.1 BA Approach: Plan-driven or Change-driven? Consideration Plan-Driven Change-Driven Change Management BA Planning Process Communication With Stakeholders Limited change (only when genuinely necessary and justified) with formal change management processes Changes are mini projects Usually integrated into larger project plan Formal communications methods Usually in writing Usually requires signatory approvals Archived Part of the iterative process of development (business as usual) Not so much a change as a reduction in uncertainty (so welcomed and expected) Usually integrated into larger project plan Informal communications methods (e.g. Scrum meetings) Official documentation still in writing Often official documentation is after implementation
2.1 BA Approach: Plan-driven or Change-driven? Consideration Plan-Driven Change-Driven Requirements Analysis and Management Tools Tools shape techniques, notation, requirements packaging Tools shape techniques, notation, requirements packaging Project Complexity Many factors Many factors
2.1 BA Approach: Plan-driven or Change-driven? THE APPROACH CONTINUUM Plan-Driven Minimize up-front uncertainty Ensuring solution fully defined before implementation Maximize control and minimize risk Requirements can effectively be defined in advance of implementation Risk of incorrect implementation is unacceptably high Managing stakeholder interactions present significant challenges. Authority to approve requirements typically rests with selected stakeholders and project sponsor. Project sponsor has final authority to approve solution requirements (but commonly insists other stakeholders grant approval before sponsor will) Waterfall methods of software development Business process re-engineering initiatives are typical examples of plan-driven approaches. Focus Preferred When Characteristics Examples Change-Driven Rapid delivery of business value in short iterations in return for acceptance of higher degree of uncertainty regarding overall delivery of the solution Taking an exploratory approach to finding the best solution Incremental improvement to an existing system Authority to approve requirements usually rests with a single individual, who is an active participant in daily team activities Others may advise or be informed, but may not withhold consent Approval process must be completed within a strict time limit Agile methods of software development Continuous improvement projects
Presentation Guidelines 5 minutes Content: What is your project? What is the problem you are trying to solve? Which approach are you using? What is your plan (estimate of the work involved, functional decomposition of the work, and risk analysis)? Who are your stakeholders? What are the requirements you have identified? What is your recommendation and why? (Decision Analysis and Business Case) And implied in them all: Why those choices and not others?
FUNCTIONAL DECOMPOSITION What is it? Why would you want it? How would you use it?
Functional Decomposition Function Sub- function Sub-function Process Process Process Process Process Identifies high-level elements of an organization, process, or solution, or project. Breaks those elements down into smaller pieces (subfunctions, processes, components, etc.) Goal: Separate the problem into smaller components so each can be analyzed, developed, or managed as independently as possible.
Types of Functional Decomposition Organizations Org Charts Requirements Document Trees Requirements Trees Problems/ Solutions Fishbone Diagrams Processes (repeatable work) Process Breakdown Structures Projects (one-time work) Work Breakdown Structure (WBS) Often depicted as a tree diagram Decomposition = simply taking a large thing and breaking it down into the smallest possible independent elements, usually for the purpose of management or problem solving.
Work Breakdown Structures Decomposes project scope into smaller and smaller pieces, creating a hierarchy of work Becomes the primary structure of a project plan Ways to break it down: By deliverable By project phase, iteration, increment, or release Boiler-plate
Building the Plan 1. Understand the project type Feasibility study Process improvement Organizational change Software development Etc. 2. Understand the deliverables 3. Identify the activities Describe: Verb + Noun Unique numbering 4. Note assumptions 5. Identify dependencies 6. Indicate major milestones WBS
Advantages and Disadvantages Advantages: Creates a conceptual model of the work Provides all stakeholders with a consistent view of the work Assists in estimating Smaller subsets More readily understandable Disadvantages: No way to be certain that all components have been captured Worth re-typing:! Decomposing a problem without fully understanding the relationship between pieces of the problem may create an inappropriate structure that impedes analysis. BABOK, 9.12.4.2
STAKEHOLDER ANALYSIS What is a stakeholder?
Executive Sponsor Business Analyst Project Manager Developer Tester Trainer Application Architect Data Modeler Database Analyst (DBA) Infrastructure Analyst Business Architect Solution Owner End User Subject Matter Expert Other Stakeholders??? Examples of Stakeholders
Four types of Stakeholder roles: R-A-C-I R = Responsible: Does the work A = Accountable/Approves: Is the decision maker (only one) C = Consulted: Must be consulted prior to the work and gives input I = Informed: Means that they must be notified by the outcome. Exercise: complete the table, using the R-A-C-I convention.
Types of Stakeholders and the Roles they Play Role Determine Requirements Select Solution Manage Implementation Executive Sponsor Business Analyst Project Manager Developer Tester Trainer Application Architect Data Modeler Database Analyst (DBA) Infrastructure Analyst Business Architect Solution Owner End User Subject Matter Expert Other Stakeholders
ESTIMATING
Estimates are Not Contracts Estimate Contract + Can reduce risk of uncertainty Shows due diligence Enables accountability Makes it real (people can begin) - Too much information may overwhelm stakeholders (actually driving bad decisions) May result in sticker shock Time consuming May force people into a contract they can t meet or don t support
Estimates are Not Contracts: The Polarity Estimate Contract + Can reduce risk of uncertainty Shows due diligence Enables accountability Makes it real (people can begin) - Too much information may overwhelm stakeholders (actually driving bad decisions) May result in sticker shock Time consuming May force people into a contract they can t meet or don t support
Estimates are Not Contracts: The Polarity Estimate Contract + Can reduce risk of uncertainty Shows due diligence Enables accountability Makes it real (people can begin) - Too much information may overwhelm stakeholders (actually driving bad decisions) May result in sticker shock Time consuming May force people into a contract they can t meet or don t support
Basis Bases for Estimation Description Analogous Estimation Use of a similar project as the basis for developing estimates for the current project. Used to develop ROM estimate, often at beginning of project. Use when little information is known. Parametric Estimation The use of parameters, multiplied by the number of hours. Use when Enough history is available to be used as a basis for comparison. BA has enough information to know which parameters to use. Bottom-up Estimation BA collects deliverables, activities, tasks, and estimates from all the involved stakeholders and rolls them up to get a total for all the activities and tasks. Rolling Wave 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. Three-point Estimation Uses scenarios for: The most optimistic estimate (best-case scenario) The most pessimistic estimate (worst-case scenario) The most likely estimate. Historic Analysis Uses history as a basis for estimating Similar to analogous, but used not only for the top-down estimate, but for the detailed tasks as well. Requires project records for data. Expert Judgment Relies on the expertise of those who have performed the work in the past. Delphi Estimation Uses a combination of expert judgment and history. Develop individual estimates, share them with experts, and discuss until consensus is reached. Use the average (or some other calculus).
Building the Plan for your Project 1. Understand the project type Feasibility study Process improvement Organizational change Software development Etc. 2. Understand the deliverables 3. Identify the activities Describe: Verb + Noun Unique numbering 4. Note assumptions 5. Identify dependencies 6. Indicate major milestones WBS
Project Planning Template Project Type: Project Approach: Phase Activity Start Date Stop Date Effort Estimate (hours, days, headcount, etc.) Cost Estimate ($$) Define the Problem or Opportunity Assess the Current Situation Plan the Work/ Begin Business Case Elicit Requirements Develop the Solution/ Improvement Sell the Solution Implement the Solution Stabilize Improve
Project Planning Template Project Type: Project Approach: Phase Activity Start Date Stop Date Effort Estimate (hours, days, headcount, etc.) Cost Estimate ($$)
LESSONS 4 and 5 (January 24, 2015): Requirements Management & Communication and Elicitation How will I manage the requirement and ensure solution fit? What are the REAL requirements? Lesson 4 Reading: Read BABOK ch. 4, pp. 63-80 Scan BABOK ch. 9 as directed in Ch 4 Lesson 5 Reading: Study BABOK ch. 3 pp. 53-62 Scan BABOK ch. 9 as directed in ch. 3 Read Block ch. 11, pp. 175-182; ch. 13, pp. 201-216 Quiz: Take and grade the Lesson 4 and 5 Quizzes and bring your questions to class. Homework: Create your project plan (use of the form from class is optional use whatever form or tool works best for you), and post to the Catalyst Site in the Assignment Dropbox. Note If your homework is posted by 3:00 PM on Friday, 1/23, we will provide feedback that night.