I began my journey as a BA half a decade ago, and here I am today: a lead BA at Made Tech. I love being able to make a difference to a very diverse mix of users of public sector systems, which has ranged from Home Office frontline users to clinicians in the NHS, as well as the general public. Learning about the different systems and processes involved goes hand in hand with this, so I’m constantly learning and developing my skill set. But there’s much more to the job than this. Here’s the lowdown on what we do, what makes a good BA, and how we contribute to success.
BAs make teams’ lives easier
If there’s one thing I wish everyone knew about BAs, it’s that we’re not seeking to disrupt an existing way of working – we’re here to make teams’ lives easier. Sure, we may ask some hard-hitting questions and expose why something’s not working, but it’s for a good cause – to guide teams in improving processes, products and services that fulfil user needs.
The BA is essentially the link between the technical and non-technical members of a project team. The BA needs to understand the technical and non-technical language, and create documents and output that let people from both sides understand the end goal through things like user stories, requirements, and acceptance criteria which detail how a specific requirement or user story will actually be met.
For example, there may be server constraints that restrict the implementation of an internal intranet. So it would be the BA’s job to go back to the end users and the non-technical team and present the information in a user-friendly way. We may also write up executive summaries which could detail requirements to help senior decision-makers with things like freeing up more money in the pot to deal with existing issues.
Be confident, curious, and personable
Being a good BA isn’t just about your knowledge and experience, it’s also about your character. This means being personable and relaxed, which opens the door to open and honest communication from stakeholders.
A good BA will also have the confidence to tell teams what they need. There’s no point in just telling teams you’re going to do something in a certain way – share how, and the steps involved, with everyone on the team.
You should also be able to document things well and clearly, in a way that is unambiguous so everyone understands what a particular requirement means for them.
A good BA will have an element of curiosity and interest to understand the details of processes and systems. It’s worth mentioning that having technical knowledge can be a plus as you can turn complex technical language into words that people without that knowledge can understand. But it’s not a necessity. There’ll be technical architects working on the same project you can collaborate with.
Projects need BAs from the get go
If investigatory work is needed to understand a problem and how you’re transforming to a new process, there should be a BA on the project. A BA should be picked up before developers, testers, and in some cases before the product owner who will come to work with the BA closely.
Without a BA, it can take longer to complete projects because there’s more back and forth between technical and non-technical people, and potential for conflict if they don’t understand each other.
As we work so closely with the product owners and managers, we understand what their outputs are so we can show the project team what they’re missing and what they need to work effectively. Having a clear vision for this bridges the gap between technical and non-technical teams because you’re bringing everyone together towards a nice, user-friendly way of understanding what a project is trying to achieve.
Common understanding is a recipe for success
If there’s an ongoing conflict or ambiguity about what the project requirements and processes are and you’re going round in constant cycles, success isn’t likely. Success happens when you’ve reached a common understanding with a project team about what needs to be achieved, and you’ve made sure what you’ve implemented is adding value and improving the overall user experience.
It’s also about making sure you’ve considered time and cost. Success means being as close to the expectation that you set out at the start, understanding the limitations that you may face along the journey, and making sure you account for that in the cost benefit analysis.
Work with us
If you’d like to learn more about how business analysts can contribute to your projects and teams, please get in touch. Or you can connect with me on LinkedIn.
