The first day on a new project can feel unproductive. You’re waiting to meet people, waiting for access, waiting for information. But that wait doesn’t have to be wasted time. The difference between a BA who makes an immediate impression and one who takes weeks to find their feet is almost always preparation.
This article is the first in a six-part series walking through how to start a business analysis project from day one through to your completed analysis approach. These are the steps I take on every project, adapted over years of practice. They won’t fit every scenario perfectly, but for most standard business analysis efforts they’ll give you a solid and credible starting point.
Arrive With Your Questions
On day one you’ll typically know something about the project, but not much. That’s normal and expected. Nobody arrives on the first day of a new engagement as the subject matter expert. What is expected is that you come prepared to ask the right questions.
Your first point of contact is usually the project manager, project sponsor, or business owner. That initial meeting is often informal, an orientation conversation more than a formal briefing. But it’s also your first opportunity to demonstrate that you’re organised, proactive, and thinking clearly about what you need to know.
Don’t waste it.
The Questions to Ask on Day One
These are the questions I ask at the start of almost every project, along with my thinking behind each one.
What is required of me?
Always confirm this, even if you think you already know. I’ve started projects with a clear idea of what I’d be doing only to find out the actual scope of my role was quite different. Check your understanding explicitly and early.
When does the project need to be delivered?
Timeline is a major constraint on everything you’ll plan. Knowing the delivery deadline helps you calibrate the level of detail that’s achievable, the number of workshops and interviews you can run, and the documentation approach that makes sense for the timeframe.
Do you have an outcome already in mind?
Stakeholders often have a preferred solution in mind before the analysis has begun. Understanding what they’re expecting, and why, gives you valuable insight into the drivers behind the project. It also helps you identify early whether the expected outcome is realistic or whether you’ll need to manage expectations carefully.
Who will be involved, and what are their names and roles?
You need to know who you’ll be engaging with so you can begin planning your interviews and workshops. Understanding the number of stakeholders and their roles gives you an initial sense of the scale of the engagement and the diversity of perspectives you’ll need to bring together.
When do you expect workshops and interviews to begin?
Stakeholder availability is one of the most significant constraints on a BA’s work. Finding out early when people will be available, and whether administrative support is in place to help coordinate meetings, lets you plan realistically rather than optimistically.
What are the expected deliverables?
Be clear on exactly what you’re being asked to produce. A business case with recommendations is a very different deliverable to a detailed requirements specification. Knowing your outputs informs your entire analysis approach.
In what format do you expect deliverables to be produced?
Many organisations have existing templates and documentation standards. Your understanding of what a requirements document looks like may differ from theirs. Align on format and structure early so you’re not rewriting deliverables later because they don’t match expectations.
What methodology do I need to follow?
Agile and Waterfall place very different demands on a BA’s documentation and timing. A plan-driven approach requires detailed documentation upfront. A change-driven approach requires just enough documentation at each stage. If the client doesn’t know the answer to this question, that’s useful information in itself, and an opportunity to offer your perspective on what would suit the project.
What existing documentation can I review?
Existing documents are a rich source of hidden requirements. Project plans, business cases, process documentation, organisation charts, policies, legislation, and strategy documents can all provide context and direction before you’ve spoken to a single stakeholder. Ask for access to everything relevant as early as possible.
If You Don’t Get to Everything on Day One
You won’t always have the opportunity to cover all of these questions in your first conversation. That’s fine. The kick-off meeting, which is covered in the next article in this series, gives you the opportunity to fill in the gaps. The important thing is to arrive prepared, ask as much as you can, and demonstrate from the outset that you’re a BA who comes ready to work.
A Note on First Impressions
The first day matters more than people often acknowledge. Stakeholders form an impression of your capability early, and it’s much easier to build credibility from a strong start than to recover it after a weak one. Arriving with prepared questions, listening carefully, and taking good notes signals that you’re organised and that you take their time seriously.
That impression carries through the rest of the project.
How Ash Supports Your Project Startup
One of the challenges at the start of a new project is knowing what you don’t know. Ash Virtual BA helps you think through the project context systematically before you’ve gathered all the information you need.
The Ash BRD Writer begins by working through your project context with you: the business problem, the organisation involved, the known constraints, and the drivers behind the initiative. If you have a brief or scope document, Ash reads it and pre-fills what it can. If you’re starting with rough notes from a first conversation, Ash works with that too, asking targeted questions to build a clearer picture of what you’re dealing with.
For BAs who are newer to the field and want to build their understanding of the concepts and terminology they’ll encounter on a new project, the Ash Glossary covers business analysis terms and methods in plain language with practical examples. It’s free to use and a useful companion from day one.
Frequently Asked Questions
What if I’m given very little information before starting a project?
That’s common, and it’s not a problem. Your job on day one isn’t to know the project, it’s to start learning it. Arrive with your prepared questions, ask what you can, and use whatever information you receive as a starting point for your desktop analysis. The picture fills in quickly once you start asking the right questions.
Should I send my questions in advance of the first meeting?
It depends on the context and your relationship with the contact. For a formal first engagement it can work well, it signals preparation and gives your contact time to think. For a more informal first conversation it can feel overly formal. Use your judgement based on what you know about the person and the organisational culture.
What if the project manager can’t answer some of my questions?
Note the gaps and follow up. Not every project manager will have visibility across every aspect of the engagement. Some questions may need to go to the project sponsor, the business owner, or other stakeholders. Identifying who can answer what is itself useful information for planning your engagement.
How much should I document from day one conversations?
As much as you can. Notes from early conversations often contain information that becomes important later, context about drivers, constraints, and stakeholder perspectives that isn’t captured anywhere else. Write up your notes as soon as possible after each conversation while the detail is fresh.
What tools should I use to capture information at this stage?
Use whatever you’re most comfortable with and can access quickly. Microsoft OneNote, Confluence, Notion, or even a well-organised Word document all work. The priority at this stage is capturing information reliably, not having it in a perfect structure. You’ll organise and model it more formally as the project progresses.