The first thing I do when I know how to set up a business analysis project properly is resist the urge to open a requirements template. It sounds counterintuitive, but jumping straight into elicitation before you have clarity on what the project is actually trying to produce is one of the most reliable ways to generate a lot of work that nobody needed. Before anything else, you need to know what kind of output is expected at the end of this engagement, what is driving the project right now, and what success actually looks like for the people who commissioned it.
That clarity shapes every decision that follows: which stakeholders you talk to, how much detail you capture, what format your outputs take, and how you know when you are done. Without it, you are navigating without a destination. The rest of this article covers how to establish that foundation quickly and practically.
Why the Type of Project Changes Everything
Not all BA engagements are the same, and treating them as though they are is where projects go wrong early. The scope of your analysis work is directly determined by what the project is trying to produce. Four of the most common engagement types look like this:
| Project Type | Core BA Focus | Level of Detail Required | Typical Output |
|---|---|---|---|
| Process improvement | Deep process mapping, pain point analysis | Operational and functional, not necessarily technical | Process documentation, recommendations report |
| Software procurement | Requirements sufficient to brief vendors and evaluate fit | High to mid level, not build-ready specification | Vendor brief, evaluation criteria, BRD |
| Custom software build | Comprehensive functional and non-functional requirements | High precision, traceability, enough to build and test from | Full BRD or FRD with traceability matrix |
| Enterprise architecture | Strategic alignment and capability mapping | Broad and cross-organisational, less granular per function | Architecture artefacts, capability model |
Each of these has a different set of stakeholders, a different definition of done, and a different standard for what constitutes a complete piece of work. Starting your analysis without knowing which one you are doing is a reliable way to produce the wrong output with considerable effort. I have done it once early in my career and I have never done it again.
The Conversations You Need Before Anything Else
Before you schedule a workshop or draft an agenda, you need three conversations: with the business owner, the project manager, and where technology is in scope, the IT manager or equivalent. These are not requirements sessions. Their purpose is to build enough context to define your approach and surface the thinking that already exists in the room.
What you are trying to come away with from these conversations:
- The business drivers behind the initiative. Understanding what is forcing or motivating this project right now gives you the foundation for scope, prioritisation, and any business case work that follows.
- A genuine problem statement. Not a solution description dressed up as a problem, but a real articulation of what is broken, inefficient, or missing, grounded in actual examples from the business.
- The strategic, policy, and legislative context. What organisational goals, regulatory obligations, or strategic priorities does this project connect to? This becomes invaluable when you need to justify recommendations or frame a business case.
- A stakeholder map for further consultation. Every conversation should surface the next set of conversations. Keep the business informed about who you have spoken to and who you are planning to speak to next, because it builds confidence and reduces the risk of missing a critical perspective.
If you want a structured set of questions to run through in these early sessions, the BA kick-off meeting question guide is a useful reference before you walk in.
A Worked Example: When the End Game Was Not What Anyone Thought
On Project X, a mid-sized utilities organisation, I was brought in to document requirements for a new customer portal. The brief I received described a customer-facing self-service system with account management, billing visibility, and outage notifications. I had two weeks to produce a requirements document before development was due to start.
In my first conversation with the business owner, it became clear that the impetus for the project was a regulatory audit finding, not a customer experience strategy. The organisation had been cited for inadequate communication with customers during outage events. The portal concept had emerged in a leadership meeting as a potential fix, but nobody had formally assessed whether it was the right solution or even the fastest one.
The friction came when I raised this with the project manager. She pushed back firmly, telling me the portal had already been approved at executive level and that my job was requirements, not solution design. That is a position I have heard many times across 25 years, and I understand why project managers take it. But I also knew that if the underlying problem was outage communication, a portal that customers had to proactively log into was almost certainly not going to resolve the audit finding on its own.
I documented both positions explicitly: the approved solution scope and the unresolved link between the proposed portal and the regulatory requirement it was meant to address. I flagged it as an assumption that required sign-off from the business owner before requirements work went further. That triggered a two-day pause and a conversation between the project manager, the business owner, and the compliance team. The outcome was a revised scope that retained the portal but added a proactive notification capability as a mandatory component, which had not been in the original brief at all.
Had I simply started writing requirements against the original brief, the portal would have been built to spec and failed to close the audit finding. The end game had not been properly defined, and surfacing that early, even uncomfortably, was exactly the right call. If you want guidance on how to document what you find in those first few weeks, this article on documenting early findings covers the approach I use.
This Discipline Applies Regardless of Methodology
Whether you are working in Agile, Waterfall, or a hybrid model, the need to understand what the project is trying to produce before you begin does not change. The methodology affects how you structure and sequence your analysis work. It does not change the fact that analysis without direction produces documentation without value.
In an Agile context, this thinking sits in the initiation and discovery phases before sprint work begins. In a Waterfall context, it belongs in the project setup and analysis phases. The framing differs but the discipline is the same. If you are unsure how your methodology affects the shape of your BA work, the Agile vs Waterfall comparison is worth a read before you lock in your approach.
How to Translate This Into a Working Structure
Once you have your early conversations and a clear sense of the project type and end game, you can structure your analysis work with confidence. The sequence I follow looks like this:
- Confirm the problem statement in writing. Get it agreed by the business owner and project manager before you go further. Ambiguity here costs weeks later.
- Identify your stakeholder groups. Map them by influence, interest, and what they can tell you. Do not rely on the project manager’s list alone; ask each person you speak to who else should be in the room.
- Scope the analysis work explicitly. Write down what is in scope, what is out of scope, and what is to be determined. Review it with the project manager. This is your protection against scope creep later.
- Choose your elicitation approach. Match the technique to the stakeholder and the type of information you need. Workshops, interviews, observation, and document review all serve different purposes.
- Agree your output format early. If the project needs a BRD, know that before you start. If it needs user stories, know that too. Producing the wrong format at the wrong level of detail wastes everyone’s time.
Getting your project set up correctly is not overhead. It is the analysis. Every hour spent establishing clarity at the start saves three hours of rework, redirection, and difficult conversations later. The projects I have seen go badly wrong almost always had a poorly defined end game and a BA who started producing outputs before the destination was agreed.
Frequently asked questions
How do I set up a business analysis project when the brief is vague?
Start by identifying the business owner and project manager and having a direct conversation about what problem the project is meant to solve, not what solution has been proposed. Document what you hear, flag what is ambiguous, and ask for sign-off on the problem statement before you begin requirements work. A vague brief is itself a finding worth surfacing early.
What should a business analyst do first on a new project?
Before opening a requirements template, talk to the people who own the problem and establish what type of output the project is expected to produce. Understand the business drivers, the problem statement, and the strategic context. Only once you have that foundation should you start planning your elicitation approach.
How does the type of project affect how a business analyst sets up their work?
The type of project determines the level of detail you need to capture, the stakeholders you need to engage, and the format your outputs should take. A procurement exercise needs enough detail to brief vendors; a custom build needs precise, traceable requirements. Getting this wrong produces work that is either too thin to be useful or far more detailed than anyone needed.
What if key stakeholders disagree on what the project is trying to achieve?
Surface the disagreement explicitly and early, rather than working around it or picking a side. Document the different perspectives, facilitate a conversation to reach alignment, and make sure the agreed outcome is recorded and visible to everyone involved. Divergent views on project purpose are far easier to resolve before analysis is underway than after.
Does this project setup approach work in Agile as well as Waterfall?
Yes. In Agile, this work sits in the initiation and discovery phases before sprint work begins; in Waterfall it belongs in the project setup and analysis phases. The discipline of establishing the end game before you start producing outputs applies regardless of methodology.
Try Ash, Your Virtual BA
If you are setting up a new project right now, Ash is built to do exactly what this article describes: work through the project context with you in a structured sequence, establish the problem statement, identify stakeholder groups, and build toward a complete requirements picture before a single requirement is formally documented. It starts where good BA practice starts, with the why, not the what. You do not need a polished brief to begin; rough notes from an initial meeting are enough for Ash to work with. Try Ash Virtual BA and see how quickly you can move from an ambiguous brief to a structured, confident analysis approach.
Further reading
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.