The Business Analyst Role

I have written this article in response to a number of aspiring practitioners who have asked me exactly what the business analyst role entails. This question is relevant because of the wide variations in Business Analysis practice and practitioners across different organisations. The BABOK itself in it’s first chapter, provides an answer to the question ‘Who is a Business Analyst?’ and gives a range of job titles that could perform the role of business analyst within the organisation. Also in the BCS publication, Business Analysis 3rd Edition, the first chapter ‘What is Business Analysis?’ equally identifies the prevailing multiplicity in the role of business analyst across different domains.

The reality is that exactly who a business analyst is and consequently what the business analyst does may often depends on who you ask! However, the multiple permutations of the business analyst role are largely dependent on three factors
 

The Organisation
The Individual
The Project

In some organisations, the BA role is part of the Business Change function while in others it sits outside the ‘business’ with the Information Technology function. As a result, there is a split between more traditional systems analysts or the “Technical” BAs responsible for producing the Software Requirement Specifications or SRS and the “Non-Technical” BAs responsible for producing the Business Requirements Document or BRD.

At the individual level, those who have a strong technical background may define their role and see it more closely aligned to the technology being developed or implemented and thus spend a little more time and albeit be a little more critical of technical solution details. On the other hand, those BAs who have more of a ‘business’ background will be very comfortable interrogating the different levels of business operation in order to establish the deeper context behind the business need and any change required.

For example, analysts with a technical background are more likely to get involved in the production of prototypes, database queries, verification of code and even systems testing while those with a non-technical background will play a lead role in operational design, requirement validation and user acceptance. Therefore, individual practitioners themselves may unwittingly contribute to the perceived split between “user-facing or requirement-focused” BAs as against “system-facing or design-focused” BAs

At the project level, projects that consist primarily of a business process improvement element will require skills and understanding that suit a thorough deconstruction of the business model while on the other hand, initiatives which focus more on technological change will require in depth solution knowledge, vendor analysis and an understanding of technical constraints. In this regard, it has often transpired that a resource vacancy in a technology project may inadvertently provide the description of a platform SME masquerading as a BA job specification.

The three factors above are further impacted by the level at which the initiative itself is being planned, executed and delivered i.e. strategic or tactical.

At a strategic level, business case conversations are more likely to be around policy, governance and longer term objectives which will also inform business or technological slant or alternatively the focus may be more IT-oriented and sit more or less within the enterprise architecture domain thus involving the transformation of technological capability over the longer term.

At a tactical level, the focus will be on a more immediate delivery, less geared towards cultural change and may require either greater or smaller technological change in order to facilitate maximum returns with minimum impact on operations. Here the split between IT and Business is dictated by the pain points necessitating the change.

All of the above are further complicated by the fact that depending on the organisation, the business analyst role is not always performed by someone whose job title is actually ‘business analyst’ because in reality, the ‘practice’ of business analysis could be conducted by any number of roles and rightly so.
 

The challenge is when a job candidate submits an application for what was advertised as a ‘business analyst’ position only to find out at interview that the job function is actually more akin to a database administrator or systems support! Or to make matters even worse, the business analyst may start in role as what is effectively a Project Manager role only to find that there is already a Project Manager and what the organisation actually needs is a UX Designer. The level of clarity required in these ads could be improved simply with statements to this effect, for example “Test Analyst with strong business analysis skills required” or “Database Manager with strong business analysis background required”. This way, it is made clear that what is advertised is not a Business Analyst role, however having strong Business Analysis skills will stand the candidate in good stead. 

Business Analysis has definitely reached a point today where it’s inherent value should be recognised in ANY role. This therefore naturally supports the split between skills (primary) and role (secondary) because business analysts will not always be hired to do business analysis (besides, all business analysts do more than business analysis anyway).

It’s also easy to blur the distinction between skills and roles. For example, to this day I continue to rely on skills and techniques developed as a teacher in order to fulfill my role as a BA (e.g. recognising and accommodating the different learning styles – visual, auditory, read/write, kineasthetic “VARK”) when planning stakeholder communication. The BABOK explicitly calls out ‘teaching’ as an underlying competency (which I think should be a key competency for a multitude of roles both within Change Functions as well as BAU yet how often do job specifications for BAs include ‘teaching experience’ as ‘essential’ or even ‘desirable’? but I digress). If I were to go back to teaching, I would continue to use many BA approaches e.g. treating a classroom like a workshop etc. and in this way I could add value to my role as a Teacher.

​Therefore, in concluding this entry, my response to anyone seeking a definition of the role of business analyst is to never get hung up on role titles or job specs for that matter! Be sure of your professional competencies and weigh the extent to which they satisfy the relevant job specification provided. If your skills are a match for the position, go for it. If indeed you find on the job that the role is different from what you expected then take the opportunity to do one of three things;

1. Expand the role to include functions it may be lacking by going out of your way to demonstrate additional capabilities – the additional value you give will raise the profile of the role within the organisation

2. Educate the organisation through partnering with standards bodies like IIBA or BCS in order to improve understanding of the BA role – this will justify a decision to limit the scope of the role in order to maximise efficiency

3. Embrace your new role and bring the added value of completing tasks with an analytical approach but be clear in your head that you are applying business analysis skills to a non-business analyst role.

Ultimately, supporting the business to achieve its objectives should be the goal of every role within any organisation regardless of job title or function or spec and as long as role definitions continue to change either due to reasons academic or pragmatic, the door will remain open to wide variations in the interpretation of the BA role.