A Business Analyst (BA) is a key role within a consultancy, this is absolutely the case at Scott Logic where analysis is as important as the software development itself. Before a single line of code can be written a vitally important consulting phase should be undertaken by the BA to understand the client’s range of issues & opportunities along with their relative priorities which ultimately sets the scene for potential solutions. This blog post explores what it means to be a BA in a consultant capacity and the opportunities it can bring.
The BA role varies greatly across companies, industries, and with experience. If you ask a number of BAs what their job entails whilst there will be overlap you’re also highly likely to get a wide range of answers, but let me demystify what a BA does. The IIBA (International Institute of Business Analysis) & BCS (British Computer Society) provide the following definitions…
‘A liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals’ (IIBA)
’An internal consultancy role that has the responsibility for investigating business situations, identifying and evaluating options for improving business systems, defining requirements and ensuring the effective use of information systems in meeting the needs of the business’ (BCS)
Both definitions essentially state that the overarching goal is to deliver sustained business value by understanding an organisation’s underlying problems and requirements, and acting as a driving force towards delivering appropriate solutions, often involving technology.
Technology is at the centre of nearly everything in the modern work environment, so BAs are heavily involved in the design of technology solutions. However, there are other business areas, such as processes, people and structure (see image 1) to be skilfully navigated.
If these elements are inefficient, duplicative or error prone, deployment of a new software solution alone may limit the potential business value achieved.
After all, the broader human and political context impacts how and when the solution is deployed to the end user and how it may be received. Successful Business Analysts constantly navigate all of these areas without over-focusing on any particular one.
BAs are expected to be commercially aware and technically proficient, but aren’t necessarily a master of either, instead acting as a crucial bridge between business stakeholders and software engineers.
BAs need also to understand the market in which the organisation operates. A BA in finance may have knowledge of certain asset classes or trading alongside Agile software development, and have an ability to write SQL queries for example. Put simply, BAs have a breadth of knowledge and skills across both business and technology, while developers and those in business tend to have a depth of knowledge in their respective domains alone. Business knowledge allows BAs to draw up solutions to meet organisational requirements, while technical skills equip BAs with the ability to design feasible solutions.
There are two main entry points into the BA profession as a general rule:
1.Technology background with an appetite to grow business domain knowledge and skills
2.Business background with an appetite to grow technology knowledge and skills
There is no single perfect blend that all BAs should adhere to, but the more business and technical knowledge you have - the more effective you can be. A successful BA seeks to build on both skill sets as the business and technical environments are constantly evolving and you can easily get left behind on both fronts.
Where do Business analysts typically fit within the organisation?
Given that technology underpins nearly everything we do, it’s unsurprising that BAs are typically aligned to a development function of some sort, but the most important connection is with the operational business, meaning end users and business stakeholders. Without this connection, the job becomes infinitely harder, if not impossible because it’s the responsibility of the BA to elicit the requirements of these stakeholders and anticipate their needs.
Spending time face to face with your stakeholders is very important for growing organisational knowledge and moving into the territory of trusted advisor from that of order taker. The link to the development team is also important; not all business solutions require changes such as the introduction or removal of software, but for those that do, it‘s vital the requirements and associated designs are clearly communicated to the development team for implementation.
Below are three common BA engagement models, ranging from tightly integrated (A) to unintegrated (C); the former favours a junior BA, while the latter favours experienced those with more experience.
At Scott Logic, BAs can work in any of these capacities (as well as others). It depends on the particular client engagement and context of the project.
Sometimes, BAs work independently on specific pieces of analysis to help achieve a particular goal for the client, in which case there may be little to no alignment with a development team. In other engagements, the BA can be expected to work as part of an Agile team comprising developers, testers and UX experts. As the business sector can be radically different from project to project, being a quick learner is infinitely useful.
What do Business analysts do on a daily basis?
BAs can get involved in a wide variety of tasks, dependent on the organisation and individual experience level. Image three below provides a quick insight into some of the key activities.
One of the most fundamental skills undertaken by BAs at all levels of experience is requirements elicitation often referred to as requirements gathering. Elicitation is subtly different to gathering, the former is a more controlled/managed approach to uncovering requirements in a structured way, the latter is less structured and the emphasis is just on gathering what you can and trying to make sense of it. There is no right or wrong approach here, both have pros & cons, in order to be a successful BA it is very important to find a style that works for both you and your customer as capturing requirements correctly is the 1st step on the journey of delivering the right solution. More experienced BAs tend to move into helping to define strategy or into product ownership as well as being a trusted partner to the business (instead of an order taker). As it is common for BAs align to the technology function within an organisation, more experienced BAs can skilfully blur the line between business & technology functions which can sometimes inhibit the flow of information for less experienced BAs. The role of the BA is very varied, although it is centred around the key goal of truly understanding the business problem/requirements and being the driving force behind solutions to those problems.
At Scott Logic, BAs typically spend the majority of their time engaged in some form of requirements elicitation often based at the client’s site for a subset of the week, this is crucial in building and maintaining an understanding of the client’s requirements & objectives. In addition, they spend time working closely with Scott Logic developers, testers, and UX folks (based across the various Scott Logic UK sites), to identify high quality technology solutions in a collaborative way drawing on expertise from all of the aforementioned disciplines. That’s not to say Scott Logic BAs solely focus on requirements elicitation, they could well be expected to work on any of the activities shown in image 3 as well as others, it really comes down to the particular client’s objectives and team composition. Successful Scott Logic BAs tend to have a relentless appetite to grow their business domain expertise and are energised at the thought of being able to design and work as part of an agile development team to deliver high quality technology solutions.
As with all roles, life as a BA comes with its challenges. Perhaps the most common one briefly eluded to above is engaging business stakeholders and fighting the technology stigma, it is often the case that your business stakeholders simply won’t make the time to engage with you as they may think their time is better spent focussing on pure business activities. It is important to accept that some people may have had previous negative experiences working with people in a technology capacity (perhaps failed or severely delayed projects for reasons they cannot understand), and it falls upon you to see it as a challenge to prove them wrong through continuous delivery of business value.
Another common challenge is resistance to change, BAs are in effect change agents, they help to deliver value through some form of change whether it be with technology, processes, or a mixture of both. It is human nature to feel threatened by change, and as a result it is hugely important for BAs to recognise the human elements of introducing change and managing it accordingly – not an easy skill to master but something that simply cannot be ignored.
The ultimate measures of success for a BA are creation of business value over the short/medium/long term, satisfied end users, and being seen as a trusted partner to the business. Being a BA comes with its challenges but at the same time you are in a unique position to make a real impact in your business and with clear opportunities for career development it’s an exciting world out there for the business analyst.