Sam Cordes 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.
If you are starting an ICT project and cannot yet articulate why the organisation is investing in it, you need to nail down your business drivers before anything else moves. This article walks through the most common business driver examples, how to surface them through executive engagement, and what happens when you get the stakeholder buy-in wrong. Use it to complete that first critical step of your analysis.
Setting up a business analysis project correctly means establishing what you are actually trying to produce before you touch a single requirements template. Get that wrong and everything that follows is misdirected effort. This article walks through the practical steps I use to frame, scope, and orient a new BA engagement from the very first conversation.
Advancing your business analyst career takes more than logging years on projects. It requires deliberate skill-building, honest self-assessment, and the habit of creating demonstrable value. This article covers what actually moves the needle, drawn from 25 years of BA practice across government, health, utilities, and enterprise environments.