At IRM we’ve long argued that investigating, eliciting and gathering requirements (i.e. analysing business problems) is only half the job of a business analyst. Sure the business wants you to understand their problems but more importantly they want you to come up with a solution. And not a technical solution but a business solution. As a business analyst you definitely need to understand how technology can be exploited. Just leave the technical (i.e. physical) design to others who specialise in…
Continue ReadingWho Reads Your Stuff Anyway?
If you’re a business analyst then producing written communications goes with the territory. It might be workshop notes to team members – or a report that lands on the desk of the CEO. Whoever you’re writing for, they’ll only read it if there’s something they want or need to know. So as writers we need to put ourselves in the reader’s shoes if we want our written communications to be effective. Fortunately, writing skills are like any other job skills,…
Continue Reading12 Positives To Being a Business Analyst
Finding solutions can be hugely satisfying in any job but in the business analyst job, you are by definition a problem solver, so it’s very easy to become “problem-centric”. Sometimes our job can just become one problem after another. We’ve got to be careful not to get depressed by all the challenges we face! So rather than just asking analysts what problems they have, what issues they need to tackle, we’ve also been asking them what problems give them the…
Continue ReadingUse Case Fragments
A previous IRM article Event Based Analysis and Modelling described how business functionality in a requirements package can be broken down into a table with column headings – Event, Trigger, Initiator, Use Case name, etc. Each business function is a separate event and has a unique number. A typical business function might contain several unique events each of which we want to end up as a component of a larger software application. So how do we go from a table containing…
Continue ReadingThe BA’s Journey – From a Current to a Future State
Many words have been written about the process of business analysis and how it can be performed on different types of projects. There are a multitude of tools and techniques which can be used plus methodologies and frameworks to suit a wide variety of circumstances. This makes it all too easy to get absorbed in the day-to-day detail and forget about the real purpose of business analysis – to fix a problem or provide the organisation with a new capability….
Continue ReadingSolution Mode Thinking
One of the biggest mistakes made by business analysts is going into “solution mode” before they’ve fully analysed a problem. They either approach a client meeting with pre-conceived ideas on what will fix the problem or jump to conclusions during the investigation phase without understanding all the underlying issues. We can all be guilty of this and sometimes the more experienced the analyst, the more prone they are to fall into this trap. Why is this so? Problem Solving When you…
Continue ReadingWhat is a Business Analyst?
When this paper was first published in 2003, business analysis was just starting to emerge as a distinct profession in its own right. Prior to this the role was often performed by the systems analyst who would carry out both the analysis and the design on a new system or enhancement. This often meant that a “problem” was made to fit the “solution”. The transition from telling the client what they would be getting – versus analysing their problems and…
Continue Reading