Downloaded 1,242 times
Uploaded byKathy Vezina
BABOK Chapter 2 - Business Analysis Planning and Monitoring
The document discusses planning for business analysis activities on projects. It addresses: 1. Planning the overall business analysis approach depending on the project type. 2. Conducting stakeholder analysis to understand who is involved and how. 3. Planning the specific business analysis activities, deliverables, and schedule. 4. Planning communications to set expectations around business analysis work and information sharing. 5. Planning the requirements management process around repositories, traceability, and change control. 6. Planning performance measurement to ensure the business analysis work is on track.
More Related Content
Similar to BABOK Chapter 2 - Business Analysis Planning and Monitoring
BABOK Chapter 2 - Business Analysis Planning and Monitoring
- 1. The Business Analyst‟s Business Analysis Campbell Ferenbach October 18, 2011
- 2. Project BA work is a business process with: ◦ Inputs ◦ Outputs ◦ Tasks ◦ Stakeholders ◦ Actors As-Is is our toolbox and methodology To-be changes with each project
- 3. Each project, release and sprint needs: ◦ Elicitation ◦ Analysis ◦ BPR ◦ Actors/ Stakeholders ◦ Documentation ◦ Performance Measurements
- 4. Each project, release and sprint needs: ◦ Elicitation FOR THE BA, this What‟s in this project? is like “What is the business domain?” Where are the Stakeholders? How are we delivering it? SOUNDS LIKE When are we due? some NFRs & technical constraints on the business processes…
- 5. Each project, release and sprint needs: ◦ Elicitation ◦ Analysis What outputs are the „user‟/BA needing to produce to communicate with the project teams? Consider practical needs, plus project and client standards More What data do they already have? NFRs! What inputs do they receive from outside? SOUNDS LIKE communications and data flows…
- 6. Each project, release and sprint needs: Works for ◦ Elicitation „No As-Is‟ too! ◦ Analysis ◦ BPR Assuming our BA/user has mature, regular processes that they know how to follow… How are those processes going to be tailored to fit the specifics of the „new world‟ (this project!)? Who needs to know how the process is going to work? Participants, suppliers, consumers, auditors….
- 7. Each project, release and sprint needs: ◦ Elicitation ◦ Analysis ◦ BPR ◦ Actors / Stakeholders Who are the users/BAs and other stakeholders? Where are the constraints and bottlenecks? are more or different resources needed? Are some fixed resources creating constraints on others? Will training be needed?
- 8. Each project, release and sprint needs: ◦ Elicitation ◦ Analysis ◦ BPR ◦ Actors / Stakeholders ◦ Documentation Who needs to know about all this BA process and data and rules and stuff? How do we communicate with them? Who needs to validate that these outputs will be right for the business (this project!)
- 9. Each project, release and sprint needs: ◦ Elicitation ◦ Analysis ◦ BPR ◦ Actors / Stakeholders ◦ Documentation ◦ Performance Measurements How will we know if the process has been correctly engineered and solutioned? Who wants to know how it‟s running? Why? What measures are useful and practical? measureable, reportable, timely and actionable
- 12. Start with the Type of Project… ◦ Feasibility studies ◦ Process improvement ◦ Organizational change ◦ New software development (in-house) ◦ Outsourced new software development ◦ Software maintenance or enhancement ◦ Software package selection Methodology affects most planning elements Pre-Set vs Open to Tailoring? Plan-driven vs Change-driven?
- 13. 2.1.4. Elements: ◦ .1 Timing ◦ .2 Formality & Level of Detail ◦ .3 Prioritization ◦ .4 Change Management ◦ .5 BA Planning Process ◦ .6 Communication with Stakeholders ◦ .7 Analysis and Management Tools ◦ .8 Project Complexity
- 14. The basics: ◦ Who‟s out there? ◦ What do they do? ◦ How are they involved? Attitudes Influence & Authority
- 16. 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.
- 17. The Elements: ◦ Where are Stakeholders? Co-located vs Dispersed? ◦ Type of project/initiative? ◦ Deliverables Begin with the end(s) in mind… ◦ Activities Needed What actions & tasks are in the process? Is a WBS just a formatted process flow? Details: assumptions, dependencies, milestones ◦ Organize the Activities by deliverable, phases/iterations, other?
- 18. “proposed structure and schedule for communications regarding business analysis activities” “setting expectations for business analysis work, meetings, walkthroughs, and other communications.” “how best to receive, distribute, access, update, and escalate information from project stakeholders, and determining how best to communicate with each stakeholder”
- 19. Plan for: ◦ what needs to be communicated ◦ who is the appropriate audience ◦ what is the appropriate delivery method ◦ and when the communication should occur.
- 20. Consider needs and constraints: ◦ Physical locations, time zones ◦ Communication approach for the stakeholder. ◦ What types of communications will be required ◦ What types of requirements will be elicited and how best to elicit them. ◦ How best to communicate requirements conclusions/packages. ◦ Time and resource availability constraints. For more info, check sections 4.4, 4.5 & 8.4
- 21. Purpose: “approve requirements for implementation” “manage changes to the solution or requirements scope”
- 22. Repository(ies) ◦ WIP, in review, approved ◦ Whiteboards LAN folders Sharepoint big tools Traceability – if & how ◦ Adds overhead ◦ Manages risk if correct and consistent (see Sect 4.2) Requirements Attributes ◦ Meta-data: unique ID, status, ownership, priority, … Prioritization ◦ Formality, frequency, techniques, participants
- 23. Change Management ◦ Approach depends on methodology & culture Change-driven vs Plan-driven Large-scale, Contractual vs small, informal ◦ Consider: Process for requests – create, assess, approve Participants: impact assessment & approval Impact analysis: who, how detailed, consolidation Prioritization and integration into scope Tailoring the Reqmts Mgmt process
- 24. Which metrics and how to capture, assess and report on them? ◦ Approach depends on methodology & project type Change-driven vs Plan-driven Large-scale, high risk vs small, low-impact Consider: ◦ How will we know we‟re on or off track? ◦ KPIs, KSFs,… Quality, Speed, Efficiency what matters? what can be measured? ◦ How to report and to whom ◦ Risk of missing targets vs Costs of tracking & monitoring
- 25. Project BA work is a business process with: ◦ Inputs ◦ Outputs ◦ Tasks ◦ Stakeholders ◦ Actors As-Is is our toolbox and methodology To-be changes with each project
- 26. Each project, release and sprint needs: ◦ Elicitation ◦ Analysis ◦ BPR ◦ Actors/ Stakeholders ◦ Documentation ◦ Performance Measurements
- 27. 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 Requirements Management Process 2.6 Manage Business Analysis Performance
- 28. Asks you tobe a: Business Analyst to the Business Analysts
Editor's Notes
- #2 Intro:Hi, thank you for introGary mentioned that this was one of the areas that a lot of people asked to hear more about, so we’re going to take a look at it today.Chapter 2 has about 35 pages of text with a few diagrams and reading through them should be one part of learning about it. Sooner or later, you really should get into the details! But - effective learning usually involves more than just sitting alone reading.In the next half hour we’re going to take a preparing sort of step towards getting our minds wrapped around this area. I’ll try to give you a perspective you can use to approach the material and a way to relate it to things you already know. I’ll also survey the Chapter sections to give you a sense of what’s where, how they relate and how you might approach it.I won’t promise expertise in half an hour, but after this you should know enough to get through a networking reception at BAWorld or an elevator ride with a curious executive!
- #3 But we can look at the Project as a sort of business entity – it has business objectives, stakeholders, user groups (or project teams) and so on. Within the project we have the BA Team – a user group that receives information inputs from supplier teams, processes that information and delivers outputs to customer teams.So, holding that image, the BA asked to look at the Planning and Monitoring knowledge area is being asked to work out the inputs, outputs, tasks, stakeholders, actors and so on for the BA team to do their part in the upcoming project.
- #4 Elicitation What’s in this project? – scope & scale? COTS/Custom? Web-based/SOA/whatnot? Enterprise/ad hoc? Where are the Stakeholders? FOR THE BA, this is like “What is the business domain?” How are we delivering it? Waterfall, agile, local or distributed teams, TBD? SOUNDS LIKE some Non-Functional Requirements and technical constraints on the business processes… When are we due? Do we have target dates, other constraints, TBD? Keep going with budget, etc.Analysis What outputs are the ‘user’/BA needing to produce to communicate with these teams? Practical needs, plus project and client standards (more NFRs!) What inputs do they already have? – info, tools, templates And what inputs do they have to receive from outside (e.g. from stakeholders, other project teams) SOUNDS LIKE communications and data flows…BPR Assuming our BA/user has mature, regular processes that they know how to follow…. How are those process going to be tailored to fit the specifics of new world (this project!)? Who needs to know how the process is going to work? – participants, suppliers, consumers, auditors….Resources/ Stakeholders Who are the users/BAs and other stakeholders? Where are the constraints and bottlenecks – are more or different resources needed? Are some fixed resources creating constraints on others?Documentation Who needs to know about all this BA process and data and rules and stuff? participants, suppliers, consumers, auditors…. How do we communicate with them? Process maps, gantt charts, Use Cases, User Stories, Models, etc. Who needs to validate that these outputs will be right for the business (this project!)Performance Measurements How will we know if the process has been correctly engineered and solutioned? Who wants to know how it’s running? Why? What measures are useful and practical? – measureable, reportable, timely and actionable
- #5 Elicitation What’s in this project? – scope & scale? COTS/Custom? Web-based/SOA/whatnot? Enterprise/ad hoc? Where are the Stakeholders? FOR THE BA, this is like “What is the business domain?” How are we delivering it? Waterfall, agile, local or distributed teams, TBD? SOUNDS LIKE some Non-Functional Requirements and technical constraints on the business processes… When are we due? Do we have target dates, other constraints, TBD? Keep going with budget, etc.
- #6 Analysis What outputs are the ‘user’/BA needing to produce to communicate with these teams? Practical needs, plus project and client standards (more NFRs!) What inputs do they already have? – info, tools, templates And what inputs do they have to receive from outside (e.g. from stakeholders, other project teams) SOUNDS LIKE communications and data flows…
- #7 BPR Assuming our BA/user has mature, regular processes that they know how to follow…. How are those processes going to be tailored to fit the specifics of ‘new world’ (this project!)? Who needs to know how the process is going to work? – participants, suppliers, consumers, auditors….
- #8 Actors / Stakeholders Who are the users/BAs and other stakeholders? Where are the constraints and bottlenecks – are more or different resources needed? Are some fixed resources creating constraints on others? Will training be needed?
- #9 Documentation Who needs to know about all this BA process and data and rules and stuff? participants, suppliers, consumers, auditors…. How do we communicate with them? Process maps, gantt charts, Use Cases, User Stories, Models, etc. Who needs to validate that these outputs will be right for the business (this project!)
- #10 Performance Measurements How will we know if the process has been correctly engineered and solutioned? Who wants to know how it’s running? Why? What measures are useful and practical? – measureable, reportable, timely and actionable
- #11 A key point here, and it applies to the other BOK sections too: these are not a set of sequential steps or phases. Each of them informs the others and so there is fair bit of integrated and iterative effort done to get them all done. Although we can say that you tend to do more of the top items at the beginning and more of the latter items towards the end.
- #12 Now these are the inputs and outputs to the Planning & Monitoring activity. The inputs are examples of what you might expect to have available before the project really starts. Depending on the organizations involved, these may be well documented or at least well known. Or you may have to go exploring! You can think of the outputs as the Requirements Package that describes how the BA area is going to operate in the “business” that is the Project. Here we see…. << describe items >>In between we have the Plan steps where we essentially analyze and document the To-Be Business Analysis area. A couple of items strain my metaphor….Item 2.2, Conduct Stakeholder Analysis – there you’re actually starting into the real project work by looking at who the players are in the real, paying client’s world. But keep in mind that as the BA Planner, you also need to know about your internal project stakeholders. Developers and testers aren’t part of the client’s business, but they are the BA’s customers and they have a stake in what the BA produces.Task 2.6 Manage BA Performance – covers both planning how you’re going manage and actually starting to do it. Obviously the actually measuring and analysing of performance will happen more as the project gets rolling.
- #14 .1 Timing: Most BA work to be done up front or iteratively?.2 Formality & Level of Detail:What deliverables are needed?What do they look like?See Chapter 4: Requirements Management and Communication for examples.Think about your stakeholders – what they need and what they can consume effectively.3 Prioritization Starts up front in Scoping and gets revisited often in more Agile projects. There are techniques in chapter 6.1.4 Change Management Think about the options between formal processes for big-impact contract changes and a way of tracking and communicating the decisions made when ‘grooming’ a product backlog It’s about balancing efficiency with keeping the scope from wandering off on its own…..5 BA Planning Process How will you plan the team’s activities and how will that plan tie into the larger project plan?.6 Communication with Stakeholders Can include traditional deliverables as well as briefings, ways of capturing feedback and so on.7 Tools Whether this is asking for what you need or finding out what’s available, your tools will affect your techniques and estimates..8 Project Complexity This just lists a few of the factors that will drive your estimates and choices of techniques and tools.number of stakeholders▶▶number of business areas affected▶▶number of business systems affected▶▶amount and nature of risk▶▶uniqueness of requirements▶▶number of technical resources required
- #15 Attitude towards:The business goals, objectives, and solution approach:▶▶Attitude towards business analysis:▶▶Attitude towards collaboration: ▶▶Attitude towards the sponsor:Influence and Authority:Influence on the projectInfluence in the organization Influence needed for the good of the projectInfluence with other stakeholders Who can approve, inspect, veto various deliverables and decisions?
- #16 Stakeholder List, Roles, and Responsibilities: This may include information such as:List of required roles▶▶Names and titles of stakeholders▶▶Category of stakeholder▶▶Location of stakeholders▶▶Special needs▶▶Number of individuals in this stakeholder role▶▶Description of stakeholder influence and interest▶▶Documentation of stakeholder authority levels
- #17 Identify business analysis deliverables - what are the outputs of our process?Determine the scope of work for the business analysis activities - of course the business domain to be covered, but also parts will the BA do vs what will the leverage from earlier work or maybe will get done by the users, architects or designers - the other side of this is whether you’re going to do just the next sprint, the next release or the whole solution. And are you doing high-level, detailed and so on.Determine which activities the business analyst will perform and when - now you’ll break it down to tasks and steps, with sequences and dependencies - is that PM work or BPR? Tomato / Tomahtoh…Develop estimates for business analysis work. - same again…
- #18 The Elements:Where are Stakeholders? Collocated vs Dispersed? Type of project/initiative?DeliverablesBegin with the end in mind…Keep interim deliverables in mind – interviews, draft reviews and such aren’t the final output, but they won’t happen if they’re not in the process… Check ahead for more: 2.4 Plan BA Communication, 2.5 Plan Reqmts Management Process, 2.6 Manage BA PerformanceActivities NeededWhat actions & tasks are needed? - look at your methodologies, experience, functional decomposition… - and again, Check ahead in 2.4, 2.5 & 2.6 for moreIs a WBS just a formatted process flow?Dependencies are all about the logical flow of the processMilestones may tie into your logical decision point (and PM’s like to see them)Organize the Activities Whatever makes sense or is consistent with the project approach.
- #21 Physical location/time zone of the stakeholders.Communication approach for the stakeholder. detail-orientedvs concepts-only, perspective (functional vs financial) Cultures of the organization and the individuals Contractual and authority environmentsWhat types of communications will be required e.g. status, anomalies, issues and their resolution, risks, meeting results, action items, etc.Formal for some parts and informal for other parts?What types of requirements will be elicited e.g. business vs technical; high level vs. detailed) and how best to elicit them (see the Elicitation KA for options).How best to communicate requirements conclusions/packages, including authority level (signoff authority, veto authority, or review only).Time and resource availability constraints.See Prepare Requirements Package (4.4) and Communicate Requirements (4.5) for additional information. Communication techniques are described in Communication Skills (8.4
- #25 Consider also Short-term project metrics to help meet milestones and ensure quality in deliverables Long-term BA metrics to develop efficiency, measure benefits of training, etc.Risk – don’t track just because you can.- approximate indicators may be enough to flag for follow-up without having to be detailed, super-precise processesTechniques include interviews, surveys, PMPRs, Root cause analysis and lot’s more