# Business Analysis Plan: [Initiative name]

> Plan for the business analysis work on one initiative: the approach,
> how stakeholders will be engaged, how decisions and changes are
> governed, how business analysis information is managed, and how the
> work itself will be measured and improved. The section structure is
> aligned with the five tasks of the Business Analysis Planning and
> Monitoring knowledge area (chapter 3) of IIBA's *A Guide to the
> Business Analysis Body of Knowledge* (BABOK Guide) version 3 (2015).
> Replace every `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Write the plan before elicitation starts, and keep it short enough
  that the sponsor reads it. Twelve pages is a lot; four is often enough.
- Fill section 1 (context) and section 2 (approach) first. Every later
  section depends on whether the work is predictive, adaptive or mixed.
- The plan covers the business analysis work, not the whole project.
  Point to the project plan, the requirements management plan and the
  communication plan instead of copying them.
- Revisit the plan at each phase gate or every few iterations. Section 6
  says what you measure to know whether the plan is working.
- The BABOK Guide is a licensed IIBA publication. This template uses
  only the names and numbers of its chapter 3 tasks; the wording is
  original. Buy or license the guide for its full content.
-->

## Document control

<!-- Guidance: Identify the plan so every copy can be traced to one version. The status moves Draft, In review, Approved, Superseded. -->

| Field | Value |
|---|---|
| Document ID | [BAP-INITIATIVE-001] |
| Initiative | [Initiative name and short code] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner (lead business analyst) | [@lead-ba] |
| Sponsor | [@sponsor] |
| Approvers / reviewers | [Sponsor, product owner, project manager, architecture lead] |
| Delivery approach | [Predictive / Adaptive / Hybrid] |
| Last updated | YYYY-MM-DD |
| Next planned review | YYYY-MM-DD |
| Classification | [Internal / Confidential] |
| Related documents | [Business case], [Project plan], [Requirements management plan], [Communication plan] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Sponsor | [@name] | [Approved / Approved with comments / Rejected] | YYYY-MM-DD |
| Product owner | [@name] | [Decision] | YYYY-MM-DD |
| Project manager | [@name] | [Decision] | YYYY-MM-DD |
| Lead business analyst | [@name] | Author | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Initial draft |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Added the claims operations team as a stakeholder group after the kick-off workshop |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved by the sponsor at the phase 1 gate |

## Contents

<!-- Guidance: Keep this list in step with the headings. The Outline panel of the editor also navigates by heading. -->

1. [Context and scope of the business analysis work](#1-context-and-scope-of-the-business-analysis-work)
2. [Business analysis approach](#2-business-analysis-approach)
3. [Stakeholder engagement](#3-stakeholder-engagement)
4. [Business analysis governance](#4-business-analysis-governance)
5. [Business analysis information management](#5-business-analysis-information-management)
6. [Performance measures and improvement](#6-performance-measures-and-improvement)
7. [Activities, deliverables and effort](#7-activities-deliverables-and-effort)
8. [Risks, assumptions and dependencies](#8-risks-assumptions-and-dependencies)
9. [Glossary and references](#9-glossary-and-references)

## 1. Context and scope of the business analysis work

<!-- Guidance: Say why the business analysis work exists and where it stops. Questions to answer: what need or opportunity triggered the initiative, who asked for analysis, what is in and out of scope for the analysts (not for the project). Pitfall: copying the project scope; the analysis scope is usually wider at the start (strategy) and narrower later (one solution). -->

### 1.1 Business need

[Two or three sentences: the problem or opportunity, who feels it, and
what it costs today. Link the business case if one exists.]

*Example:* Tarnwick Home Insurance (fictional) takes 12,000 first notices
of loss (FNOL) per quarter, almost all by telephone. Each call takes 14
minutes of agent time and customers wait an average of 9 days for a first
payment. The board approved a self-service claims portal in the
2026 plan.

### 1.2 Scope of the business analysis work

| In scope for business analysis | Out of scope for business analysis |
|---|---|
| [Current-state analysis of claim notification] | [Vendor selection, owned by procurement] |
| [Future-state process and business rules] | [Detailed technical design, owned by architecture] |
| [Requirements and acceptance criteria for release 1] | [Training material production] |
| [Solution evaluation six months after launch] | [Pricing changes] |

### 1.3 Business analysis team

| Role | Name | Allocation | Main responsibilities |
|---|---|---|---|
| Lead business analyst | [@name] | [100%] | Plan, governance, stakeholder engagement, final quality of requirements |
| Business analyst | [@name] | [80%] | Process models, business rules, acceptance criteria |
| Data analyst | [@name] | [40%] | Baseline measures, data requirements, solution evaluation data |
| Product owner (counterpart) | [@name] | [50%] | Prioritisation, backlog decisions, acceptance |

## 2. Business analysis approach

<!-- Guidance: BABOK task 3.1 Plan Business Analysis Approach. Decide how formal, how sequential and how detailed the analysis will be, and say why. Questions: is the solution known, how volatile are needs, what does the governance or regulator expect to see in writing? Pitfall: picking "agile" or "waterfall" by habit instead of from the characteristics of the change. -->

### 2.1 Approach decision

| Factor | Assessment | Effect on the approach |
|---|---|---|
| Certainty of the need | [High / Medium / Low] | [Low certainty favours short discovery cycles] |
| Stability of requirements | [Stable / Changing] | [Changing needs favour a backlog over a signed baseline] |
| Regulatory or audit expectations | [Describe] | [Formal sign-off on rules and decisions where an auditor will look] |
| Stakeholder availability | [Describe] | [Workshops versus asynchronous review] |
| Size and complexity | [Describe] | [Number of analysts, depth of modelling] |
| Supplier involvement | [Describe] | [Contracted specifications need a fixed baseline] |

**Chosen approach:** [Predictive / Adaptive / Hybrid], because [reason].

*Example:* Hybrid. Business rules for claim acceptance and the data
shared with the reinsurer are baselined and signed off, because the
internal audit team reviews them. Portal screens and messages are
refined in two-week iterations with the product owner.

### 2.2 Timing and level of detail

| Phase or cadence | Business analysis focus | Level of detail | Formality |
|---|---|---|---|
| Discovery (weeks 1 to 4) | Current state, problem framing, stakeholder map | Process level 1 and 2, high-level needs | Light: workshop notes, one-page summaries |
| Definition (weeks 5 to 8) | Future state, business rules, release 1 scope | Rules and data at attribute level | Formal: reviewed and baselined |
| Delivery iterations | Stories, acceptance criteria, refinement | Story level, examples | Light: backlog items, reviewed in refinement |
| Evaluation (launch + 6 months) | Actual value against expected benefits | Measures and findings | Formal report to the sponsor |

### 2.3 Elicitation and analysis techniques

| Technique | Used for | Stakeholders involved | Output |
|---|---|---|---|
| Document analysis | Existing call scripts, policy wording, complaints log | Analysts | Current-state notes |
| Interviews | Claims handlers, team leaders, fraud team | [Groups] | Interview notes (`requirements/stakeholder-interview-guide`) |
| Workshops | Future-state process and rules | Claims operations, product, legal | Process model, rule list (`requirements/discovery-workshop-plan`) |
| Observation | Live FNOL calls (with consent) | Agents | Pain points, timings |
| Process modelling | Current and future FNOL process | Analysts | BPMN diagrams |
| Business rules analysis | Claim acceptance and routing rules | Claims, legal | Rules catalogue (`requirements/business-rules-catalogue`) |
| Acceptance and evaluation criteria | Release 1 stories and evaluation measures | Product owner, QA | Scenarios (`requirements/acceptance-criteria-bdd`) |

### 2.4 Approach overview

The diagram shows the phases in 2.2 and the baseline decision in 4.4.
Redraw it when the chosen approach changes.

```mermaid
flowchart LR
  A["Discovery: current state and need"] --> B["Definition: future state, rules, scope"]
  B --> C{"Baseline approved?"}
  C -- "No" --> B
  C -- "Yes" --> D["Delivery iterations: stories and acceptance criteria"]
  D --> E["Release and transition"]
  E --> F["Solution evaluation: actual value against benefits"]
  F --> G["Recommendations to the sponsor"]
