Business Analysis Planning, Explained the Easy Way

2025-06-23 11:23 Business analysis

The previous post on strategy analysis, discovery, and vision and scope “in plain terms” seemed to hit the mark, so I’m going to stick to the same format and talk about something else that’s just as useful — business analysis planning: what it is, why you should care, and how to approach it.

I first heard of business analysis planning as a standalone activity through BABOK. There’s actually an entire knowledge area in BABOK (though most people just treat them as work areas) called Business Analysis Planning and Monitoring. We’ll talk a bit about how BABOK frames it, but the focus will be on a simpler, more practical take.

Business analysis planning, for a BA, is basically getting ready to do your job. Just like with any project — be it work-related or personal (and by “project” I mean anything with a unique set of steps and a goal) — it’s usually smart to pause for a second and think through what needs to be done and how to do it well. In other words, measure twice, cut once.

Now, let’s be clear: “planning” doesn’t mean spending days overthinking every detail. If you’ve set aside at least 15 minutes to think your work through — that’s already planning. Whether it’s good planning depends on what you considered and how much experience you bring into it. I can’t magically give you experience in this post, but I can offer a checklist of things worth thinking about, which should already make the whole process worth your while.

So, when do we actually plan business analysis? Naturally, at the beginning of the work (and often even before the project has been officially approved or contracted). But not only at the start. Think about how you plan personal projects. For anything more complex than a quick trip to the store, you rarely have all the input right at the beginning — sometimes, you have none at all. That’s why many people who value planning treat it as an ongoing thing: whenever you’ve got enough info to move forward with a chunk of the plan, that’s when you update it.

A good analogy: planning a vacation. At first, it’s just broad strokes. As the trip gets closer, you work out the finer details. And if you’re like me — a bit of a systems nerd — you might even review and tweak those plans while you’re on vacation.

So what does BABOK say? In BABOK version 3, there are five tasks under this knowledge area:

Plan Business Analysis Approach — thinking through the overall way a BA (that’s you, or your team) will work: what needs to be done, how it’ll be done, and what the expected outcomes are.
Plan Stakeholder Engagement — figuring out who your stakeholders are, what you need from them, and how you’re going to interact with them. BA work is people work, and this is a reminder of that.
Plan Business Analysis Governance — yeah, sounds intense. But it’s just about defining how decisions will be made during the BA process: who’s responsible for what, and how we manage things like approvals and changes.
Plan Business Analysis Information Management — deciding what kind of info you’ll work with, how you’ll capture it, organize it, share it, and so on. BA is also heavily about handling information.
Identify Business Analysis Performance Improvements — this one’s more about monitoring than planning: tracking how things are going, identifying where to improve, and adjusting accordingly.

We’ll skip #5 for now since our focus here is planning. That leaves us with four key areas, and I’ll structure the checklist around those.

As with any checklist, the idea is to go through it and make sure you haven’t forgotten anything important. Some points you’ll think through in detail (if they’re really relevant to your project), others you might skim or skip (maybe they’re not so important right now, or there’s not enough info yet). The key thing is: this checklist is about what to think through during planning — not what the final deliverables or documents should be.

Let’s dive into each task one by one.

1. Plan Business Analysis Approach

1.1. Planning Approach

This is how it’s presented in BABOK, but I’d expand it a bit to: “What will our overarching approach to business analysis on the project look like?”

BABOK boils this down to a scale with two endpoints:

Predictive (detailed upfront planning).
Adaptive (less planning, more real-time adaptation).

I won’t linger here since I’ve already said a few words about it: Agile vs. Waterfall: Specifics of a Business Analyst’s Role.

The key thing to understand here is: our work heavily depends on the chosen — or imposed — business analysis approach. Tasks, processes, artifacts, required skills, and even mindset can vary drastically depending on whether you're working in a high-bureaucracy organization or a product-oriented Agile team. This planning task is about avoiding the mindset of “I just write and refine stories and nothing else,” and instead building a richer toolbox — selecting the right screwdriver for each screw.

