Business Analysis Plan Template

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.

Document control

Approvals

Revision history

Contents

1. Context and scope of the business analysis work
2. Business analysis approach
3. Stakeholder engagement
4. Business analysis governance
5. Business analysis information management
6. Performance measures and improvement
7. Activities, deliverables and effort
8. Risks, assumptions and dependencies
9. Glossary and references

1. Context and scope of the business analysis work

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

1.3 Business analysis team

2. Business analysis approach

2.1 Approach decision

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

2.3 Elicitation and analysis techniques

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.

3. Stakeholder engagement

3.1 Stakeholder analysis

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

3.2 Collaboration and communication plan

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

4.1 Decision rights

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.

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

5. Business analysis information management

5.1 Information types and where they live

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

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

6.1 Measures

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

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

8. Risks, assumptions and dependencies

9. Glossary and references

9.1 Glossary

9.2 References

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.