```

## 3. Stakeholder engagement

<!-- Guidance: BABOK task 3.2 Plan Stakeholder Engagement. List who is affected or has influence, how much they matter to the analysis, and how you will work with each group. Questions: who can block a decision, who holds knowledge nobody else has, who is affected but has no voice? Pitfall: listing only the people who attend meetings. -->

### 3.1 Stakeholder analysis

Keep the full register in `project/stakeholder-register`; this table
records only what the analysis needs.

| ID | Stakeholder or group | Interest in the change | Influence | Attitude | Knowledge they hold |
|---|---|---|---|---|---|
| STK-01 *(Example)* | Claims operations manager | Fewer calls, shorter handling time | High | Supportive | Volumes, staffing, call reasons |
| STK-02 *(Example)* | Claims handlers | Less repetitive data entry, fear of job change | Medium | Mixed | Real exceptions and workarounds |
| STK-03 *(Example)* | Fraud team | Early fraud signals, no loss of control | High | Cautious | Fraud indicators, referral rules |
| STK-04 *(Example)* | Policyholders | Fast, simple notification and payment | Medium (through complaints and reviews) | Unknown | Experience of the current process |
| STK-05 *(Example)* | Internal audit | Evidence that rules are controlled | High at gates | Neutral | Control expectations |
| [STK-nn] | [Group] | [Interest] | [High / Medium / Low] | [Attitude] | [Knowledge] |

### 3.2 Collaboration and communication plan

| Stakeholder | How we collaborate | Frequency | Format | Owner |
|---|---|---|---|---|
| STK-01 | Decision meeting, review of baselines | Every two weeks | Meeting, written summary | Lead BA |
| STK-02 | Observation, interviews, prototype walkthroughs | Discovery, then each iteration | In person or video | BA |
| STK-03 | Rules workshops, review of fraud referral rules | Definition phase | Workshop | BA |
| STK-04 | Usability tests on prototypes, survey after launch | Two rounds before launch, one after | Remote sessions | Product owner |
| STK-05 | Walkthrough of governance and traceability | At each gate | Meeting | Lead BA |

Align recurring messages with the project communication plan
(`project/communication-plan`) so stakeholders do not receive two
versions of the same update.

## 4. Business analysis governance

<!-- Guidance: BABOK task 3.3 Plan Business Analysis Governance. Define who decides on requirements and designs, how changes are requested and assessed, and how priorities are set. Questions: who approves a baseline, who can change a priority, what happens when two stakeholders disagree? Pitfall: a governance model that needs the sponsor for every decision, so nothing gets decided. -->

### 4.1 Decision rights

| Decision | Proposes | Decides | Consulted | Informed |
|---|---|---|---|---|
| Release scope | Product owner | Sponsor | Lead BA, project manager | All stakeholders |
| Business rule baseline | Lead BA | Claims operations manager | Legal, fraud, audit | Delivery team |
| Story priority within a release | Product owner | Product owner | BA, delivery team | Sponsor |
| Change to a baselined rule | Any stakeholder | Change control board | Lead BA, legal | Delivery team |
| Escalated disagreement | Lead BA | Sponsor | Parties involved | Project board |

### 4.2 Change control

1. Raise the change with the reason, the requirement or rule IDs
   affected and the urgency.
2. The business analyst assesses impact on scope, value, cost, time,
   risk, compliance and traceability within [five working days].
3. The decider in 4.1 accepts, rejects or defers it.
4. The business analyst updates the requirement, the traceability
   links and the revision history, and tells affected stakeholders.

```mermaid
flowchart TD
  R["Change request raised"] --> I["BA impact assessment"]
  I --> Q{"Affects a baselined item?"}
  Q -- "No" --> P["Product owner decides in refinement"]
  Q -- "Yes" --> B["Change control board decides"]
  P --> U["Update requirements and trace links"]
  B --> U
  U --> N["Notify affected stakeholders"]