In real life, the approach to business analysis is almost always a hybrid, not an extreme on the scale — we just tend to lean more one way or the other. The goal is not to slap a label on the analysis effort (“predictive” or “adaptive”) but to make a conscious decision about which direction to lean in — and then reflect that decision in all subsequent planning: it will affect how we document requirements, the scope of our work, our tools and systems, how deeply we do risk management, how thoroughly we study stakeholders, and so on.

(Disclaimer: all examples in this article are simplified for clarity.)

We’re working in pure Agile, so my business analysis will be heavily skewed toward adaptiveness (and I’ll keep that in mind throughout all the following planning sections).

1.2. Formality and Level of Detail of Business Analysis Deliverables

This is primarily about the “containers” of information the analyst will use to hold business analysis outputs (particularly requirements — though I’ll use “requirements” as shorthand here, full discussion here: Requirements vs. Non-Requirements: Where the Analyst Ends).

Formality means the degree of freedom in choosing templates for your artifacts. A formal artifact could be a government-standard technical specification, a rigid requirements spec, or a Vision and Scope document. Informal ones are Agile artifacts — like user stories or simplified documentation (e.g., UI prototypes with annotations).

Detail refers to both the depth and breadth of requirements. The highest level of detail means requirements that cover all behavioral nuances and system specifics. Unsurprisingly, your choices here will correlate with the approach chosen in 1.1.

In this section, we reflect on what artifacts we’ll create and whether we’ll maintain them in an up-to-date state (something worth considering separately).

We will compose an SRS using the corporate template since the contract requires a well-structured document. For behavioral requirements, we’ll stick to use cases — finer detail (like individual UI controls) isn’t needed, as the team can design excellent UIs based on usage scenarios. We’ll keep the SRS up-to-date because it will serve as a crucial knowledge base for reasons X and Y.

1.3. Business Analysis Activities

(Combining BABOK’s .3 Business Analysis Activities and .4 Timing of Business Analysis Work)

Here we map out our activities. As with section 1.1, we can focus on the near term or attempt to draft a full project-wide plan. The full version would include a list of tasks, timelines, assignees, effort estimates (note: effort ≠ duration — you may work on something for a month but only 25% of your time), dependencies (e.g., Task X can't start until Task Y is done), and expected outcomes.

If we lean predictive, just Google “Gantt chart” or ask ChatGPT about it. But even in an adaptive approach, it helps to understand — at least directionally — what we’re doing and when. It’s also often needed for estimates — for your own clarity or your PM’s peace of mind.

With a predictive approach, it’s straightforward (exhaustively plan everything years in advance, while secretly knowing it’ll never go exactly as planned). In contrast, in adaptive environments, I like how Max Dorofeev puts it:

A rational flâneur is someone who, unlike a tourist, reevaluates their route at each step based on new information. In other words, they:
Acknowledge they don’t know everything upfront.
Accept uncertainty will decrease as the project progresses.
Adjust plans accordingly.
...
Like an investigator who can’t lay out a full Gantt chart before starting the case, or a doctor who can't prescribe treatment before test results — trying to plan the whole project from day one is a rookie mistake. You don’t need the full plan now. At most, a couple of tasks for “today and tomorrow” is enough. A rational type will step in again soon, evaluate outcomes, and decide what’s next.

Simple task list example from Business Analysis for Dummies.

1.4. Business Analysis Risks (Identification and Analysis)

A risk is (simplified) a potential future event that could mess up your business analysis. Identification means brainstorming and outlining the list of visible risks. Analysis means evaluating their likelihood and impact — and figuring out what to do about them.

To identify risks, use a checklist of common ones (e.g., Mr. Karl’s Software Requirements has a great list in “Requirements-related risks”), and expand it as you gain more scar tissue from real-life mishaps.
In analyzing, you might rate each risk on a scale (say, 1 to 10) for:
a) likelihood,
b) impact.
Then calculate a composite risk score (e.g., by multiplying or averaging) and assign a final label: red, yellow, or green.

Finally — and this is the whole point of this section — decide what to do with the serious ones:

Avoid: remove the cause. (E.g., drop a feature likely to have conflicting requirements.)
Transfer: shift responsibility. (E.g., adopt a change management approach where requirement changes incur additional cost.)
Mitigate: reduce likelihood or impact. (E.g., agree in advance with the client on response times; or define that if no response comes within X days, the team proceeds with the default suggestion.)
Accept: do nothing.

