There’s a habit that separates BAs who hit the ground running from those who take weeks to find their footing: they write things down. Not just meeting notes, but a working record of everything they’re learning about the project, the organisation, and the problem they’ve been asked to help solve.
This is the fourth article in a six-part series on how to start a business analysis project. The previous article covered desktop analysis: how to research a project using existing documentation before your formal stakeholder engagement begins. This article is about what to do with what you find.
Why Writing Things Down Matters
At the start of a project, you’re absorbing a large volume of information from multiple sources simultaneously. Documents, conversations, observations, and your own analysis all feed into a developing picture of the problem domain. If that information exists only in your head, it’s fragile. Details get lost. Connections go unnoticed. And when you sit down to plan your stakeholder sessions, you’re working from memory rather than from a solid foundation.
Writing things down as you go solves all of this. It gives you a record you can return to, a starting point for your requirements documentation, and material you can present to stakeholders to validate and refine.
It also accelerates the quality of your stakeholder sessions. When you walk into a workshop with a draft process map or an initial list of business drivers drawn from your desktop analysis, participants have something concrete to react to. People find it far easier to say “that’s not quite right, it actually works like this” than to describe a process from scratch in response to an open question. Your working document becomes a prompt for better conversation.
What to Record
From your desktop analysis and early conversations, focus your recording on the following areas:
Business drivers, organisational values, and success criteria. What is motivating this project? What does the organisation value? What will success look like? These provide the context that gives all subsequent requirements their meaning.
Issues and risks currently affecting the organisation. What problems exist in the areas being examined? What risks is the organisation trying to manage or mitigate? Understanding the current pain points is essential for ensuring your requirements address the right problems.
Business requirements including reporting needs. Any documented or discussed requirements, even at a high level, are worth capturing. This includes information and reporting requirements that may not surface until later if you don’t look for them early.
Functional and non-functional system requirements from previous work. These may be partially or fully relevant to the current project, or they may reveal gaps and unresolved issues from previous initiatives.
Organisational structure. Who does what, who reports to whom, and how the affected business functions relate to each other. This informs your stakeholder engagement planning and helps you understand the political and operational context of the project.
Business processes and the systems that support them. A preliminary understanding of how things currently work, even at a high level, is a powerful foundation for your requirements elicitation.
You don’t need to be exhaustive at this stage. You’re building a working picture, not a final deliverable. Focus on capturing enough of each area to give your stakeholder sessions a solid starting point, and flag the gaps that need to be filled through engagement.
How to Structure Your Notes
The structure that works best is one you’ll actually use consistently. Some BAs prefer a simple document with sections for each of the areas listed above. Others prefer a more visual approach, using tools like Lucidchart, Miro, or draw.io to sketch process flows and organisational maps alongside written notes. A combination of both is often most effective.
Whatever tool you use, organise your notes so that related information is easy to find and the gaps are visible. A section with three bullet points and a note saying “needs verification in kick-off meeting” is more useful than a dense paragraph that buries the uncertainty.
Presenting Your Initial Analysis to Stakeholders
One of the most effective ways to use your working document is as a starting point for stakeholder sessions. Rather than opening a workshop with blank slides and open questions, present your initial understanding of the business context, processes, and issues, and invite participants to validate and refine it.
This approach works for several reasons. It demonstrates that you’ve done your homework, which builds credibility. It gives participants something concrete to engage with, which produces more specific and useful responses. And it surfaces misunderstandings early, before they have a chance to embed themselves in your requirements documentation.
Be clear with participants that what you’re presenting is a starting point, not a conclusion. You’re there to learn, and their corrections and additions are exactly what you need.
How Ash Supports Your Documentation Work
Once you’ve gathered your initial findings, Ash Virtual BA helps you organise and build on them in a structured way. Bring your notes or brief into the Ash BRD Writer and it will work through the key categories of information with you, identifying what you have, what needs clarification, and what’s still missing. The process is conversational and systematic, and the output is a complete confirmed requirements summary ready for BRD generation.
For BAs who want a reference point while working through their initial analysis, the Ash Glossary covers the concepts and terminology you’re likely to encounter, from business drivers and baseline measures to process modelling and stakeholder analysis.
Frequently Asked Questions
How detailed should my working notes be at this stage?
Detailed enough to be useful in a stakeholder session, but not so polished that you’ve spent time formatting rather than thinking. This is working documentation: its purpose is to support your analysis, not to be a deliverable in its own right. A clear structure with enough detail to prompt good questions is the right benchmark.
Should I share my working notes with the project manager?
That depends on the relationship and the project culture. In many engagements, keeping the project manager informed of your progress and preliminary findings is appropriate and helpful. In others, sharing unverified preliminary analysis too widely can create confusion. Use your judgement, and be clear about the status of anything you share.
What if my initial understanding turns out to be wrong?
That’s exactly what the validation process is for. Your working notes are a hypothesis about the problem domain, and stakeholder sessions are how you test and refine that hypothesis. Being wrong about some things at this stage is normal and expected. What matters is that you’re identifying the gaps and uncertainties rather than treating your initial understanding as fact.
How do I handle information that I’m not sure is still current?
Note it clearly as something to verify. A simple flag like “from 2019 process document, needs confirmation” is enough. This keeps the information available for reference while making its status explicit. Verification becomes part of your stakeholder session agenda.
Can I use AI tools to help organise my notes at this stage?
Yes, and this is one of the areas where AI tools genuinely add value. Bringing rough notes into a structured elicitation tool like Ash, which can help you identify gaps and organise what you’ve captured into a coherent picture, is a practical and efficient way to move from raw information to structured analysis.