The specifics of a Business Analyst’s role will vary a lot from team to team, but these are some of the more common tasks:
The best description of a Business Analyst would be - the glue that keeps technology and business stakeholders together, through understanding business change needs and delivering technology solutions.
It is a vital role that stretches all the way from identifying the needs of stakeholders e.g. trading, sales, and the middle office, through assessing the business/technology impact, documenting the requirements and supporting the delivery of the solution.
How this works from a day to day perspective, through the life of a typical Financial Technology change project, is as follows:
Prioritisation
One of the key roles of the Business Analyst is to work with multiple senior business stakeholders, with a number of different technology requests, and understand what is being asked for to determine and document the cost benefit of each.
This cost benefit analysis gives senior business and technology management the information they need to decide on the priorities for delivery as there is never enough time and budget to deliver on all business stakeholder requests.
Requirements Gathering
In order to ensure the solution delivered will meet the expectations of the business, the requirements gathering phase is the most important of all.
The Business Analyst will first identify the key stakeholders to work with; this is vital when making sure the solution delivered covers the needs of all users and regions. This will typically be one senior representative for each region for the entire business, and a junior representative for each region for each business unit to have more detailed discussions with.
You’ll be required to change focus and organise yourself.
Once identified, the Business Analyst must make sure there is buy in from the stakeholders involved and they are informed of the analysis approach which will be followed including milestones and expected completion dates. This makes sure everyone is aware of what needs to be done and by when, within the timelines of the overall project.
The elicitation of requirements must be done in an organised and efficient manner; stakeholders will lose patience if the same discussions need to happen more than once so documentation is key. The clear and concise documentation of requirements will give stakeholders comfort that what is being discussed is being captured and is correct.
Once it is clear what is required, the Business Analyst should create diagrams/supporting documentation to illustrate the current state process vs. the future state process, clearly highlighting where business stakeholders can expect day-to-day changes.
Technology Impact Assessment
Alongside the requirements gathering phase, the Business Analyst must begin to determine the impact on existing systems due to the changes which are being proposed. This requires an understanding of the system architecture to identify those systems which may be affected and deep dive sessions with the technology teams who own these systems to determine the size of the changes required. It’s worth noting, the Business Analyst is not expected to be an expert in each and every system in the area he/she works, just to have a good understanding of the dependencies and flows so they can work with the experts allocated to each system.
This impact assessment is key in assisting the Project Manager create packages of work which need to be delivered and lining up milestones with dates.
Development and Testing
Throughout the development of the solution, the Business Analyst will be a key contact of the development team for any questions or issues. This process is typically managed via a ticket system known as JIRA where the development team will raise a ticket with a specific question and assign it to the Business Analyst for resolution.
This back and forth Q&A will continue until the system is built and ready for testing. The Business Analyst will then support the process of User Acceptance Testing (UAT) whereby the Business Users who originally requested the changes will test the solution through a number of pre-agreed test case scenarios. Once the end user is satisfied with the solution they will provide sign off that the changes can be rolled out to the live environment.
This organised and clearly defined approach to delivering a project isn’t always how it works in the real world and as a Business Analyst you may find yourself dealing with day to day issues and requests alongside you’re more long term projects. This makes for a very dynamic and fast moving work environment where you’ll be required to change focus and organise yourself so that you can meet both the short and long term needs of the Business.
If you want to gain an in depth knowledge of how the Business works, the role of a Business Analyst is where you need to be. You will work across all stages of the Business lifecycle and learn how Sales/Trading and supporting operation teams work together, and the systems they need to be able to do this as efficiently as possible. You’ll come away with skills that are transferable across all industries and experience of leading change initiatives in the most dynamic of environments.
