4 Business Analysis Planning and Monitoring
In the previous chapter, we explored how organizations decide what problems to solve. Now we shift to how Business Analysts plan and organize their work once a project begins. This chapter covers the Initiation Phase, where plans take shape and the foundation for successful analysis is laid.
Business Analysis Planning and Monitoring might sound administrative, even boring. I understand that reaction. But consider this: projects fail far more often from poor planning than from technical problems. Teams that skip or rush through planning consistently struggle later. The time invested in planning pays dividends throughout the project.
4.1 The Five Tasks of Business Analysis Planning and Monitoring
This knowledge area encompasses five main tasks. Each one addresses a different aspect of preparing for and managing Business Analysis work.
The first task is planning the Business Analysis approach. The second is planning stakeholder engagement. The third is planning Business Analysis governance. The fourth is planning Business Analysis information management. The fifth is identifying Business Analysis performance improvements.
Let me examine each task in depth.
4.2 Planning the Business Analysis Approach
Every project has unique characteristics. The problem being solved, the organization’s culture, the available resources, the timeline constraints, and many other factors shape how Business Analysis should be conducted. Planning the Business Analysis approach means determining what activities are needed, what deliverables will be produced, how much effort each activity will require, and how progress will be measured.
Several considerations guide this planning. The approach should match the problem or opportunity the organization faces. It should account for what is known about the business need at the time of planning. It should acknowledge that understanding evolves throughout business analysis activities. What seems clear at the beginning may become more complex, or simpler, as work progresses.
Two broad categories of approaches exist. Plan-driven approaches, associated with Waterfall methodologies, emphasize formality, upfront planning, and control. Most Business Analysis work happens at the beginning or during a specific dedicated phase. Deliverables require significant documentation using standard templates. Documents must be approved before subsequent work begins. Change is managed through formal processes.
Change-driven approaches, associated with Agile methodologies, emphasize communication and flexibility. Business Analysis work occurs throughout the project lifecycle in every iteration. Requirements are defined through team interaction with less formal documentation. Additional documentation is discretionary and often produced after the solution is implemented. Changes are simply prioritized along with other work items.
Neither approach is inherently better. The right choice depends on the situation. Many organizations use elements of both, adapting their approach to fit specific project characteristics.
4.3 A Planning Analogy: Making Coffee
To illustrate planning concepts, consider something simple: making a cup of coffee.
What is the goal? To make a good cup of coffee. What inputs do you need? Coffee grounds, water, a cup, and brewing equipment. What steps are required? You must measure the coffee, add water, brew it, and pour it. What is the output? A cup of coffee. How do you know if you succeeded? You taste it.
This simple example demonstrates the basic planning questions that apply to any activity. What are we trying to accomplish? What resources do we need? What steps will we follow? What will we produce? How will we know if we succeeded?
Business Analysis planning asks these same questions, just with more complexity. What requirements artifacts will we produce? Who will provide input? What techniques will we use to gather and analyze information? How long will each activity take? What tools will help us work efficiently?
4.4 Techniques for Planning Business Analysis Activities
Two techniques deserve special attention in planning.
Functional decomposition helps manage complexity by breaking down processes, systems, functional areas, or deliverables into simpler constituent parts. Each part can then be analyzed independently. When you face a large, overwhelming task, decomposition makes it manageable.
Think about planning a wedding. The overall task is enormous. But if you decompose it into venue selection, catering, invitations, decorations, music, photography, and other components, each becomes manageable. You can estimate time and cost for each component. You can assign different people to different tasks. You can track progress on each piece.
A Work Breakdown Structure (Figure 4.1) applies this same principle to project work. It organizes all project work into manageable pieces, enabling assignment, estimation, and tracking.
Estimation determines how long Business Analysis activities will take. Good estimation is difficult but essential. Underestimating leads to rushed work, missed deadlines, and quality problems. Overestimating wastes resources and may cause projects to be cancelled that should have proceeded.
The key to better estimation is decomposition. Estimating how long “Business Analysis” will take is nearly impossible. Estimating how long it takes to conduct five stakeholder interviews, document findings, and create a process model is much more feasible.
4.5 The Making a Basket Story
The slides include a story about making baskets that illustrates communication challenges in planning. Let me retell it here because the lesson matters.
A manager tells an employee to make a basket. The employee goes to work. But the manager had a specific type of basket in mind that was never communicated. The employee makes a basket, but it is not what the manager wanted. Frustration follows on both sides.
This scenario plays out constantly in organizations. Managers assume their expectations are obvious. Employees assume they understand what is needed. Neither party confirms their understanding with the other. The result is wasted effort and damaged relationships.
Business Analysts learn to avoid this trap. They ask clarifying questions even when tasks seem clear. They confirm understanding by restating what they heard. They use visual models and prototypes to surface misunderstandings early. They treat communication as an ongoing activity, not a one-time event.
4.6 Planning Stakeholder Engagement
Stakeholders are individuals or groups who participate in a change initiative or will be affected by it. Planning stakeholder engagement means determining how Business Analysts will establish and maintain effective working relationships with these people.
Why does stakeholder engagement deserve explicit planning? Because stakeholders are the source of requirements. Because stakeholders will use, support, or be affected by the solution. Because stakeholder buy-in determines whether solutions get adopted. Because stakeholder resistance can derail even technically excellent projects.
4.7 Identifying Stakeholders
The first step in stakeholder engagement is identifying who your stakeholders are. This is not as obvious as it might seem.
For internal stakeholders, start with organizational charts, business process documentation, and information from the project sponsor. Who performs the work being affected? Who manages those performers? Who depends on their outputs? Who approves decisions in this area?
For external stakeholders, analyze existing contracts, identify anticipated vendors, consider regulatory bodies that may influence the work, think about shareholders who have financial interests, and remember customers who will ultimately use or benefit from the solution.
4.8 Why Identification Matters
You might wonder why I make such a point of identifying stakeholders. The answer involves several factors.
More minds generate more ideas. Stakeholders you never consulted might have insights that transform your understanding of the problem or solution.
Varied perspectives improve solutions. What looks perfect from one viewpoint may have serious flaws from another. Finance sees different things than operations. Customers see different things than employees.
Early involvement builds buy-in. People support what they help create. Excluding stakeholders from the analysis process makes them more likely to resist the eventual solution.
Demonstrating that you care about stakeholders increases credibility. When people see that you took time to understand their concerns, they trust you more and share information more freely.
4.9 Stakeholder Roles
Different stakeholders play different roles. Understanding these roles helps you work with each one effectively.
The Business Analyst is a stakeholder in all business analysis activities, responsible and accountable for execution.
Customers use or may use the products or services of the enterprise and may have contractual or moral rights.
Domain Subject Matter Experts possess in-depth knowledge of topics relevant to the business need or solution scope. This category includes end users, managers, process owners, and legal staff.
End Users directly interact with the solution, including all participants in a business process.
Implementation Subject Matter Experts have specialized knowledge regarding implementing solution components, such as solution architects, developers, and database administrators.
Operational Support handles day-to-day management and maintenance of systems, including help desk staff and release managers.
Project Managers deliver solutions while balancing scope, budget, schedule, resources, quality, and risk.
Regulators define and enforce standards, including government bodies and auditors.
Sponsors initiate efforts to define business needs and develop solutions, authorizing work and controlling budget.
Suppliers provide products and services from outside the organization.
Testers determine how to verify that solutions meet requirements and conduct verification processes.
4.10 Stakeholder Analysis
Once you identify stakeholders, you need to understand them. Stakeholder analysis examines several dimensions.
Figure 4.2 shows one way to think about stakeholder engagement. The Power-Interest matrix positions stakeholders based on their power to influence outcomes and their interest in the initiative.
Attitudes matter enormously. How does each stakeholder feel about the business goals? About the initiative? About proposed solutions? About Business Analysis in general? About the sponsor? About other stakeholders? About collaborative approaches? Understanding attitudes helps you anticipate support and resistance.
Decision-making authority defines who can approve what. Identify the authority level each stakeholder has over Business Analysis activities, deliverables, and changes. Knowing who can say yes and who can say no prevents frustration and wasted effort.
Level of power or influence shapes how you engage. Some stakeholders have formal authority. Others have informal influence that may matter more. Understanding influence structures helps you build relationships and navigate organizational politics.
4.11 The RACI Matrix
The RACI matrix (Figure 4.3) is a powerful tool for clarifying roles and responsibilities. RACI stands for Responsible, Accountable, Consulted, and Informed.
Responsible identifies who does the work. This is the person or people who actually perform the task or create the deliverable.
Accountable identifies who ultimately answers for the work. This person ensures quality and completeness. Only one person should be accountable for any given item.
Consulted identifies whose opinions are sought. These are typically subject matter experts with whom two-way communication occurs before decisions are made.
Informed identifies who needs to know about decisions and progress. This is one-way communication after decisions are made.
Several rules make RACI matrices effective. Only one person should be Responsible and Accountable for each item. Having multiple people accountable creates confusion and diffuses responsibility. The Consulted and Informed roles are not mandatory for every activity; some tasks may not require them. Consulted involves dialogue; Informed involves notification.
Consider a simple example: making a birthday cake. Who is Responsible for baking? Who is Accountable for the overall celebration? Who should be Consulted about flavor preferences? Who should be Informed about the party details? Working through these questions clarifies how people will work together.
4.12 Defining Stakeholder Collaboration
Planning how collaboration will occur requires explicit attention. Collaboration can happen spontaneously, but much of it should be deliberate and planned.
Consider timing and frequency. How often will you meet with key stakeholders? Are there regular touchpoints or ad-hoc meetings?
Consider location. Where are stakeholders physically located? Do geographic distances require special arrangements?
Consider available tools. Wikis, online communities, video conferencing, and collaboration platforms can support stakeholder engagement.
Consider delivery methods. Will communication be in-person or virtual? Written or verbal? Formal or informal?
You may need different collaboration approaches for different stakeholders. Internal team members might meet daily, while external regulators might receive formal monthly reports.
4.13 An Important Principle
I want to share something that took me years to learn: never make your stakeholder look stupid.
This might seem obvious, but it is surprisingly easy to violate. You ask a question in a meeting that reveals someone did not do their homework. You point out a flaw in their reasoning in front of their peers. You share information that exposes their mistake.
When you make someone look stupid, you damage the relationship. That person becomes defensive, shares less information with you, and may actively resist your recommendations. Even if you are right, you lose.
Instead, frame your expertise as service to stakeholders. Help them look good. Make their jobs easier. When you need to raise concerns, do it privately rather than publicly. When you discover problems, present them as shared challenges rather than personal failures.
This is not about being dishonest or avoiding difficult conversations. It is about having those conversations in ways that preserve relationships and enable progress.
4.14 Planning Business Analysis Governance
Governance defines how decisions are made about requirements and designs, including reviews, change control, approvals, and prioritization.
The decision-making process defines what happens when teams cannot reach consensus, by identifying escalation paths and key stakeholders who hold final decision-making authority.
The change control process determines how changes to requirements are handled. Which requirements does change control cover? What are the steps for proposing changes? When can changes be proposed? Who can propose them? How will change requests be communicated?
The prioritization approach determines how requirements will be ranked relative to each other. What factors influence priority? Who participates in prioritization decisions?
The approval process determines what types of requirements need approval, when approvals occur, who approves what, and where approvals happen.
4.15 Planning Business Analysis Information Management
Business Analysis generates enormous amounts of information. Planning information management develops an approach for how this information will be stored and accessed.
This information includes everything Business Analysts elicit, create, compile, and disseminate: models, scope statements, stakeholder concerns, elicitation results, requirements, designs, solution options, user stories, formal requirement documents, and functioning prototypes.
Organization ensures information is well-structured so it is not difficult to locate, does not conflict with other information, and is not needlessly duplicated.
Level of abstraction determines how detailed information will be. Representations may range from highly conceptual or summarized to very detailed.
Traceability approach determines how you will keep track of requirements status or progress during the lifecycle of the project.
Storage and access decisions depend on who must access the information, how often they need to access it, and what conditions must be present for access.
Requirements attributes provide information about requirements and aid in management. Commonly used attributes include unique identifiers, author names, complexity ratings, ownership assignments, priority levels, associated risks, source references, stability indicators, status markers, and urgency flags.
4.16 Identifying Business Analysis Performance Improvements
Performance analysis assesses Business Analysis work and plans improvements where required. This should occur throughout an initiative, not just at the end.
Possible measures include accuracy and completeness (correctness), knowledge (whether the analyst is skilled), effectiveness (how easy deliverables are to use), organizational support (whether adequate resources were available), significance (whether the work was justified), strategic alignment (whether objectives were met), and timeliness (whether work was delivered on time).
Once potential improvements are identified, they become guidelines for the next time similar tasks are executed.
4.17 Case Example: The CRM Implementation
Consolidated Financial Services decided to implement a new Customer Relationship Management system. The project had executive sponsorship, adequate budget, and a clear timeline.
The Business Analyst assigned to the project was experienced and competent. But she made a critical mistake: she skipped stakeholder analysis. She assumed she knew who mattered. She focused on the sales team, who would be the primary users, and the IT department, who would implement the system.
She missed several important stakeholders. The compliance department had specific requirements about data retention and customer communication that were not captured until late in the project. The customer service team needed access to sales information to serve customers effectively, but this integration was not planned. The marketing department expected the CRM to support campaign management, but nobody had discussed this with them.
As implementation progressed, the overlooked stakeholders raised concerns. Some requirements were easy to add. Others required significant rework. Scope expanded. Timeline slipped. Budget overruns followed.
Even worse, the overlooked stakeholders felt disrespected. They had been excluded from decisions that affected their work. Some actively resisted the system even after their requirements were addressed.
The project was eventually completed, but it took eighteen months longer than planned and cost nearly double the original budget. Most of the overruns traced directly to inadequate stakeholder identification at the start.
The lesson is clear. Stakeholder analysis is not optional. The time invested in identifying and understanding stakeholders pays dividends throughout the project. Skipping this step creates problems that are far more expensive to fix later.
Now that you understand how to plan Business Analysis work and engage stakeholders effectively, let us move on to the heart of the discipline: eliciting requirements from stakeholders.
4.18 Review Questions
In a RACI matrix, which role involves two-way communication before decisions are made?
- Responsible
- Accountable
- Consulted
- Informed
Which technique breaks down complex processes into simpler parts for analysis?
- SWOT Analysis
- PESTLE Analysis
- Functional Decomposition
- Root Cause Analysis
According to RACI rules, how many people should be Accountable for any given item?
- At least two for redundancy
- Exactly one
- As many as needed based on complexity
- The same number as Responsible
Change-driven (Agile) approaches typically:
- Front-load all Business Analysis work before development
- Require formal approval of all documents
- Distribute Business Analysis work throughout the project in iterations
- Eliminate the need for any documentation
The principle “Never make your stakeholder look stupid” reflects:
- A legal requirement
- A strategic approach that builds relationships and enables progress
- A suggestion only for difficult stakeholders
- An outdated professional norm
1-c, 2-c, 3-b, 4-c, 5-b