Sam Cordes The first day on a new project can feel unproductive. You’re waiting to meet people, waiting for access, waiting for information to come through. But that wait doesn’t have to be wasted time. The difference between a BA who hits the ground running and one who takes weeks to find their footing is almost always preparation.
Choosing between Agile and Waterfall methodologies is one of the most consequential decisions you will make at the start of a project. Get it wrong and you will spend months fighting the method instead of delivering value. This guide cuts through the bias and gives you a practical framework for making the right call.
When you are sitting in front of a problem on a live project, what you need is a clear approach and the right technique for the situation. This article walks through real business analyst problem solving examples, covers the most useful tools, and includes a concrete worked scenario where the straightforward answer turned out to be the wrong one.
If you are trying to stay current in business analysis, the right blogs and websites can do a lot of the heavy lifting for you. This is my curated list of business analysis blogs and communities I have found genuinely useful across 25 years of BA practice. Each entry includes an honest note on what it actually offers and who it suits best.
Business analyst challenges around scope, requirements, and stakeholder management are not abstract problems. They are the daily friction points that slow projects down and undermine delivery. This article draws on survey evidence, published research, and real project experience to help you recognise those challenges and respond to them in practice.
When you have a problem to investigate and need to structure your thinking quickly, a fishbone diagram is one of the most effective tools in a BA’s kit. This article walks through a concrete fishbone analysis example using a real product defect scenario, covering all four steps from problem definition through to analysis and prioritisation. Follow the process and you can run your own session today.
Mind mapping is one of the most practical techniques I reach for when a problem feels too tangled to tackle head-on. It lets you put a central idea on the page and pull every related thought out of your head before you start making assumptions. This article walks you through exactly how to build and use a mind map on a real BA project, including what to do when stakeholders push back on where the analysis is heading.
The five whys technique is one of the most powerful tools in a BA’s kit for stopping a project from solving the wrong problem. This article walks through how to apply it in practice, what to do when stakeholders push back, and why the question you ask before you start eliciting requirements can change everything. If you have a problem statement in front of you right now, this is where to start.
Writing a business case is one of the highest-stakes deliverables a BA produces, yet most of the document goes unread. This article shows you how to structure your case so that the people who approve funding actually engage with it, act on it, and say yes.
When you are eliciting business requirements, the order in which you approach the work matters enormously. Start with what is already written down, then go to your stakeholders with something to validate rather than a blank page. These two methods, done in sequence, give you coverage that neither approach achieves alone.
Writing a business problem statement is one of the most consequential things I do at the start of any project. Get it wrong and everything that follows is built on sand. This article gives you real problem statement examples in business, a practical categorisation framework, and a worked example drawn from genuine BA practice so you can produce something useful today.