If your risk management efforts influence other parts of the business analysis plan — you’re doing it right. That’s where the true value of risk work lies.

Client takes forever reviewing documents → build in buffer time when sending for review/approval.
Client constantly suggests new features → proactively explain prioritization and co-create a prioritization process.
Risk of missing key info during requirement elicitation (e.g., team of juniors) → meticulously plan meetings and define clear goals for each session.

1.5. BABOK also mentions Acceptance — getting stakeholder buy-in for all of the above. This only really applies in bureaucratic environments. In reality, we often do all this planning just for ourselves or our team — the client and other stakeholders usually don’t care about our meticulous planning. They just want results.

2. Plan Stakeholder Engagement

2.1. Perform Stakeholder Analysis

We need to:
a) Identify the stakeholders,
b) Define their roles (in the context of our analysis/change/solution),
c) Note additional relevant attributes (e.g., attitude toward the project, you, the weather; their level of influence; the benefit they get from the solution; any usage constraints, etc.).

This step should not be skipped — it’s rarely irrelevant. The key is to use every trick in your toolkit to avoid overlooking important stakeholders. Missing a critical one is a significant business analysis risk (see section 1.4).

The result should be a table listing stakeholders, their roles (e.g., client, users, SMEs, dev team and roles within it), and any useful parameters.

Maximilian Petrovich, client. Value: achieving business goals.
Sales team staff, direct users. Value: reducing manual work. Access: require VPN to the local network.
Payroll department, indirect users (receive reports). Value: accurate reporting. Attitude: extremely negative, irritated by system changes.

2.2. Planning Stakeholder Interactions

(Merges BABOK’s .2 Define Stakeholder Collaboration and .3 Stakeholder Communication Needs)

For each stakeholder group, think about:

