The kick-off meeting is where your project comes into focus. It’s your opportunity to move from a general understanding of what the initiative is about to a working knowledge of the problem domain: the people, processes, systems, issues, and drivers that define the context you’ll be analysing.
This is the fifth article in a six-part series on how to start a business analysis project. Earlier articles covered day one preparation, scheduling the kick-off meeting, desktop analysis, and how to document your findings. This article is about the questions to ask in the kick-off meeting itself.
The Two Purposes of the Kick-Off Meeting
When I attend a kick-off meeting, I go in with two clear intentions.
The first is to confirm any outstanding questions from my initial conversations. I need to be clear on my role, the deliverables, the timeline, the methodology, and the stakeholder landscape before I can write a credible analysis approach.
The second is to develop an initial understanding of the problem domain. This means establishing a working picture of the business functions affected, the processes involved, the people who perform them, the issues that currently exist, and the drivers behind the proposed change.
Both purposes are served by the same set of questions, asked in the right order with the right level of depth for a meeting that typically runs for an hour.
A Note on Depth
The kick-off meeting is not the place for detailed process walkthroughs or deep system analysis. You’re building an overview: enough to write your business analysis approach and plan your subsequent engagement activities. With multiple agenda items and several people in the room, you may have only two or three minutes per question.
Prepare your questions, prioritise them, and be disciplined about staying at the right level of detail. The granular information comes later, in interviews and workshops with the operational stakeholders who perform the work day to day.
And with every question, ask “why.” Asking why is one of the most powerful tools in a BA’s kit, and one of the most underused. It uncovers assumptions, exposes inefficiencies, and gets you to the root of things that might otherwise stay hidden.
The Ten Core Questions
1. What are the main functions of the business areas impacted by this project?
Start by establishing which parts of the organisation are involved. You don’t need exhaustive detail at this stage, just a clear picture of the main business functions affected and their relationship to each other. You may also need to understand adjacent areas of the business that won’t be directly affected but have some relationship to the functions under review.
2. What are the main processes performed within each of those functions?
For each business function identified, there will be one or more processes that support it. For example, a Payroll function might involve processes like Manage Time and Attendance and Process Pay Run. Getting a high-level list of the main processes gives you the map you’ll work from in your subsequent analysis.
3. Who is involved, both internally and externally?
For each process, you need to know who performs it, who it affects, and who has decision-making authority over it. This includes internal staff, external parties like suppliers or regulators, and any system-to-system interactions. Understanding who is involved also informs your stakeholder engagement plan: who needs to be in workshops, who needs to be consulted, and who needs to be kept informed.
4. What systems currently support the business activities?
You don’t need a technical deep-dive at this stage. You need to know what systems and applications are used in the business areas under review, what functions they support, and how they connect to each other. This gives you the starting point for your integration and non-functional requirements work later in the project.
5. What are the main events that trigger each process?
Every process starts somewhere. Understanding what triggers a given process, what event or condition causes work to begin, gives you a clearer picture of the boundaries and dependencies of the system you’re analysing. Keep the answers at a summary level: you’re looking for the start events, not the full process narrative.
6. What content or information is required or produced?
For each process, what information goes in and what comes out? What reports, records, or outputs does the process produce? This question surfaces information and reporting requirements that might otherwise be missed until much later in the project.
7. What are the main issues and risks currently affecting the business?
This is one of the most important questions in the meeting. Understanding what’s broken, what’s inefficient, and what risks the organisation is carrying in the areas under review is essential for ensuring your requirements address the right problems. For each issue raised, ask why. Then ask why again. Getting to the root cause of an issue, rather than accepting the surface description, is where the most valuable insights live.
8. What policies and constraints influence the direction of this project?
Every project operates within constraints: legislation, internal policy, technical limitations, budget, or timeline. Understanding these early ensures your analysis is grounded in reality and that your recommendations are viable within the actual operating environment of the organisation.
9. What value will be gained from the proposed change?
This question defines the purpose of the project in terms of what the organisation stands to gain. What will be better, faster, cheaper, or more reliable if the project succeeds? You can also explore this through related questions: What is the vision for the change? What is its purpose? What becomes possible that isn’t possible today?
10. What are the main factors that drive this project?
Business drivers are the forces, internal or external, that are motivating the organisation to act now. They might include regulatory deadlines, operational inefficiencies, competitive pressure, or strategic growth objectives. Understanding the drivers helps you prioritise requirements and make the case for recommendations later in the project.
After the Meeting
At the end of the kick-off meeting, confirm that you’ll be writing up the meeting notes and that you may have follow-up questions. Ask whether it’s okay to call or email. A phone call is almost always more effective than email for follow-up with busy stakeholders.
Distribute the meeting notes to all participants as soon as possible. This gives everyone the opportunity to review the outcomes, correct any misunderstandings, and confirm that what was captured is accurate. It also demonstrates that you’re organised and that you respect people’s time.
How Ash Helps You Work Through What You’ve Gathered
The information you collect in your kick-off meeting is exactly what Ash Virtual BA is built to work with. The Ash BRD Writer guides you through the same categories of information you’ve just gathered, business drivers, vision, objectives, functional areas, issues, constraints, and more, and helps you build a structured, complete requirements summary from your raw material.
If your kick-off notes are rough and partial, that’s fine. Ash will identify what’s there, ask targeted questions about what’s missing, and help you build toward a complete picture without having to start from scratch.
Frequently Asked Questions
What if the meeting runs out of time before I’ve covered all my questions?
Prioritise your questions before the meeting so you know which ones are essential and which can be followed up afterwards. If time runs short, note what’s outstanding and follow up promptly by phone or email. Let participants know at the end of the meeting that you’ll be in touch with any remaining questions.
How do I handle it when answers are vague or incomplete?
Probe gently with follow-up questions. “Can you give me an example of when that happens?” and “What does that look like in practice?” are reliable ways to move a vague answer toward something concrete. If the level of detail simply isn’t available in the room, note it as a gap to be addressed in follow-up sessions with more operationally focused stakeholders.
Should I share my questions with participants before the meeting?
Yes, where possible. Including your key discussion points in the agenda gives participants the opportunity to think about your questions in advance, which produces better answers in the meeting. It also sets clear expectations about what the session is for, which reduces the risk of the conversation drifting into territory that isn’t relevant at this stage.
What if a participant tries to get into too much detail too soon?
Acknowledge the detail, note it as something to explore in a more focused session, and bring the conversation back to the overview level. Something like “that’s exactly the kind of detail I want to make sure we capture properly, let’s set aside time with you specifically to go through that” is usually enough to redirect without causing frustration.
How do I ask “why” without making people feel like they’re being interrogated?
Frame it with curiosity rather than challenge. “What’s driving that?” and “Can you help me understand what’s behind that?” land differently to a blunt “but why?” The intent is the same: you want to understand the root cause. The framing makes the difference between a productive conversation and a defensive one.