```

### 4.3 Prioritisation

Method: [MoSCoW / weighted scoring / cost of delay]. Criteria:
[business value, regulatory need, risk reduction, dependency, cost].
Record the method in `product/prioritization` when the product team
owns the backlog.

### 4.4 Approval and sign-off

| Item | Approval needed | Evidence kept |
|---|---|---|
| Business requirements baseline | Sponsor | Signed approval in the document control table |
| Business rules baseline | Claims operations manager and legal | Approval record, rule catalogue version |
| Release acceptance | Product owner | Acceptance test results |

## 5. Business analysis information management

<!-- Guidance: BABOK task 3.4 Plan Business Analysis Information Management. Say how requirements, models, decisions and evidence are organised, stored, traced and kept. Questions: where is the single source of truth, what is traced to what, how long is it kept and who can see it? Pitfall: requirements spread over email, slides and three tools with no one owning the master. -->

### 5.1 Information types and where they live

| Information | Format | Tool or repository | Owner | Access |
|---|---|---|---|---|
| Business and stakeholder requirements | Document | [Repository] | Lead BA | Project team, read for stakeholders |
| Stories and acceptance criteria | Backlog items | [Backlog tool] | Product owner | Project team |
| Process models | BPMN files | [Modelling tool] | BA | Project team |
| Business rules | Catalogue | [Repository] | BA | Project team, audit |
| Decisions | Decision log (`business/decision-log`) | [Repository] | Lead BA | Project team |
| Elicitation notes | Notes, recordings with consent | [Restricted folder] | BA | Analysts only |

### 5.2 Level of abstraction and templates

[Which document templates are used for which audience, for example
`requirements/business-requirements` for the sponsor,
`requirements/stakeholder-requirements` for operations,
`product/user-story` for the delivery team.]

### 5.3 Traceability

Trace business objectives to business requirements, business
requirements to stakeholder requirements and rules, and those to stories
and tests. Maintain the links in `requirements/traceability-matrix`, and
keep the wider requirements process in
`requirements/requirements-management-plan`.

### 5.4 Attributes recorded for each requirement

| Attribute | Values |
|---|---|
| ID | Prefix plus number, never reused |
| Source | Stakeholder ID, document or regulation |
| Priority | Per 4.3 |
| Status | Proposed, Approved, Implemented, Verified, Deferred, Withdrawn |
| Owner | Named person |
| Stability | High, Medium, Low |
| Acceptance criteria | Reference to scenario or test |

### 5.5 Storage, retention and privacy

Recordings and notes that contain personal data are stored in
[restricted location], kept for [period agreed with the data protection
officer] and deleted after [event]. Requirements and decisions are kept
for [period] after the solution is retired. Check your organisation's
retention schedule and data protection policy.

## 6. Performance measures and improvement

<!-- Guidance: BABOK task 3.5 Identify Business Analysis Performance Improvements. Choose a few measures that show whether the analysis work is helping delivery, and review them. Questions: are requirements arriving on time, how much rework do they cause, do stakeholders trust them? Pitfall: measuring the number of documents produced instead of their effect. -->

### 6.1 Measures

| ID | Measure | How measured | Target | Review |
|---|---|---|---|---|
| BAM-01 *(Example)* | Stories ready before sprint planning | Share of planned stories meeting the definition of ready | At least 90% | Each iteration |
| BAM-02 *(Example)* | Requirement defects found in review | Defects per 100 requirements (`requirements/requirements-review-checklist`) | Falling over three reviews | Each review |
| BAM-03 *(Example)* | Rework caused by misunderstood requirements | Stories reopened for requirement reasons | Fewer than 2 per iteration | Each retrospective |
| BAM-04 *(Example)* | Stakeholder confidence | Short survey, 1 to 5 scale | At least 4.0 | Each phase gate |
| [BAM-nn] | [Measure] | [Method] | [Target] | [Cadence] |

### 6.2 Review and improvement

At each [phase gate or fourth iteration] the lead business analyst
reviews the measures with the product owner and project manager, records
what to change in this plan, and updates the revision history. Lessons
that apply beyond the initiative go to `project/lessons-learned`.

## 7. Activities, deliverables and effort

<!-- Guidance: Turn the approach into a work list the project manager can schedule. Estimate in hours or days and show the basis. Pitfall: forgetting solution evaluation effort, which is spent months after the project team has moved on. -->

| Activity | Deliverable | Effort (hours) | Share | Timing |
|---|---|---|---|---|
| Planning *(Example)* | This plan | 40 | 6.7% | Weeks 1 to 2 |
| Strategy analysis *(Example)* | Current and future state, gap analysis | 48 | 8.0% | Weeks 2 to 4 |
| Elicitation *(Example)* | Interview and workshop outputs | 160 | 26.7% | Weeks 1 to 8 |
| Analysis and design definition *(Example)* | Requirements, rules, models, acceptance criteria | 220 | 36.7% | Weeks 5 to 20 |
| Requirements life cycle management *(Example)* | Traceability, change assessments | 60 | 10.0% | Throughout |
| Solution evaluation *(Example)* | Evaluation report (`requirements/solution-evaluation-report`) | 72 | 12.0% | Launch + 6 months |
| **Total** | | **600** | **100%** | |

Estimation basis: [past initiatives of similar size, number of
stakeholder groups, number of processes and rules in scope].

## 8. Risks, assumptions and dependencies

<!-- Guidance: Record only risks to the business analysis work; project risks belong in the project risk register. Give each an owner and a response. Pitfall: listing risks with no response, which makes the table decoration. -->

| ID | Type | Description | Likelihood | Impact | Response | Owner |
|---|---|---|---|---|---|---|
| BAR-01 *(Example)* | Risk | Claims handlers unavailable during peak season | Medium | High | Book sessions before the season, use observation instead of workshops | Lead BA |
| BAR-02 *(Example)* | Risk | Fraud rules held only by two experts | High | High | Pair a BA with each expert, review rules with audit | BA |
| BAR-03 *(Example)* | Assumption | Baseline call data for the last 12 months is available | | | Confirm with the data analyst by week 2 | Data analyst |
| BAR-04 *(Example)* | Dependency | Legal review of claim acceptance wording | | | Agree review slots in week 1 | Lead BA |
| [BAR-nn] | [Type] | [Description] | [L] | [I] | [Response] | [@owner] |

## 9. Glossary and references

<!-- Guidance: Define every term a new stakeholder might misread, and list the documents this plan depends on. -->

### 9.1 Glossary

| Term | Meaning in this plan |
|---|---|
| Business analysis approach | The overall method, timing and formality chosen for the analysis work |
| Baseline | An approved set of requirements or rules that changes only through change control |
| FNOL | First notice of loss: the customer's first report of a claim (example domain) |
| Knowledge area | One of the six groups of tasks in the BABOK Guide |
| Stakeholder | A person or group affected by, or able to influence, the change |

### 9.2 References

| Reference | Use |
|---|---|
| IIBA, *A Guide to the Business Analysis Body of Knowledge* (BABOK Guide) v3, 2015, chapter 3 | Task structure of this plan (names only) |
| [Business case] | Need, benefits and constraints |
| [Project plan] | Schedule and project governance |
| `requirements/requirements-management-plan` | Requirements process, baselines, tools |
| `requirements/business-requirements` | Business requirements document |
| `project/stakeholder-register` | Full stakeholder register |
| `project/benefits-realization-plan` | Benefits that the solution evaluation will measure |

## Standard and licence note

Structure aligned with the five tasks of the Business Analysis Planning
and Monitoring knowledge area (chapter 3: 3.1 Plan Business Analysis
Approach, 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) of *A Guide to the
Business Analysis Body of Knowledge* (BABOK Guide) version 3, published
by the International Institute of Business Analysis (IIBA) in 2015.
BABOK is a registered trademark of IIBA. This template is original text
written for this collection; it uses only the guide's task names and
numbers and reproduces none of its content. As of October 2026 version 3
is the current edition listed by IIBA; check for a newer edition before
use. Official text: IIBA, purchase or member access at
https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/.
Template licence: MIT.