Knowledge areas BABOK Guide v3, chapter 3
Business Analysis Planning and Monitoring
In short This knowledge area covers how you organize business analysis on an initiative: which approach you take, how you work with stakeholders, who decides what, where analysis information lives, and how you check and improve your own work. Its outputs shape every other knowledge area.
Based on: IIBA, BABOK® Guide v3, chapter 3 “Business Analysis Planning and Monitoring”; business analysis training materials (task reference cards and course slides).
On this page
Purpose#
Before you elicit a single requirement, you need a plan for the analysis work itself. The BABOK® Guide treats this as a separate knowledge area because its results (approaches and assessments) are inputs to the tasks in all the others.
Seen through the Business Analysis Core Concept Model, planning and monitoring is where you decide how changes to analysis deliverables are requested and approved, choose an approach that fits the need, analyze stakeholders, make sure the analysis activities themselves deliver value, and understand enough of the context to make these choices well.
Tasks#
The BABOK Guide defines five tasks.
3.1 Plan Business Analysis Approach. You decide how analysis will be done on this initiative: predictive, adaptive or a mix; which activities and deliverables you will produce; when they happen; and how formal the documentation needs to be. You produce: a business analysis approach.
3.2 Plan Stakeholder Engagement. You work out which stakeholders matter for this change, what you need from each of them, what they need from you, and how you will collaborate (meetings, channels, frequency). You produce: a stakeholder engagement approach.
3.3 Plan Business Analysis Governance. You define how decisions about requirements and designs get made: who can request changes, who prioritizes, who approves, and how analysis risks and resources are handled. You produce: a governance approach.
3.4 Plan Business Analysis Information Management. You decide how requirements, designs and other analysis information are recorded, stored, linked and kept usable over time, including which attributes you track and how much traceability you need. You produce: an information management approach.
3.5 Identify Business Analysis Performance Improvements. You monitor how the analysis work is going against what was committed, and find ways to do it better. You produce: a business analysis performance assessment.
Key inputs and outputs#
The tasks form a chain, and the last one feeds back into the first.
| Task | What goes in (simplified) | What comes out |
|---|---|---|
| 3.1 Approach | Lessons from past analysis performance; organizational policies and standards | Business analysis approach |
| 3.2 Stakeholder engagement | The approach; the change strategy and current-state picture from strategy analysis | Stakeholder engagement approach |
| 3.3 Governance | The approach; the engagement approach | Governance approach |
| 3.4 Information management | The approach; the governance approach | Information management approach |
| 3.5 Performance improvements | The approach; performance objectives set outside the initiative | Performance assessment (feeds the next round of 3.1) |
Techniques you will use most#
- Brainstorming and Workshops: shape the approach together with the team.
- Estimation and Functional Decomposition: size the analysis work by breaking it into pieces.
- Business Cases: align the depth of analysis with what is at stake.
- Interviews: learn what sponsors and key stakeholders expect from the analysis.
- Stakeholder List, Map, or Personas and Organizational Modelling: find stakeholders and understand authority lines.
- Item Tracking and Reviews: set up how issues and approvals are handled.
- Lessons Learned: reuse what worked in earlier initiatives.
- Metrics and KPIs and Root Cause Analysis: measure your own performance and fix recurring problems.
Practical tips#
Choose the approach on purpose#
The training materials contrast two ends of a scale:
- Predictive approach. You reduce uncertainty up front and define the solution before building starts. It gives the most control and the least risk of a wrong build. Prefer it when requirements can be known in advance, when a mistake would be very costly (legal, safety, money), or when stakeholders will be hard to reach later. Documentation tends to be formal and template-based, and work is done within defined phases.
- Adaptive approach. You accept that the final solution is uncertain and deliver value in short iterations, learning from feedback. Prefer it when you are exploring for a solution or improving something step by step. Information is gathered through close team collaboration rather than formal documents.
You can combine both in one initiative, and a change in the business environment can force you to re-plan. For example, at The Workshop (a fictional chain of 12 bike-repair shops), the payment and customer-data parts of online booking could be handled predictively, because the rules are known and errors are costly. The booking screens and notification messages could be handled adaptively, because nobody knows yet what customers will find easiest.
Size the effort with complexity and risk factors#
The training materials list factors worth checking before you commit to a plan:
- Complexity: size of the change, number of stakeholders and analysts, number of business areas and systems affected, geographic and cultural spread, technical complexity.
- Risk: the analyst’s experience and domain knowledge, how well stakeholders can express their needs, their attitude to the change, how much time they can give, frameworks imposed in advance, and organizational culture.
Decide which requirement attributes you will track#
For task 3.4, agree early which attributes each requirement carries. Commonly used ones: unique ID, author, owner, source, priority, urgency, complexity, stability, status and risks. Track only what someone will actually use; every extra attribute is maintenance work.
Measure your own analysis work#
For task 3.5, the training materials suggest indicators such as stakeholder satisfaction with the analysis, the share of rework caused by requirements, the number of requirements missed, the stability of sprint scope, and defect counts. When you act on the results, label each action as preventive, corrective or improvement, so you can see whether you are fixing symptoms or causes.
Keep the plan light and alive#
A plan for analysis is a working agreement, not a deliverable to be signed and forgotten. Revisit it when the scope, team or business context changes, and after each major review of how the analysis is going.
Sources and further reading#
- IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Chapter 3 “Business Analysis Planning and Monitoring”.
- Business analysis training materials (practice examples and templates): task reference cards for chapter 3; course slides on planning and monitoring (predictive and adaptive approaches, complexity and risk factors, requirement attributes, analysis KPIs).