Hello! Welcome to the final lesson in our "Foundations of Business Analysis" module.
In our last lesson, you mastered how to identify and analyze project stakeholders, mapping them to understand their power and interest. This is crucial because the people involved in a project directly influence how we should plan and execute our work. A project with a few co-located stakeholders who are unsure of their needs requires a very different plan than one with a large, geographically dispersed team working from a fixed regulatory contract.
Today, we'll build on that foundation. Your learning outcome is to plan a business analysis approach for a given project scenario. This means creating a clear roadmap that outlines the what, when, and how of all business analysis activities. Think of it as the BA's specific project plan within the larger project. Mastering this is essential for setting expectations, managing your workload, and demonstrating senior-level thinking in BA interviews.
What is a Business Analysis Approach?
Essentially, a BA approach is a documented plan detailing the method you'll use to conduct all business analysis activities for a project. It ensures that everyone—the project manager, developers, and stakeholders—is aligned on how requirements will be gathered, analyzed, documented, and managed.
The Business Analysis Body of Knowledge (BABOK®) formalizes this as a key process. The diagram below shows how a business's 'Needs' serve as the input, which are then processed using various techniques to produce the 'Business Analysis Approach' as the output.
To understand the core components that make up this plan, let's start with a video that walks through the key tasks defined by the BABOK.
How to do Business Analysis Planning & Monitoring? Business Analyst Course | BABOK Study - Part 1
This video, 'How to do Business Analysis Planning & Monitoring?' from Business Analysis Excellence, introduces the official BABOK knowledge area and breaks down the 'Plan Business Analysis Approach' task into its essential elements.
Please watch from 02:23 to 14:15. This covers the six key elements you need to consider when creating your plan: Planning Approach (predictive vs. adaptive) Formality & Level of Detail Business Analysis Activities Timing of BA Work Complexity & Risk Acceptance Focus on understanding what each element means, as we'll be building on them throughout this lesson.
As the video explained, one of the first and most critical decisions you'll make is choosing your overall planning approach: predictive (Waterfall) or adaptive (Agile). This choice has a ripple effect on everything else, from the type of documentation you create to how you interact with stakeholders.
The Core Decision: Predictive (Waterfall) vs. Adaptive (Agile)
Your project management background has likely exposed you to these concepts, but let's solidify them from a BA perspective.
-
Predictive (Waterfall): This is a traditional, linear approach where you define and document as much as possible upfront. The project moves through distinct phases (e.g., requirements, design, build, test), and each phase is completed before the next begins.
- BA Role: Heavily focused on creating comprehensive documentation at the beginning, like a detailed Business Requirements Document (BRD). Change is generally discouraged and costly.
-
Adaptive (Agile): This is an iterative approach that embraces uncertainty. Work is done in short cycles (sprints), delivering small, functional pieces of the product. Requirements are expected to evolve.
- BA Role: More of a continuous, collaborative role. The focus is on user stories, maintaining a product backlog, and constant communication with the team and stakeholders.
To see a practical comparison of how these two approaches affect the day-to-day work, the next video offers an excellent side-by-side view.
AGILE versus WATERFALL Project Plans
The video 'AGILE versus WATERFALL Project Plans' by David McLachlan provides a detailed comparison of how various project activities are handled in each methodology. It's broader than just BA work, but it beautifully illustrates the different mindsets.
Watch the following sections, paying close attention to the differences in the BA-related tasks: Eliciting Requirements (04:59 - 07:22) Creating Scope (07:22 - 11:01) Communication (22:15 - 24:42) Risk Management (24:42 - 26:17) Notice how Waterfall relies on formal documents and upfront planning, while Agile favors iterative feedback, user stories, and continuous communication.
How to Choose the Right Approach?
So, how do you decide between Waterfall and Agile? It's not about which is "better," but which is "fitter" for the project context. The following article provides a clear framework for making this decision.
The article 'Agile versus Waterfall' from the Project Management Institute (PMI) provides a set of evaluation criteria to help you decide which approach is best suited for your project.
Please read the section titled 'Evaluation Criteria to Determine the Best Approach for Your Project'. This section gives you a checklist of factors to consider, including project characteristics (like requirements clarity), sponsor characteristics, and project resources. This is an excellent tool for justifying your choice in a real-world scenario or an interview.
Test your understanding!
You are assigned as the BA on two upcoming projects. Based on the criteria you just read, would you recommend a predictive (Waterfall) or adaptive (Agile) approach for each? Briefly explain why.
- Project A: An upgrade to your company's internal ad spend reporting system to comply with a new, well-defined financial regulation. The deadline is fixed, and the requirements are spelled out in the legal documentation.
- Project B: The creation of a new mobile app feature for your AdTech platform that suggests optimal campaign bids using AI. The final form of the feature is unknown, and the team wants to get user feedback as quickly as possible.
Show answer
-
Project A: A predictive (Waterfall) approach is more suitable.
- Reasoning: The requirements are rigid, well-defined, and unlikely to change ("comply with a new, well-defined financial regulation"). The scope is fixed, and success is measured by complete compliance by a specific date. A linear, phase-gated approach works well here.
-
Project B: An adaptive (Agile) approach is the clear choice.
- Reasoning: The requirements are uncertain ("final form of the feature is unknown"), and there's a high need for customer feedback and adaptation. An iterative approach allows the team to build a small version, test it with users, learn, and adjust, which is ideal for innovative and user-centric features.
Documenting Your Plan: The BA Work Plan
Once you've decided on an approach and considered the key elements (activities, timing, risks, etc.), you need to document it. A formal Business Analysis Work Plan serves this purpose. This document is your charter, outlining your scope of work for the project.
The following resource is an excellent template with sample content that shows what a comprehensive BA Work Plan looks like.
A Template of Business Analysis Work Plan with Sample ...
This document, 'A Template of Business Analysis Work Plan with Sample...', provides a concrete example of how to structure your BA plan. It translates the theoretical elements we've discussed into a formal document.
Please review the document, focusing on these key sections which formalize our discussion: OVERVIEW: Understands the purpose of the plan. Section 4: PROPOSED BUSINESS ANALYSIS APPROACH: This is where you declare your choice (e.g., SDLC/Waterfall) and define your role and the techniques you'll use (interviews, workshops, etc.). Section 5: DELIVERABLES: This lists the specific documents you will produce (e.g., User Requirements Document). Section 6: WORK SCHEDULE: This outlines the BA activities across the project phases. Section 8: STAKEHOLDER: This section contains the Stakeholder Register, directly connecting to our previous lesson. Notice how it captures their expectations and influence.
As you can see, the BA Work Plan is a comprehensive document that leaves no ambiguity about your role, activities, and deliverables. It's a powerful tool for managing expectations.
Conclusion
Congratulations on completing the first module! You have now journeyed from the fundamentals of a BA's role to the strategic planning of their work. Planning a business analysis approach is the capstone of these foundational skills—it forces you to think critically about the project's context and select the right tools and techniques for the job.
Key Takeaways:
- A Business Analysis Approach is a formal plan detailing the BA's methodology, activities, deliverables, and schedule for a project.
- The choice between a predictive (Waterfall) and adaptive (Agile) approach is a fundamental decision driven by factors like requirements clarity, project complexity, and the need for flexibility.
- A comprehensive BA plan considers the approach, required formality, specific activities, timing, risks, and how success will be accepted.
- This plan is documented in a BA Work Plan, which aligns stakeholders and serves as the BA's roadmap.
Preview of the Next Lesson:
Your BA Work Plan will list key elicitation activities, such as workshops, document analysis, and interviews. In our next lesson, "Plan and conduct effective stakeholder interviews for requirements gathering," we will kick off the "Stakeholder Engagement and Requirements Elicitation" module by diving deep into the art and science of one of the most critical BA skills: interviewing stakeholders to uncover their true needs.