After your kick-off meeting, your desktop analysis, and your initial stakeholder conversations, you have what you need to do something important: put a plan in writing. That plan is the business analysis approach document, and it’s the foundation everything else is built on.
This is the sixth and final article in the series on how to start a business analysis project. The previous five articles walked through day one preparation, scheduling the kick-off meeting, desktop analysis, documenting your findings, and the questions to ask in your kick-off meeting. This article is about turning all of that into a formal approach document.
Why the Approach Document Matters
Project plans are often written from a delivery perspective. They cover timelines, milestones, resourcing, and governance. What they frequently don’t cover in any useful detail is the business analysis work itself: what the BA will do, how they’ll do it, what they’ll produce, and how they’ll engage with stakeholders.
The business analysis approach document fills that gap. It’s the definitive statement of your planned activities for the life of the project. It demonstrates that you’ve understood the project, thought carefully about what’s required, and have a credible plan for delivering it.
It also protects you. A well-written approach document creates a shared understanding with your project sponsor, project manager, and key stakeholders about what the BA work will involve and what it will produce. When scope starts to expand or expectations drift, the approach document is what you return to.
What the Approach Document Contains
The sections below reflect what I include in most approach documents. The level of detail in each section should match the scale and complexity of the project.
Purpose
A brief statement of what the business analysis activities are intended to achieve on this project. This isn’t a restatement of the project objectives: it’s a description of the role that business analysis plays in achieving them.
Objectives
The specific objectives of the business analysis component of the project. What will the BA work deliver, and how does that contribute to the broader project goals?
Background
A summary of the project context: what the organisation does, what led to this initiative, and what the impetus for change is. This section should give an unfamiliar reader enough context to understand why the project exists.
Scope
A clear definition of what is included in the business analysis activities and what is explicitly excluded. Scope boundaries are one of the most important things to establish early, and this section is where they’re formally documented.
Current Condition
A description of the problems, inefficiencies, and risks that currently exist in the areas being examined. This is drawn directly from your desktop analysis and kick-off meeting: the issues and risks that stakeholders have identified as the motivation for change.
Root Cause Analysis
An initial identification of the root causes underlying the issues described in the current condition. This doesn’t need to be exhaustive at the approach stage, but demonstrating that you’re looking for root causes rather than surface symptoms signals analytical rigour and helps ensure that requirements address the right problems.
Target Condition
A description of what the situation will look like if the project is successful. How will the issues identified in the current condition be resolved? What will be different for the people and processes affected? This section bridges the gap between the problem and the solution.
Critical Success Factors
The conditions that must be met for the project to be considered a success. These might include stakeholder engagement milestones, data quality thresholds, system performance standards, or organisational readiness criteria. Being explicit about success factors early helps everyone stay aligned on what the project is actually trying to achieve.
Planned Activities
A description of the business analysis activities that will be conducted across the life of the project, including the purpose of each activity, the deliverables it will produce, and the planned delivery dates. This is the operational heart of the approach document: the plan that your project manager and project sponsor will hold you to.
Quality Management
A description of the activities that will be undertaken to ensure the quality of your deliverables. This might include peer review processes, stakeholder sign-off requirements, or the use of structured templates and standards. Quality management doesn’t need to be elaborate, but it does need to be explicit.
Communications Strategy
An outline of how you’ll communicate with stakeholders throughout the project. This includes how often, through what channels, and for what purposes. Regular, structured communication with stakeholders is one of the most effective ways to maintain alignment and catch problems before they become serious.
Stakeholder Engagement Plan
An overview of the stakeholder engagement process: who will be engaged, when, through what methods, and for what purpose. This draws directly from the stakeholder identification work you’ve done in your kick-off meeting and initial conversations.
Requirements Management
A description of how requirements will be collected, analysed, documented, and managed throughout the project lifecycle. This includes your chosen requirements format (user stories, shall statements, or another convention), how requirements will be prioritised, how changes will be managed, and how traceability will be maintained.
Follow Up
A description of how you’ll measure the effectiveness of the project after delivery. This might include post-implementation review activities, benefit realisation tracking, or stakeholder satisfaction assessment. Not every project will require a formal follow-up plan, but including it demonstrates that you’re thinking beyond delivery to actual outcomes.
A Few Final Principles
Be prepared. Don’t waste stakeholder time with an approach document that hasn’t been thought through carefully. This document reflects your professional judgement about what the project requires. It should be credible and grounded in what you’ve actually learned.
Respond to feedback. When stakeholders review your approach document, listen to what they say. If someone raises a concern or suggests a change, engage with it genuinely rather than defending your first draft. The approach document is a plan, not a contract, and it should reflect the best collective thinking available at the start of the project.
Manage expectations. If you commit to a deliverable date in the approach document, meet it. If circumstances change and a date needs to move, communicate that proactively before the deadline passes. People remember consistent, reliable delivery. They also remember the opposite.
Stay curious. The approach document is a starting point. As the project progresses and your understanding deepens, you’ll encounter things you didn’t anticipate. Be adaptable. Every project is a new experience, and the ability to learn and adjust is one of the most valuable qualities a BA can have.
How Ash Supports Your BRD and Requirements Documentation
The approach document sets the stage. What comes next is the detailed requirements work, and that’s where Ash Virtual BA is built to help.
The Ash BRD Writer guides you through a structured elicitation process covering all the key categories of requirements: background, business drivers, vision, objectives, functional requirements, non-functional requirements, integration, data, assumptions, and scope. It works systematically, probes for gaps, and produces a complete confirmed requirements summary ready for BRD generation.
If you’ve followed the steps in this series, you’ll arrive at Ash with a solid foundation: a clear project context, a stakeholder map, an understanding of the key issues and drivers, and a documented approach. Ash takes it from there.
Frequently Asked Questions
Does every project need a formal approach document?
The level of formality should match the scale and complexity of the project. For a large, high-visibility initiative, a comprehensive approach document is essential. For a smaller engagement, a shorter, lighter version covering the key sections may be sufficient. What matters is that the plan exists in writing, has been shared with key stakeholders, and reflects a genuine understanding of what the work requires.
Who should review and approve the approach document?
At minimum, the project sponsor and project manager should review and confirm the approach document before work proceeds. Depending on the governance structure, other stakeholders, such as technical leads or steering committee members, may also need to be involved. The goal is to ensure that the people accountable for the project’s success have agreed to the BA plan.
What if the project scope changes after the approach document is written?
Update the document and communicate the changes clearly to all relevant stakeholders. An approach document isn’t a static artefact: it’s a living plan that should reflect the current understanding of the project. When scope changes, the approach document should change with it, and the implications for timeline, deliverables, and stakeholder engagement should be made explicit.
How long should a business analysis approach document be?
Long enough to cover the content meaningfully, and no longer. For a complex project it might run to fifteen or twenty pages. For a straightforward engagement, five to eight pages may be sufficient. Avoid padding: a concise, well-organised document that covers the key sections clearly is more useful and more credible than a lengthy document full of generic content.
What’s the difference between a business analysis approach document and a project plan?
A project plan covers the full scope of the project: timeline, milestones, resourcing, risk, and governance across all workstreams. A business analysis approach document focuses specifically on the BA activities: what analysis will be done, how it will be done, what it will produce, and how stakeholders will be engaged. In a well-run project the two documents complement each other, with the approach document feeding into the broader project plan.
Can I use Ash to help write the approach document itself?
The Ash BRD Writer is focused on requirements elicitation and BRD generation rather than approach documentation. For the approach document, the content comes from your own analysis and judgment: the desktop analysis, the kick-off meeting, and the conversations that follow. What Ash does is take you from that foundation into the detailed requirements work that the approach document sets up.