I have to admit, the term 'Business Analyst' doesn't sound particularly interesting. It's not even very descriptive; my own parents don't really understand what I do. Analyse the business, perhaps? Look at processes, write business cases, monitor value-add with KPIs and perform cost:benefit analysis maybe?
That's all true, but there's much more to it than that. We're an often innocuous-looking part of the engine that runs in the machine of a digital development team, that ensures the service delivered meets the needs of the business. That it does the right things, in the right way, and perhaps more importantly doesn't do or permit anything it shouldn't. You dig into business processes and activities and ask why, when, what, who, where, how?
In order to do that however, we need to do that aforementioned very vague activity of 'analyse the business', and once we've done that, we need to consider - regardless of what it currently has - what it needs from the digital service in question.
What?
Analysing the business is varied and challenging and exciting (to me, at least!). It can be a solitary activity, as you're often working ahead of your team to make sure that when the questions come, you've got the answers and that if you haven't, you know where to go to get them. You speak to stakeholders, you ask questions, you model out processes and concepts and you do an awful lot of soaking up of knowledge. You take the happy day process and you flip it upside down, and look at it again - if all doesn't go to plan, then what happens? What changes? What downstream impact is there? What are all the possible variances of this process, and how would they affect the onward flow?
Why?
Your aim is to become a proxy for the business, within the team. To be able to advise on the business processes, and the business rules (what must, or must not happen or be true at various points in a business process) and ensure that the resulting service is fit for purpose and working in line with the business needs, and objectives. That should one of those 'untoward' scenarios happen in real life, it's handled gracefully, or to be confident enough that the risk of one of those scenarios cropping up is minimal enough that it doesn't need to be handled explicitly - at least not now. Agile development and delivery is all about prioritisation (more on that in the next blog).
How?
If you were to look at the job description for a Business Analyst you'd see things like 'Stakeholder Management', 'Process Modelling', and 'Requirements Management'. What the job description doesn't say is "Ability to take in vast amounts of information and domain knowledge in a short space of time whilst building strong relationships", "Translate abstract concepts and the contents of copious amounts of documentation into easily understandable models", and "Use all of that, plus all the stuff still stuck in your head to identify the business needs, and document them in a format that your team can work to deliver" but ultimately that's what the role entails.
Who?
Business Analysis can be learnt, as a standalone skill and you will often hear that 'anyone' can do Business Analysis. This is true to an extent, but the best Business Analysts are a special breed. They're inquisitive, curious and questioning. They don't take 'that's just how it is' for an answer and were almost certainly "Why?" children, with an innate and lifelong love for learning.
If you were a "Why" child, or you simply enjoy learning something new almost every single day and using your knowledge to add value to a team, don't let a job title fool you; Business Analysis could be your perfect role.
Interested in joining MoJ Digital & Technology? why not take a look at our current job opportunities