The Six Steps
The first day on a new project can feel unproductive. You’re waiting to meet people, waiting for access, waiting for information to come through. But that wait doesn’t have to be wasted time. The difference between a BA who hits the ground running and one who takes weeks to find their footing is almost always preparation.
This guide walks through the six steps I take at the start of every business analysis project, from the first conversation through to a completed analysis approach document. Each step links to a full article with detailed guidance, questions, and practical advice you can use immediately.
Step 1: Arrive on day one with your questions
Don’t wait to be told what to ask. On the first day you’ll know something about the project, but not much. That’s expected. What’s not expected is arriving unprepared. Coming ready with a clear set of questions signals from the outset that you’re organised, proactive, and worth the stakeholders’ time.
The questions you need on day one cover the scope of your role, the timeline, the expected deliverables, the methodology, the stakeholders involved, and what existing documentation you can access. Getting clear on these early shapes everything that follows.
Read the full guide: How to Start a Business Analysis Project: What to Do on Day One
Step 2: Schedule the project kick-off meeting
Your first contact is often an informal orientation conversation. The next important task is to get the kick-off meeting in the calendar. This is where you bring together the project sponsor, project manager, and key stakeholders to establish the scope and boundaries of the initiative.
A clear agenda is essential. Without one, the conversation drifts and the meeting produces confusion rather than clarity. Send your discussion points in advance, give participants time to prepare, and arrive knowing exactly what you need to cover.
Read the full guide: How to Run a Business Analysis Kick-Off Meeting That Actually Works
Step 3: Start your desktop analysis
While you’re waiting for the kick-off meeting, start researching. Ask the project manager for access to existing documentation: project plans, business cases, process documentation, organisation charts, policies, legislation, and strategy documents. If the project involves existing systems, request access to those too.
The desktop analysis builds a working picture of the problem domain before you’ve spoken to a single operational stakeholder. That preparation transforms the quality of every conversation that follows.
Step 4: Write down as much as possible
Information that exists only in your head is fragile. As your desktop analysis progresses, record what you’re finding in a structured way: business drivers, issues and risks, existing requirements, the organisational structure, and the processes and systems involved.
These working notes become the starting point for your requirements documentation and a prompt for your stakeholder sessions. Presenting your initial understanding to stakeholders and inviting them to correct and expand on it is one of the most effective elicitation techniques available to a BA.
Read the full guide: How to Document Your Findings at the Start of a Business Analysis Project
Step 5: Attend the kick-off meeting with prepared questions
The kick-off meeting serves two purposes: confirming any outstanding questions from your day one conversations, and building an initial understanding of the problem domain. That means the business functions affected, the processes involved, the people who perform them, the issues that currently exist, and the drivers behind the proposed change.
There are ten core questions I ask in most kick-off meetings. Each one is designed to surface a specific type of information, and each one gets more useful the more you follow it with “why.”
Read the full guide: Business Analysis Kick-Off Meeting Questions: What to Ask and Why
Step 6: Write the business analysis approach document
Once your kick-off meeting is complete and your desktop analysis is underway, you have what you need to put a plan in writing. The business analysis approach document is the definitive statement of your planned activities for the life of the project. It covers your objectives, the background and scope of the initiative, the current and target conditions, your planned activities and deliverables, your communications strategy, and your stakeholder engagement plan.
Project plans often don’t cover BA work in useful detail. This document fills that gap and creates a shared understanding with your sponsor, project manager, and key stakeholders about what the analysis work will involve and what it will produce.
Read the full guide: How to Write a Business Analysis Approach Document
From Planning to Requirements
Once your approach document is approved, the detailed requirements work begins. That’s where Ash Virtual BA is built to help. Ash guides you through a structured elicitation process covering all the key categories of requirements: background, business drivers, vision, objectives, functional and 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’re newer to business analysis and want to build your understanding of the concepts and terminology you’ll encounter along the way, the Ash Glossary covers BA terms and methods in plain language with practical examples. It’s free to use and a useful companion at any stage of your career.