Sam Cordes If you are on a CRM implementation and trying to separate business requirements from functional requirements, this article shows you exactly how to do it. I draw on a real professional services CRM project, including a stakeholder who pushed back hard on the process. You will leave with a working structure, concrete examples, and a clear method for keeping the two requirement types properly separated.
Feeling stuck as an experienced business analyst is one of the most common mid-career problems in the profession, and it has specific, fixable causes. This article names those causes clearly and gives you concrete steps to break out of the pattern. Read this if you have active work in front of you and want to start operating differently today.
Career progression after business analyst is not about picking the right job title from a list. It is about understanding what kind of work energises you, where your strengths create genuine value, and which path you are willing to commit to. This article covers the trajectories I have seen work across 25 years of BA practice, with the friction included.
Being a business analyst is a stressful job in ways most training courses never prepare you for. The stress is real, specific, and largely traceable to structural problems rather than the nature of the work itself. This article names those problems honestly and gives you practical ways to address them before they become unsustainable.
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.
Deciding between a business analyst and a business intelligence analyst role is harder than most job descriptions make it look. Both roles generate insight and both are genuinely valuable, but they do fundamentally different work. This article breaks down the real differences, shows you where the confusion happens in practice, and helps you work out which path suits the way you think.
If you have a use case to write right now, this is the template I use across every project, with each field explained and a real worked example that includes the friction. You will also find the most common mistakes I see and how to avoid them.
If you are building a business case right now, this is the structure I use across government, utilities, health, and enterprise environments. Every section is covered, including the ones most commonly skipped, with a real worked example showing exactly where the friction appeared and how I resolved it.
If you are putting together a business analysis plan right now, this guide gives you the structure, the section-by-section content, and a real project example with genuine friction. Use it to produce a plan that holds up when stakeholders disagree, timelines shift, or scope is challenged.
Choosing between a business analyst and a product owner is a structural decision that affects how requirements get captured, how the backlog gets managed, and how much rework your team does. This article cuts through the role confusion and gives you a practical framework for making the call on your current project. It draws on real Agile delivery experience, including a specific example where the split between the two roles created friction that had to be resolved mid-sprint.
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.