If you need to get up to speed on a new project and you are already feeling the pressure to contribute, this is the article to work through right now. Not because it will hand you domain expertise you do not yet have, but because it gives you a repeatable structure for finding out what you need to know, quickly and purposefully. I have used this approach across government, utilities, health, and enterprise environments over 25 years of BA practice. The specific questions change. The structure does not.
The instinct in an unfamiliar project is to wait: for a clearer brief, for more time, for someone to hand you context. In my experience, that waiting rarely serves you. What actually moves things forward is shifting from uncertainty about what you do not know, to active problem solving about how to find out. The questions below are the mechanism for making that shift.
The Five Areas You Need to Work Through
These questions are organised into five areas. Work through them in order. They move from understanding the problem, to locating information, to planning stakeholder engagement, to handling what you gather, to keeping your eye on what you are actually producing. The gaps you identify are as useful as the answers you find. They tell you exactly where your next conversation needs to go.
1. Understanding the Problem
- What is the problem being solved? This sounds obvious but it is frequently unclear at the start, and the answer you get from one stakeholder will often differ from the answer you get from another.
- What do I already know about this problem space? Even adjacent experience is useful. Inventory it honestly before your first meeting so you are not starting from zero in the room.
- What do I not know yet? Writing down your known unknowns is one of the most productive things you can do. It turns vague discomfort into a specific research agenda.
2. Finding the Information
- What information is already available? Previous project artefacts, strategy documents, process maps, existing systems documentation, and reports from prior reviews are all fair game before you speak to a single stakeholder. This is desktop analysis, and doing it properly saves significant time in your early conversations.
- How do I get what I do not have? Identify whether the gaps require stakeholder conversations, system access, or secondary research, and plan accordingly.
- Can I triangulate across sources? A single source of information is a single point of failure. Where possible, look for the same picture from two or three directions.
3. Understanding the Stakeholders
- Who do I need to talk to? Do not rely on the project sponsor’s list alone. Ask each stakeholder you speak to who else you should be talking to. The most important voices are often not the most visible ones.
- What are their roles and interests? Organisational role and project role are not the same thing. Someone with a junior title may be the operational expert whose input shapes the solution.
- What do I need from each of them specifically? Going into a stakeholder conversation without a clear sense of what you are trying to learn from that person is a significant waste of their time and yours.
4. Planning Your Engagement
- What questions do I need to ask? Draft them before you go in. Your kick-off meeting questions are worth preparing with real care, because the first conversation sets the tone for everything that follows.
- What format works best? One-to-one interviews, workshops, observation, and document review each surface different things. The format should match what you are trying to find out, not just what is easiest to arrange.
- How will I capture what I learn? Decide this before the conversation, not during it. Think about how your notes will feed into your analysis and your early documentation.
5. Staying Focused on Deliverables
- What am I actually producing? Knowing your deliverables from the outset shapes every decision about where to spend your time and what level of detail you need to go to.
- When do they need to be ready? Work backwards from the deadlines and identify where the information-gathering bottlenecks are likely to appear.
- What analysis do I need to do with what I gather? Raw information from stakeholders is not analysis. Know in advance what you will do with it once you have it.
A Worked Example: Where This Gets Complicated
I was brought onto a project midway through for a mid-sized public sector organisation, Organisation A, that was replacing a legacy case management system. The project had been running for four months before I joined. There was a project manager in place, a solution had been selected, and I was told the requirements were “mostly done.” My role was described as helping tidy things up before the build phase started.
I ran through my standard orientation questions in the first two days. What I found was that the existing requirements documentation was largely functional specification written by the vendor, not requirements elicited from the business. The stakeholders I spoke to had not seen it. The project manager pushed back when I raised this, telling me the vendor document had been signed off and reopening requirements at this stage would delay the timeline.
That was the friction point. The pressure was real. The timeline was tight. But I held the position that signed-off vendor documentation was not the same as validated business requirements, and that discovering a gap at build stage would cost far more time than discovering it now. I proposed a focused two-week rapid requirements review with the three key operational stakeholders, scoped tightly to the highest-risk functional areas. The project manager agreed reluctantly.
What we found during that review was a significant gap in how the system would handle case escalation, a process that turned out to be central to how the team operated. The vendor had not been told about it. The fix was manageable at requirements stage. It would have been expensive mid-build and potentially catastrophic post-implementation.
The orientation questions did not magic away the politics or the timeline pressure. But they gave me the structure to identify what I did not yet know, make the case for finding it out, and do so quickly enough that the project stayed recoverable.
When to Use These Questions
These questions are most powerful at the start of a project, but they are not only for the start. I use them whenever a project changes direction, when scope expands significantly, or when I am handed something someone else has started and the path forward is unclear. Any time the current state of the problem becomes uncertain again, this structure is a reliable way to reorient.
The table below shows how the application of the questions shifts depending on where you are in the project lifecycle.
| Scenario | Primary focus areas | Likely starting point |
|---|---|---|
| Brand new project, unfamiliar domain | Understanding the problem, finding information | What is the problem being solved? |
| Joining a project already in progress | Finding information, understanding stakeholders | What information already exists and who has it? |
| Project has changed direction or scope has expanded | Understanding the problem, staying focused on deliverables | What has changed and what does that mean for what I am producing? |
| Upcoming workshop with stakeholders you have never met | Understanding the stakeholders, planning your engagement | Who will be in the room and what do I need from each of them? |
| Technical domain outside your experience | Finding information, understanding stakeholders | Who are the subject matter experts and where is the existing documentation? |
Being Honest About What You Do Not Know
One of the most effective things I have found in an unfamiliar domain is being transparent about where I am in my understanding. Stakeholders respond well to a BA who is clearly prepared and purposeful, even if they are still building context. What erodes confidence is the appearance of uncertainty without any visible plan for resolving it.
Working through these questions gives you that plan. You may not have all the answers yet, but you know exactly what you are trying to find out and how you are going to find it. That is a credible position to be in. It is also a far stronger position than pretending to know more than you do, which tends to surface at the worst possible moment.
This connects directly to how you approach your first day on a new project. The orientation questions give you a structure, but you still need to document what you find as you go. If you do not capture your early findings systematically, you will spend time re-establishing context later that you could spend doing analysis. The article on how to document your findings at the start of a project covers exactly that process.
The questions in this article are not complicated, and that is precisely why they work. Complexity is not what you need when you are disoriented on a new project. What you need is a structure that forces you to be specific about what you know, what you do not know, and what you are going to do about it. Run through these honestly, work through the gaps, and you will be contributing meaningfully far sooner than if you wait for clarity to arrive on its own.
Frequently asked questions
How do I get up to speed on a new project quickly when I have no domain knowledge?
Start by working through your known unknowns before your first stakeholder conversation. Identify what information already exists in project documents, previous reviews, or system documentation, and use that to sharpen your questions. You do not need domain expertise to be effective; you need a clear structure for learning it quickly.
What do I do if I have to run a stakeholder session before I have had time to prepare?
Go in with what you have and be transparent that your goal for the session is to build context. A well-structured set of questions based on limited knowledge is far more credible than pretending to understand more than you do. Most stakeholders respond positively to a BA who is clearly purposeful about what they are trying to learn, even at an early stage.
How do I manage stakeholder expectations when I am still getting up to speed?
Be clear about your timeline and tell stakeholders when you expect to have a working picture of the problem space. Setting that expectation early is always preferable to appearing uncertain or unprepared in later sessions. Giving people a concrete date by which you will be ready to move into detailed requirements work makes the uncertainty feel bounded and manageable.
Can I use these orientation questions mid-project, not just at the start?
Yes, and I regularly do. They are particularly useful when a project changes direction, when scope expands significantly, or when you are handed a project that someone else has started. Any time the path forward becomes unclear again, working through these questions is the fastest way to reorient.
What if the domain is highly technical and well outside my experience?
You do not need to be a technical expert to do effective BA work in a technical domain. Lean on subject matter experts, ask basic questions without apology, and focus on understanding the business problem rather than trying to master the technical detail. Curiosity and the willingness to ask straightforward questions are genuine strengths in an unfamiliar technical environment.
Try Ash, Your Virtual BA
Once you have worked through your orientation questions and have a clearer picture of the problem space, the next step is turning that understanding into structured requirements. Ash Virtual BA is built for exactly that moment. Bring your rough notes, your initial brief, or even a half-formed summary of what you have learned so far, and the Ash BRD Writer will read what is there, pre-fill what it can, and ask focused questions about what is genuinely missing. You do not need a polished starting point. Ash works with whatever you have got. Try Ash Virtual BA.
Further reading
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.