How often and when to communicate (e.g., don’t ping your grumpy PM too often — batch questions and updates).
Reasons for communication (when it's necessary to approach them).
Their location and how it impacts communication (e.g., client in a different time zone — hello, late-night calls).
Communication channels and tools (e.g., email for client, walk over to devs’ desks).
Their preferences (ask which messenger the client likes and install it — keep the boss happy).
How much detail to share (e.g., give the dev team full SRS to read at night; present the client with summaries during calls).
Formality level (e.g., polished emails to the client; casual Slack with their employees — you’ve already shared a beer with them).

Key tool here: Communication Plan (a table summarizing the above points as needed).

Example

3. Plan Business Analysis Governance

3.1. Decision Making

At this stage, we need to think through who and how will make decisions on various business analysis-related matters:

Identify the stakeholder(s) who will have the final say. Usually, it's the client, but in more complex cases, there may be multiple decision-makers for different areas. For example, we’ll go to Maximilian Petrovich to resolve conflicts between requirements from different user groups; we'll escalate communication issues with external stakeholders to PM Afanasy; and John will have the final approval on solution requirements and their priorities. The key is to ensure that a decision-maker (or a few, depending on the context) is defined — avoid ending up in a “no one wants to decide, and I have five top stakeholders with equal influence, all pulling in different directions” situation.
If relevant, define how decisions will be made — by a single person, through voting, or using a more sophisticated algorithm. Rarely comes up for a typical analyst, but it’s worth keeping in mind just in case.

3.2. Change Control Process

In a more mature setup, this can include the following:

Process for handling change requests. For example: The author sends the request to analyst Bob → Bob performs an impact analysis → Bob passes the estimate to the development team → Bob relays the estimate to the client → Bob waits for the final decision. In an agile setup, this process could simply translate to creating a new backlog item placed according to its priority.
Information to include and work through in each request. For instance: author, business value, user value, project risks, and development estimate from the tech team.
Prioritization approach for change requests — what criteria, which techniques, and which people will be involved in prioritizing them among all others.
Who and how will perform the impact analysis — i.e., analyzing how a change will affect the solution. For example, if the client's interest rate formula changes, how many documents or components must be updated? Most likely, you or a designated analyst on the team will handle this. This is usually facilitated through a solid traceability system in documentation (see section 4.3).

3.3. How We Will Prioritize Requirements

Here, think through who and how will take part in prioritizing different types of requirements (business goals, scope items, quality attributes, etc.). Define the prioritization technique, the process, and its participants.

We are going to hold dedicated meetings with the client before each sprint to prioritize the current list of “wants.” Prioritization could be done by reordering backlog items accordingly.

3.4. Requirements Approval Approach

We know that approval processes can range from highly formal (literal paper signatures) to very informal (client hears it on a call, waves it off, and gives the go-ahead for development). In any case, it’s worth deciding:

Who the decision-maker is for different types of requirements (overlaps with section 3.1);
At what moments they make those decisions (e.g., during the transition to development phase, at the start of each iteration, or on an ad hoc basis as requirements are fleshed out);
In what format this approval takes place (e.g., emailing the specification for approval).

4. Plan Business Analysis Information Management

Let’s keep this brief and to the point — the items are fairly straightforward, but it’s crucial not to overlook them.

4.1. How Will We Organize Information (Especially Requirements)?

Here, for example, we might decide to write separate Word specifications for each solution module, plus a general spec tying them all together. Or we might choose to use Confluence, in which case we’ll define a structure and page templates for user stories.

4.2. How Detailed Should Information Be for Different Audiences?

For instance, we may define that the Vision and Scope document will outline features in broad strokes, while the specifications will be highly detailed and written in the development team’s terminology.

This point overlaps with section 1.2, and it doesn’t really matter where exactly this gets addressed, as long as it does get addressed.

4.3. How Will We Ensure Information Traceability?

What mechanisms will we use to explicitly link pieces of information?

For example, we might rely on hyperlinks in documents — each feature will explicitly reference the business requirement it supports. We’ll maintain a catalog of business rules and annotate where requirements originate from them, with references back to the parent rule.

4.4. Approach to Reusability of Information

Chances are, you won’t need to overthink this, but it’s still worth mentioning. For instance, you might recognize that it makes sense to keep a separate catalog of business rules for the client organization, as these rules may be reused across multiple projects. In that case, you’d plan to structure it accordingly and ensure analysts from various projects can contribute collaboratively.

4.5. Where Will We Store Information and How Will Access Be Managed?

For example, we’ll store specifications on Google Drive. Therefore, Bob will need to set up the infrastructure and configure version history. Editing access will be granted to analysts, while read-only access goes to the client and the development team.

4.6. Will We Bother with Requirement Attributes, and If So, Which Ones?

Requirement attributes are additional metadata about the requirement (beyond the content itself).

Here’s what we’ll track:
Unique ID (for epics, user stories, and quality attributes);
Author (which analyst added the requirement — tracked for user stories so we know who to poke if something goes wrong);
Priority (not written explicitly — backlog order reflects priority);
Source (trace link to parent requirement, business rule, or stakeholder that generated this requirement);
Status (e.g., draft, proposed, approved, developed, tested, met Definition of Done).

That’s pretty much it. You can document all of this in a grand “BA Plan” or “BA Approach,” jot it down in informal notes (a mind map, a Confluence section, chocolate wrapper notes, etc.), or even just keep it all in your head — plans don’t have to be written down. Think about how many “project” plans you carry around in your brain. The main thing is not to suffer for it later.

To reiterate: the key action when you first get involved in a project (and occasionally after that) is to go through each of these points like a checklist. Spend at least a few seconds on each — even just to think, “I don’t need this — I’ll skip it.”

What happens if you don’t? Is it OK for you, if...

“Huh, my team avoids reading the specs. Maybe I should talk to the PM... Wait, did I even consider whether the specs are clear and useful for them?”

“The client stopped responding... Oh no, they’re on vacation! Maybe a pre-agreed communication plan would’ve helped?”

“Whoa — turns out users are exporting our reports to pass them on to Finance. Crap, did we even check the format Finance needs? Guess they’re indirect users we didn’t account for.”

“The client just threw a ton of change requests at us. Do they even know we’re on a fixed-price contract and this won’t be done for free, overnight? No? Now what?”

“The client never reads the specs we send. Maybe now’s the time to ask whether they understand what they’re for, what we expect from them, and whether they’re even capable of reviewing them?”