Planning Before the Project Gets Complicated
Business analysis planning is not a paperwork exercise. It is the discipline of deciding how the change will be understood, who must participate, how decisions will be governed, how information will be managed, and how success will be measured.
1. Start With the Big Picture: Business Analysis Is About Change
The presentation begins with the Business Analysis Core Concept Model (BACCM). Around the central idea of business analysis are six connected concepts: Change, Need, Solution, Stakeholder, Value, and Context.
Core Concept Model
(BACCM)
The value of this model is that it prevents the analyst from looking at a project as merely a list of features. A project introduces change. That change exists because there is a need. A solution is created or changed to respond to that need. Stakeholders are affected by, contribute to, or influence the change. Everything happens inside a particular context, and the ultimate question is whether the change creates value.
The planning question is therefore bigger than “What are the requirements?”
Before requirements are gathered, the BA needs to understand what kind of change is happening, what need is being addressed, what solution is being considered, and who will define whether the outcome is valuable.
The presentation suggests three useful questions to anchor the work:
- What are the kinds of changes we are doing?
- What are the needs we are trying to satisfy?
- What are the solutions we are creating or changing?
These questions look simple, but they stop a BA team from racing directly into solution mode. A team can spend months improving a solution while never challenging whether it solves the real need.
2. Define Success First
One of the strongest pointers in the presentation is remarkably short: “Success must be defined first.”
This is a planning principle, not merely a project-management slogan. If success is unclear, the team cannot make good decisions about scope, priorities, stakeholder trade-offs, or measurement.
Imagine a customer-service organization that wants to introduce automation and machine learning for handling customer queries. A weak definition of success would be: “Launch an AI chatbot.”
That describes an output. It does not describe a successful business result. A stronger view asks what the organization is actually trying to achieve: faster response, greater availability, fewer repetitive manual interactions, improved consistency, better customer experience, or some combination of these.
Once success is defined, the BA can work backwards. Which needs must be satisfied? Which stakeholders should help shape the solution? Which requirements matter most? Which risks threaten the outcome? Which measures will tell us whether the change worked?
3. Choose the Business Analysis Planning Approach
The presentation emphasizes that projects introduce change and that the BA needs to determine the BA planning approach first. It presents three broad possibilities: plan-driven, adaptive-driven change, and a combination approach.
Plan-driven
The BA work emphasizes elicitation, analyzing, documenting, verifying, and communicating requirements. The approach works well when the work benefits from a more deliberate sequence and more defined requirements.
Adaptive-driven
The BA focus is on high-level requirements and their dynamic prioritization. The detailed understanding evolves as the team learns more.
Combination approach
Different parts of the initiative can use different planning styles. Stable or highly controlled areas can be planned in detail while uncertain areas evolve iteratively.
When should the approach change?
The approach is not sacred. It should reflect the nature of the change. A compliance-heavy initiative may demand detailed documentation and formal verification. A new product with uncertain customer expectations may need short learning cycles and reprioritization. A transformation can require a combination of both.
A common planning mistake: selecting an approach because that is how the organization “usually does projects.”
A mature BA adapts the planning method to the uncertainty, complexity, risk, stakeholder environment, and type of change rather than forcing every initiative into the same template.
4. The Project Manager Is a Key Partner
The presentation explicitly calls out the PM as a very important figure. This matters because BA planning and project planning cannot be separated completely. The BA may define how requirements and analysis will be handled, while the project manager coordinates schedule, resources, dependencies, risks, and delivery.
A productive BA–PM relationship creates alignment around questions such as: what needs to be understood first, which stakeholder sessions are critical, when requirements are needed by the delivery team, where decisions may block progress, and how emerging changes affect the project plan.
Think of the BA plan as one part of the overall project operating model. It should fit the project's delivery rhythm instead of becoming a separate administrative process.
5. Stakeholder Engagement: Analyze the People, Not Just the Org Chart
Stakeholders are central to business analysis because they hold information, make decisions, experience the change, influence adoption, or can block progress. The presentation distinguishes between supporters, fence-sitters, and opponents. This is a useful reminder that stakeholder attitude matters as much as stakeholder position.
Three practical ways to analyze stakeholders
- Note popularity and influence. Understand who is listened to, who has formal authority, who shapes opinions, and who can accelerate or slow the initiative.
- Write the personal impact. Consider how the proposed change affects each stakeholder's responsibilities, incentives, workload, risks, status, or day-to-day behavior.
- Record norms of communication. Understand how each stakeholder prefers to interact, what information they expect, and how decisions are normally communicated.
This moves stakeholder analysis from a static list toward an engagement strategy. Two people with the same job title may require entirely different approaches because one is an enthusiastic supporter and the other sees the initiative as a threat to established ways of working.
Use clear responsibility categories
The presentation highlights four categories that help clarify how people participate in the work:
The people who carry out the work or provide the subject-matter contribution required to complete it.
The person who owns the overall responsibility for the outcome or decision.
People who provide a relevant perspective before a decision or deliverable is finalized.
People who need visibility into progress, decisions, or outcomes without being active decision-makers for every item.
Making these roles explicit prevents a classic project problem: everyone is “involved,” but nobody is sure who is actually expected to act or decide.
6. Governance: Decide How Decisions Will Be Made
Governance is the structure that keeps requirements, decisions, approvals, and changes from becoming arbitrary. The presentation puts particular attention on requirements approvals and authorizations.
A practical governance plan should make the following explicit:
- Who has authority? Identify the people or groups who can approve requirements, scope decisions, or exceptions.
- What information is required? Decision-makers need the right evidence, not simply more documentation.
- How are changes requested? Define a clear change-request path rather than allowing changes to arrive informally through meetings and messages.
- How are items reviewed and approved? Establish review cycles, decision points, and escalation mechanisms.
- How is communication handled? Make sure affected stakeholders understand what was decided and what it means for them.
The change control process
The deck describes change control as the set of boundaries that determine what is an acceptable change versus what should trigger escalation and potentially executive decisions.
The key is not to eliminate change. Changes are normal. Good governance makes change visible, evaluated, authorized, and traceable.
7. Manage Business Analysis Information for Long-Term Use
The deck explicitly points to business analysis information management and the requirements traceability matrix. This is an important transition: the BA is not merely collecting information for today's workshop; the information should remain useful throughout the project.
Know what already exists
Before creating new documents, look for existing requirements, process descriptions, business rules, data definitions, prior decisions, software documentation, reports, and other artifacts. Re-creating information that already exists creates inconsistency and wastes analysis effort.
Document the origin and meaning of the requirement
The presentation identifies several key elements of documentation:
| Documentation element | Why it matters |
|---|---|
| Source of the requirement | Shows where the requirement came from and helps validate whether the source is still relevant. |
| Owner of business need | Connects the requirement to a person or business area that has a real stake in the outcome. |
| Detailed description of the need | Preserves the business reasoning instead of leaving only a feature statement. |
| Complexity and urgency of the need | Helps the team make better prioritization and planning decisions. |
| Impacts | Makes downstream effects visible to business and delivery teams. |
| Risks of action or inaction | Shows what may happen if the organization implements the change—or chooses not to. |
Priority, approver, and the ability to track changes
The presentation recommends considering priority, approver, and the ability to track changes as part of the documentation.
These three ideas are powerful because they make a requirement operational: priority tells the team how important it is, approver identifies who can authorize it, and change tracking provides a history of how it evolved.
Connect requirements to test scenarios
The deck also recommends linking requirements to test-case scenarios. This creates a practical chain from business need to implementation and validation.
When this connection exists, it becomes much easier to answer: Why are we building this? How do we know it is complete? What business objective does this test support? What changed when the requirement changed?
8. Build a Common View of Success
The presentation uses this idea to emphasize alignment on a common view of success with stakeholders. A BA may believe a project is successful because the system has been delivered on time, while a customer-experience team may judge success using adoption, satisfaction, turnaround time, complaint volume, or some other outcome.
A planning conversation therefore needs to move beyond: “What will we deliver?” and toward: “What will success look like for the people who depend on the change?”
Define useful performance indicators
The deck offers several examples of BA performance indicators:
How many requirement issues are significant enough to be escalated for approval?
How many changes are being introduced against the original requirements?
How often are important requirements, stakeholders, or systems discovered late?
The deck also recommends tracking issues and risks for the entire duration of the project. This matters because BA risk does not end after requirements are approved. New information, stakeholder changes, technical constraints, and business conditions can all create new risks.
9. Continuous Improvement: The Plan Is Not the Finish Line
A strong BA process does not assume that the original plan was perfect. Instead, it creates mechanisms to learn and improve as the work progresses.
Define performance criteria for the BA work and make expectations visible to stakeholders.
Use feedback to understand where the analysis is falling short and where the team can improve.
Turn lessons from the current initiative into better planning, analysis, and engagement practices.
The SESI cycle
The final part of the presentation gives a compact four-step improvement cycle labeled SESI:
Continuous improvement means improving the analysis system itself. The question is not only “Did we produce the requirements?” It is also “Did our way of working help the organization make better decisions?”
10. Use Information to Your Advantage
One of the later sections of the presentation asks: “How do you use information to your advantage?” The answer is broader than document management. It is about using information to increase business understanding before committing to a solution.
Understand the external environment, competitive pressures, customer expectations, and forces shaping the problem.
Break a broad problem into understandable parts instead of treating it as one large requirement.
Understand how the organization actually works today, including workarounds and pain points.
Clarify what the project is ultimately expected to accomplish and how the result will be judged.
Look beyond formal roles to understand behavior, influence, motivation, concerns, and culture.
Understand the organizational structure and where authority, knowledge, and dependencies actually sit.
Connect the project to the organization's purpose, vision, and strategic priorities.
Learn from previous work and the lessons that should influence today's analysis and decisions.
Understand what else is happening in the organization because initiatives compete for people, budget, and attention.
This is where a BA becomes more than a requirements collector. The analyst uses information to understand why the organization needs change, what constraints already exist, and where the proposed project sits within the larger business system.
11. Example: Planning an Automation and Machine-Learning Change
You are the lead business analyst. Your team must introduce automation and machine learning for handling customer queries, and you are responsible for organizing the work for the team.
Step 1: Clarify the change
The change is not simply “deploy machine learning.” The change affects how customer questions are handled, who handles them, how cases are routed, what information is made available, and how customers experience the service.
Step 2: Define the need and success
Clarify what business problem is being solved and define a common view of success with stakeholders. Avoid assuming that automation is valuable merely because it is technically impressive.
Step 3: Choose the BA approach
If the business already understands the target process and the scope is stable, a more plan-driven approach may be appropriate. If the organization is still discovering where machine learning can safely and effectively help, an adaptive or combination approach may be more useful.
Step 4: Analyze stakeholders
Potential stakeholders could include customer-service leaders, front-line agents, customers, technology teams, data owners, compliance or risk teams, and project leadership. For each one, assess influence, personal impact, and communication needs.
Step 5: Establish governance
Decide who is accountable, who must be consulted, who authorizes requirements, how change requests are reviewed, and what types of changes require escalation.
Step 6: Manage requirements and information
Record the source and owner of each significant requirement, its priority, complexity, urgency, impacts, and risks. Keep an auditable path between requirements and test scenarios.
Step 7: Measure the BA process
Monitor requirement issues, change requests, missed requirements, unresolved risks, and other indicators that show whether the analysis approach is helping the project.
Step 8: Review and improve
Seek stakeholder input, expect changes, schedule reviews, and integrate improvements into the ongoing work.
12. What a Good BA Planning Package Should Make Easy
At the end of planning, a person joining the initiative should be able to understand the operating model of the analysis work quickly. At minimum, the plan should make it easy to answer:
Approach: How will business analysis be performed?
Stakeholders: Who needs to participate and in what way?
Governance: Who has authority to approve, reject, prioritize, or escalate?
Information: Where does business analysis information live, and how will it remain usable?
Change: How are new or changed requirements handled?
Success: What evidence will show that the business outcome is being achieved?
Improvement: When and how will the BA process itself be reviewed?
If those answers are clear, the BA team has a working foundation. If they are not, requirements activities can still begin—but the project is likely to spend more time resolving avoidable confusion later.
13. Common Mistakes to Avoid
Starting with features instead of the need
“We need an app” or “we need AI” is a proposed solution, not a fully articulated business need. Planning should force the team to understand the change before optimizing the solution.
Confusing participation with influence
Inviting someone to every meeting does not guarantee meaningful engagement. Stakeholders should receive the kind of involvement that matches their influence, knowledge, and impact.
Allowing informal changes to bypass governance
When requirements change through side conversations, chat messages, or undocumented decisions, the team eventually loses control of scope and traceability.
Documenting without preserving context
A requirement without its source, owner, business need, priority, and rationale can become difficult to interpret later.
Measuring delivery instead of business analysis quality
Finishing workshops or producing documents does not by itself prove that the analysis was effective. Look at requirement issues, changes, missed needs, risks, and stakeholder alignment as well.
Treating the plan as a one-time artifact
A plan that is never reviewed will eventually describe a project that no longer exists. Continuous improvement is part of the operating model.
14. A Practical BA Planning Checklist
Before moving into intensive requirements work, walk through the following sequence:
- Understand the change. Describe what is changing and why the organization is considering it.
- Clarify the need. Separate the underlying need from the initial solution idea.
- Define success. Agree on what a valuable outcome looks like.
- Select the approach. Decide between plan-driven, adaptive-driven, or a combination approach.
- Map stakeholders. Assess supporters, fence-sitters, opponents, influence, impact, and communication norms.
- Set governance. Define authority, approvals, change control, review, and escalation.
- Design information management. Decide where information lives and how traceability and change history will be maintained.
- Define performance indicators. Decide how BA effectiveness will be monitored.
- Schedule improvement cycles. Make reviews explicit rather than hoping improvement will happen automatically.
- Implement the plan. Put the agreed approach into day-to-day practice and adjust it as the initiative evolves.
15. The Deeper Lesson: Planning Is an Enablement Activity
Business analysis planning can look like preparation for “the real work.” The presentation makes a stronger case: planning is part of the real work.
A clear plan helps analysts focus their analytical skills, keep the work aligned to the business, and create a repeatable way to learn and improve.
It also changes the role of the BA. Instead of being the person who documents what everyone else says, the BA becomes the person who helps the organization create a shared understanding of: the change, the need, the solution, the stakeholders, the context, and the value.
That is why the planning question should come early: How should we organize our analysis so that the project can make better decisions?
Conclusion: Implement the Business Analysis Plan
The final message of the presentation is practical: the key is not only creating the plan, but also putting it into operation.
A business analysis plan has value only when it changes how people work. Stakeholders know how they are expected to participate. Decision-makers know when and how approvals happen. Requirements have context and traceability. Changes follow a visible path. Performance is reviewed. Lessons become improvements.
In that sense, effective BA planning is less about producing a document and more about establishing a reliable system for turning business uncertainty into shared understanding and informed action.
No comments:
Post a Comment