If you are sitting down to plan your business analysis effort on a new project, the first thing to sort out is not a template or a tool. It is a clear answer to one question: what am I actually being asked to deliver, and how does that connect to what the organisation is trying to achieve? Business analysis planning starts there. Everything else, your approach document, your stakeholder map, your activity schedule, flows from the answer to that question.
I have set up BA planning on projects across government, utilities, health, and enterprise environments. The single biggest mistake I see, and one I made myself early in my career, is treating the planning phase as a formality rather than as a thinking exercise. When I skipped real planning, I paid for it later in rework, misaligned deliverables, and stakeholder relationships I had to repair. When I invested in it properly, the rest of the project moved faster and with far less friction.
What Business Analysis Planning Actually Covers
Planning your BA effort is not the same as the project manager’s project plan. The project plan covers the full delivery lifecycle. Your business analysis plan covers the specific work you are responsible for: the approach you will take, the techniques you will use, the deliverables you will produce, the stakeholders you need to engage, and the timeframes you are working within. Often the project plan says almost nothing about the BA work in any useful detail. That gap is yours to fill.
A solid business analysis plan addresses the following areas:
- Scope of the BA effort: Exactly what analysis work is in scope, and what is explicitly out of scope, so there is no ambiguity later about what you are accountable for.
- Approach and methodology: Whether you are working in an agile, waterfall, or hybrid environment shapes every technique you choose and every deliverable you produce.
- Stakeholder identification and engagement: Who you need to involve, at what level, and through which channels, including workshops, interviews, and review cycles.
- Deliverables and milestones: The specific outputs you will produce, when they are due, and who needs to sign them off.
- Risks and assumptions: The conditions your plan depends on, and the risks that could derail your analysis work before it starts.
- Resources and tools: What access, systems, data, and subject matter expert time you need to do the work properly.
If you are looking for a structured starting point, the Business Analysis Plan Template on this site gives you a framework you can adapt to your project context immediately.
Planning Across Different Delivery Approaches
The level of formality and the specific outputs you produce will differ depending on the delivery methodology your project is using. This is one of the most practically important distinctions in business analysis planning, and it catches a lot of analysts out when they move between project types.
| Planning Element | Waterfall | Agile | Hybrid |
|---|---|---|---|
| Approach document | Formal, signed off before analysis begins | Lightweight, agreed verbally or in a brief document | Formal for scope, flexible for delivery |
| Stakeholder engagement plan | Detailed, structured communication matrix | Ongoing, embedded in sprint ceremonies | Structured up front, iterative during sprints |
| Deliverables | BRD, FRD, process maps, sign-off documentation | User stories, acceptance criteria, backlog refinement notes | Mix of formal documents and agile artefacts |
| Revision frequency | Controlled change process | Continuous, per sprint | Formal changes for scope, iterative for details |
| Risk to BA if planning is skipped | High: misaligned requirements, late rework | Medium: scope creep, undefined acceptance criteria | High: ambiguity between phases causes delivery gaps |
For a deeper look at how methodology choice affects your BA work, the article on Agile vs Waterfall Methodologies is worth reading alongside your planning work.
A Worked Example: When the Plan Had to Be Rebuilt
On Project X, a systems replacement initiative for Organisation B, a mid-sized public sector body, I was brought in after initial scoping had already been done by the project manager. I was handed a project plan that included a single line item for “business analysis” with a six-week window and no further detail. The assumption was that I would slot into that window and produce a requirements specification at the end of it.
When I sat down with the project manager to discuss my approach, the friction started almost immediately. She had already communicated the six-week timeline to senior stakeholders and did not want to reopen that conversation. I needed to explain, with evidence, why the timeline was unworkable given the number of business units affected and the complexity of the legacy system being replaced.
I put together a one-page business analysis approach document that mapped out the stakeholder groups, the elicitation activities required for each, the dependencies on IT access and SME availability, and the realistic timeline. It showed clearly that six weeks was achievable only if three conditions were met: dedicated SME time from four business units, access to the legacy system documentation within the first two weeks, and a decision from the steering committee on scope boundaries before elicitation began. None of those conditions had been confirmed.
The project manager pushed back, but when we presented the approach document to the steering committee together, the committee chair immediately saw the risk. The scope boundary decision alone took three weeks to resolve because two of the business units disagreed about which processes were in scope. Had I not planned explicitly and made those dependencies visible, I would have spent six weeks producing requirements that were later challenged, revised, or discarded.
The lesson I took from that project was this: your planning document is not just for your own organisation. It is a risk management tool. It makes the conditions for your success explicit, which gives decision-makers the information they need to either meet those conditions or adjust their expectations.
How to Write a Business Analysis Approach Document
The business analysis approach document is the core output of your planning phase. It does not need to be long. On smaller projects I have written it in three pages. On larger enterprise programmes it has run to fifteen. The length is not what matters. What matters is that it answers the questions any informed stakeholder would ask about your work.
For a detailed walkthrough of how to write this document, including the sections to include and the language to use, see How to Write a Business Analysis Approach Document. What I will add here from my own experience is that the most important section is the one most often written poorly: assumptions and dependencies. This is where you name the things your plan relies on that are outside your control. If those things do not materialise, your plan changes. Writing them down gives you a legitimate, documented basis for renegotiating scope, timeline, or resources when the project reality diverges from the plan.
Three Reasons Planning Directly Improves BA Outcomes
- It improves stakeholder communication from day one: A written plan gives stakeholders a shared picture of what you will do, how you will engage them, and what you need from them. This sets expectations before any misunderstandings have a chance to take root.
- It keeps your work on track across competing priorities: When you are running multiple streams or juggling project work alongside business-as-usual, a plan gives you a reference point for deciding where to put your time. Without it, you default to whatever feels most urgent, which is rarely what is most important.
- It reduces the risk of the most common BA failure modes: Missed requirements, poorly managed scope, inadequate stakeholder involvement, and requirements that do not trace back to business objectives are all significantly less likely when you have thought through your approach before you start eliciting. Planning is not a guarantee, but it shifts the odds in your favour.
What to Do When Your Plan Needs to Change
A business analysis plan is not a contract. It is a working document. The projects I have found most difficult are not the ones where the plan changed. They are the ones where the plan changed and nobody acknowledged it, which left me delivering work that no longer matched what the project actually needed.
When your plan needs to change, and it will, treat it the same way you would treat a scope change on any other project deliverable. Document what has changed, why it has changed, and what the implications are for your timeline, deliverables, and stakeholder engagement. Communicate that to your project manager and sponsor. Then update the plan. This is not bureaucracy for its own sake. It is how you protect yourself and the project from the accumulated drift that turns manageable scope creep into a delivery crisis. The article on Business Analyst Scope Creep and Governance covers this in detail if you are dealing with a project where boundaries are already blurring.
The single habit that has saved me more time and credibility than anything else across 25 years of BA work is this: treat the planning phase as the most valuable thinking time you have on any project, not as a box to tick before the real work begins. A plan that forces you to articulate your approach, name your dependencies, and commit to a set of deliverables is one that will carry you through the inevitable turbulence of any real project, and give you the professional standing to navigate it with confidence.
Frequently asked questions
What is business analysis planning?
Business analysis planning is the process of defining how you will carry out your BA work on a project. It covers your approach, the techniques and tools you will use, the stakeholders you need to engage, the deliverables you will produce, and the timeline you are working within. It is distinct from the project manager’s project plan and focuses specifically on the BA contribution.
What should a business analysis plan include?
A business analysis plan should include the scope of your BA effort, your chosen methodology and elicitation approach, a stakeholder engagement strategy, a list of deliverables with target dates, and a section on risks, assumptions, and dependencies. The level of formality will vary depending on whether you are working in an agile, waterfall, or hybrid environment.
Why is planning important in business analysis?
Planning reduces the risk of common BA failure modes including missed requirements, scope creep, and stakeholder misalignment. It gives you and your stakeholders a shared understanding of what you will deliver and what you need to do it. Without a plan, it is easy to spend time on activities that do not contribute to the project’s actual objectives.
What is a business analysis approach document?
A business analysis approach document is a written description of how you intend to carry out your BA work on a specific project. It typically covers your methodology, elicitation techniques, stakeholder engagement plan, deliverables, timeline, and assumptions. It can be a standalone document or used alongside the project manager’s project plan.
How do I start planning my business analysis work?
Start by clarifying the objectives of the project and the problem you are being asked to help solve. From there, identify the stakeholders you need to involve, the techniques that suit the context, and the deliverables you are expected to produce. Write this down in a brief approach document before any elicitation begins so that your plan is visible and agreed rather than assumed.
Try Ash, Your Virtual BA
If you are working through your business analysis planning right now, Ash can help you think it through practically. Ash is a virtual BA assistant built specifically for this kind of work. Ask Ash to help you structure your approach document, identify the right elicitation techniques for your project context, or pressure-test your assumptions before you share your plan with stakeholders. It is the logical next step after reading this guide. Try Ash Virtual BA and get your planning on solid ground today.
Further reading
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.