Plan Business Analysis Approach is BABOK Guide v3 task 3.1: the business analyst decides how business analysis work will be done on one initiative. It has one input (Needs), six elements, and one output, the business analysis approach. It sits in Business Analysis Planning and Monitoring (BAPM), which carries 14% of the 120-question CBAP exam, so expect several scenario questions on it.
This article is part two of a ten-part series. For the whole knowledge area, start with the overview of Business Analysis Planning and Monitoring for CBAP.
What the plan business analysis approach task is
The business analysis approach is the agreed description of how, when and how formally business analysis work will be done for a given change. It is not a requirements document and not a project plan. It is a plan for the analysis itself.
BABOK v3 section 3.1 states the purpose in one line: define a fitting method for the business analysis activities. In practice that means answering five questions before you start eliciting:
- Will we plan the work up front or in short cycles?
- How formal and detailed must our deliverables be?
- Which business analysis activities will we do, and in what order?
- When will each piece of analysis happen?
- What makes this change complex or risky, and who must agree to the approach?
Why it matters on the CBAP exam
Task 3.1 is the first task in the first knowledge area, and its output feeds every other BAPM task. On the exam it shows up in scenarios where a new analyst joins a project, a regulator or contract changes the rules, or stakeholders disagree on how much documentation they want.
| Fact | Value |
|---|---|
| Exam | Certified Business Analysis Professional (CBAP), International Institute of Business Analysis (IIBA) |
| Format | 120 case-study and scenario-based multiple-choice questions, 210 minutes |
| BAPM weight | 14% of the exam |
| Basis | BABOK Guide v3 |
| Exam fee | $505, or $350 for IIBA members (application fee $145) |
Last verified: October 2026, from the IIBA CBAP page.
IIBA's own sample question for BAPM shows the style: a senior stakeholder disagrees with the project objectives, and the correct response is to analyse the risk rather than push ahead. Expect the same pattern for task 3.1: the right answer usually adapts the approach to context instead of applying a fixed method.
Inputs, guidelines, techniques and output
Task 3.1 has a short list of inputs and a long list of techniques. The table summarises it, checked against the official IIBA task card and a second public study guide.
| Part | Content |
|---|---|
| Input | Needs |
| Guidelines and tools | Business analysis performance assessment, business policies, expert judgment, methodologies and frameworks, stakeholder engagement approach |
| Key stakeholders | Domain subject matter expert, project manager, regulator, sponsor |
| Output | Business analysis approach |
| Used by | 3.2 Plan Stakeholder Engagement, 3.3 Plan Business Analysis Governance, 3.4 Plan Business Analysis Information Management, 3.5 Identify Business Analysis Performance Improvements |
The techniques list has 15 entries: brainstorming, business cases, document analysis, estimation, financial analysis, functional decomposition, interviews, item tracking, lessons learned, process modelling, reviews, risk analysis and management, scope modelling, survey or questionnaire, and workshops. You do not need to memorise all of them, but you should recognise that estimation and functional decomposition break the work down, while risk analysis and lessons learned shape it. Our map of BABOK techniques by knowledge area shows where else each one appears.
Two points trip candidates. First, the stakeholder engagement approach (the output of 3.2) is a guideline for 3.1, while the business analysis approach is an input to 3.2. The tasks loop; BABOK does not run them strictly in sequence. Second, the performance assessment from 3.5 on earlier work also feeds 3.1, so lessons from the last project change the next approach.
How to plan business analysis approach: the six elements
Each element of section 3.1.4 is a decision you record in the approach. Here they are as steps.
1. Planning approach
Choose where the work sits between predictive (most planning done early) and adaptive (planning done in short cycles as the solution emerges). Most initiatives mix both. The organisation's methodology often sets the frame, and you tailor inside it. The full comparison comes later in this series, so keep it simple here: pick the approach that fits how stable the need is and how much change the team can absorb.
2. Formality and level of detail of deliverables
Decide how formal the business analysis deliverables must be. Formality usually rises when the change is high risk, regulated, under contract, spread across locations, outsourced, or expected to be maintained for years. Adaptive work tends to use lighter, just-in-time documentation; predictive work tends to use full specifications signed off in stages.
3. Business analysis activities
List the activities you will perform and the deliverables each produces. Break large pieces into tasks small enough to estimate. A guide to estimation and relative sizing helps here, because the same techniques work for analysis tasks as for features.
4. Timing of business analysis work
Decide when analysis happens. In a predictive setting much of it happens before build starts. In an adaptive setting it runs through the whole life cycle, a little ahead of each iteration. Timing also depends on stakeholder availability, which is why 3.2 and 3.1 feed each other.
5. Complexity and risk
Assess what could make the analysis harder: size of the change, number of business areas and systems, geographic or cultural spread, technical complexity, unfamiliar stakeholders, or stakeholders who resist the change. Higher complexity usually means more formality, more checkpoints and more contingency time.
6. Acceptance
Get key stakeholders to review and agree to the approach. In some organisations that is a formal sign-off; in others a short review meeting is enough. Acceptance matters because the approach sets expectations about effort, deliverables and stakeholder time.
Worked example: a claims-intake change at an insurer
A mid-size insurer wants to replace its paper claims-intake form with an online form connected to a vendor's software-as-a-service claims system. You are the lead business analyst.
Needs (input). Claims take 9 days to register; the target is 2 days. The business case estimates savings from fewer manual touches.
Planning approach. The vendor delivers in two-week sprints, but integration with the policy system and a regulatory notice to the supervisor must be fixed in advance. You choose a hybrid: predictive for the integration and regulatory parts, adaptive for the form screens.
Formality. The regulator expects an audit trail, so business rules and data mappings get formal specifications with sign-off. Screen requirements stay as user stories with acceptance criteria.
Activities and timing. Week 1-2: current-state process model and document analysis of the paper form. Week 3: workshop to agree scope. From week 4: backlog refinement one sprint ahead of the vendor team. Data-mapping specification complete before integration build in week 6.
Complexity and risk. Three claim types, two legacy systems, a vendor in another time zone, and claims handlers worried about job changes. You add a risk log, a fortnightly review with the vendor, and extra elicitation time with handlers.
Acceptance. The sponsor, project manager and compliance officer review a two-page approach and sign it. You note that the approach will be revisited after the first release.
The output is short: one or two pages, plus a list of deliverables and dates. That is normal. The approach is a decision record, not a thick document.
What practitioners say about planning the approach
Practitioners agree on one point: scale the approach to the context, and revisit it.
- Formality follows context. In an IIBA guide on planning, practitioner Giorgos Sioutzos writes that a public-sector or regulated client needs more formality than an R&D start-up, and that the approach should end with formal sign-off and a review of how it worked (IIBA, 9 Steps to Planning).
- Only analyse what changes the outcome. Howard Podeswa argues on Modern Analyst that documentation should scale with life cycle, project size and build-versus-buy, with effort aimed at high-risk, business-specific requirements: "If it isn't going to make a difference to the outcome, don't do it." (Modern Analyst).
- Approaches change mid-project. Laura Brandenburg describes a consolidation across five organisations where the team needed shared templates, agreed requirement granularity and a tools decision (Excel, then SharePoint, then DOORS), and the approach was revised several times (Bridging the Gap). Her post predates BABOK v3, but the lesson holds.
- Contracts and culture drive the choice. Trainer LN Mishra notes that rigid contracts push suppliers toward predictive planning, while adaptive methods need a client open to collaboration (Adaptive US, 2025).
- Plan even on small or agile work. Scott Bennett of IIBA writes that planning can be a few short conversations on a small project and a full process on a large one, but skipping it leads to rework (IIBA blog, 2020). A 2026 Building Business Capability session warns the other way: "detailed plans will inevitably become outdated" (BBC 2026).
- Tailoring guidance is not a rule. Joy Beatty stresses that tables mapping deliverables to life cycles are guidance, so pick the format that fits, such as use cases instead of user stories (ProjectManagement.com).
Common misconceptions
The approach is the project plan. It is not. The project manager owns the project plan; the business analyst owns the plan for analysis work. The two must align, and the project manager is a key stakeholder in 3.1.
Adaptive means no approach. Adaptive work still needs decisions on formality, timing and acceptance. They are just lighter and revisited more often.
You plan once. BABOK treats the approach as something you revise when the change, stakeholders or risks shift. Task 3.5 feeds lessons back into it.
More formality is always safer. Extra documentation costs stakeholder time and goes stale. Formality should match risk, regulation and contract terms, not habit.
Acceptance means a signature. Formal sign-off is one option. Agreement in a review meeting can be enough where governance allows it.
Practice questions
These are original questions in CBAP style. Answers follow each question.
Question 1. A business analyst joins a project to replace a payroll system. The organisation is subject to tax audits and the vendor contract fixes scope. Stakeholders are in three countries. What should the analyst do first when planning the business analysis approach?
A. Start elicitation workshops to gain momentum B. Assess complexity and risk to set the level of formality C. Adopt an adaptive approach because it lowers risk D. Ask the sponsor to approve a requirements specification template
Answer: B. Regulation, a fixed contract and distributed stakeholders all raise formality. Assessing complexity and risk (an element of 3.1.4) drives the formality decision. A skips planning; C ignores the contract; D jumps to acceptance of a deliverable before the approach exists.
Question 2. Which item is an input to Plan Business Analysis Approach?
A. Business analysis approach B. Stakeholder engagement approach C. Needs D. Governance approach
Answer: C. Needs is the only input. The stakeholder engagement approach is a guideline and tool, not an input; the business analysis approach is the output; the governance approach is the output of 3.3.
Question 3. Halfway through an initiative, the team switches to two-week iterations and the sponsor asks for less upfront documentation. What should the business analyst do?
A. Keep the original approach because it was signed off B. Revise the business analysis approach and get key stakeholders to accept the change C. Stop documenting requirements D. Ask the project manager to update the project plan only
Answer: B. The approach is revisited when the context changes, and acceptance still applies. A treats the plan as fixed; C confuses lighter formality with none; D leaves the analysis approach out of date.
For timed practice on another IIBA exam, try the IIBA CBDA practice exam.
Related techniques and tasks
- Planning workshops to agree scope and the approach with stakeholders.
- Stakeholders and personas, which feed the stakeholder engagement approach used as a guideline here.
- Estimation and business cases, covered in the links above.
FAQ
What is the output of Plan Business Analysis Approach?
The output is the business analysis approach. It describes the planning approach, deliverable formality, activities, timing, complexity and risk, and how the approach was accepted. Tasks 3.2 to 3.5 use it as an input.
What is the only input to BABOK task 3.1?
Needs is the only input. Other items such as the stakeholder engagement approach, business policies and expert judgment are guidelines and tools, not inputs. The exam often tests this difference.
Is the business analysis approach the same as a BA work plan?
They overlap. Many teams write a business analysis work plan that records the approach, activities, deliverables and dates. BABOK cares about the decisions, not the document name or template.
Do agile teams need to plan a business analysis approach?
Yes. Agile teams still decide how formal deliverables are, when analysis happens relative to each iteration, and who must agree. The approach is lighter and revised more often, but it exists.
Who must accept the business analysis approach?
Key stakeholders, typically the sponsor and project manager, and a regulator or compliance officer where rules apply. Some organisations require formal sign-off; others accept agreement in a review.
Sources
- IIBA: CBAP certification page
- IIBA: Task card, Plan Business Analysis Approach
- IIBA: 9 Steps to Planning a Business Analysis Approach
- IIBA blog: Business Analysis Planning and Monitoring, Scott Bennett, 2020
- Open Exam Prep: Plan BA Approach, Task 3.1
- Adaptive US: Choosing a Business Analysis Approach, LN Mishra, 2025
- Modern Analyst: How much analysis do you really need to do, Howard Podeswa
- Bridging the Gap: The BABOK might not be a methodology, Laura Brandenburg
- ProjectManagement.com: Adapting BA processes for adaptive vs predictive life cycles, Joy Beatty
- Medium: Business analysis approach definition, Ivan Tumashevskiy
- Building Business Capability 2026: Better business analysis with the BA planning canvas