After your kick-off meeting, your desktop analysis, and your initial stakeholder conversations, you have what you need to do something important: put a plan in writing. That plan is the business analysis approach document, and it’s the foundation everything else is built on.
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.
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.
While you’re waiting for the kick-off meeting to be scheduled, you don’t have to sit idle. This is the time to start your desktop analysis, one of the most underutilised tools in a business analyst’s early project toolkit.
The project kick-off meeting is one of the most important events in the early life of a business analysis engagement. It’s where you bring together the principal stakeholders, establish the scope and boundaries of the initiative, and gather the context you need to plan your work.
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.
Moving from business analyst to business architect is less about learning entirely new skills and more about applying the ones you already have at a different level of the organisation. This article covers what genuinely changes in the role, which capabilities you need to build deliberately, and the specific actions you can take this week to start positioning yourself for the transition.
Whether you’re staring at a job description with SQL listed as a requirement or someone has just asked you to pull data directly, the question of whether SQL is required for business analysts has a practical answer. The honest truth is that it depends entirely on your context, your team structure, and the nature of the work. Here’s how to work out which situation you’re in and what to do about it.
A business analyst template toolkit reduces the cost of starting, but standard templates are built for projects that do not exist. This article shows you how to use templates with your eyes open, when to rebuild them entirely, and how AI-assisted analysis fills the gap templates have always left. Includes a real procurement specification example with genuine stakeholder friction.
A stakeholder analysis template is one of the most important tools I reach for at the start of any project. Done properly, it goes far beyond listing names and tells you exactly who to engage, how, and when. This guide walks you through how to use one effectively, including a worked example from a real project where the analysis uncovered serious friction before it became a crisis.
If you’re weighing up whether a business analyst can genuinely do work from home, the short answer is yes, and I’ve been doing it across sectors for years. Remote BA work requires deliberate design, not just a laptop and a login. This article walks you through what actually works, what trips people up, and how to set yourself up to thrive.