How do BAs operate in your organisation? : A pragmatic guide to the different roles of the Business Analyst

Featured
17208 Views
8 Comments
25 Likes

How do BAs operate in your organisation? : A pragmatic guide to the different roles of the Business AnalystBusiness Analysis is a term that covers a wide range of different disciplines, which has grown in scope over the past 10-15 years. BAs can become involved in a variety of different activities, depending on the organization and the particular project that they are working on – these can range from very technical to very business focused activities.

So if you're working as a Business Analyst, or working with a Business Analyst, what can you expect? I've split this article into two sections, firstly focusing on the activities that a BA can perform and secondly looking at the job titles that they can hold.

Part 1: Activities

You should expect the following characteristics and capabilities to apply to all BAs as standard:

  • logical thinking

  • constructive challenge

  • independent perspective

  • broad knowledge of both business and technical concepts

  • problem solving

  • facilitation and negotiation

However, they can use these capabilities to perform different activities which are briefly explained below:

System analysis
Nowadays, most BAs will not be responsible for systems analysis, and some will deliberately steer well clear of it. However, it used to be the case that what an organization called a business analyst was in fact a systems analyst and this is still the case in some businesses.

Whilst you can argue that an organization or business function is as much of a system as an AS/400 application, systems analysis tends to be geared towards technology. The BA in this context is interested in determining how an existing system works so that changes can be specified – and in my experience, systems analysis tends to be a term applied to existing systems rather than new developments. Systems analysis in this context provides a better understanding of an existing situation to inform requirements definition and design. Having said that, systems analysis can be applied to new systems, and can be particularly relevant if needing to frame requirements within the context of a defined technology.

Enterprise analysis
This is a more recent term which tends to be applied to more strategic analysis roles that sit very close to the business. This role involves assessment of business strategy, definition of vision, strategy and business goals as well as development of business cases in close consultation with sponsors. It can have a sizeable crossover with business architecture activity but this is not always the case – I prefer to think of this as distinct activity that covers what the business wants to do and why, whereas business architecture considers how it will be achieved and the impacts on the current operations.

Requirement analysis
Requirements analysis is by far the most common role for a Business Analyst, and can be considered the bread and butter activity for many BAs. This is concerned with eliciting, documenting and analyzing the problems that the business is experiencing, translating these into requirements and effectively communicating them to those that will design and build a solution.

Business partner
This is a less common role but it does exist and can tie in closely with Enterprise Analysis. This role sits very close to the business, often to only one or two individuals and acts in a consultative capacity, providing advice relating to business change or specific concepts such as benefits management.

A variation on this activity is for the role to provide a focal point for Business Analysis resource for a particular business unit, with the responsibility for performing feasibility analysis, subsequently allocating BAs to individual projects and providing guidance across that business unit's portfolio

Feasibility analysis
Feasibility analysis is another common role for a BA to fulfill; this relates to the upfront shaping and scoping of business change and the assessment as to whether the organization should proceed with a project to deliver it. This role can include business case development as well as requirements definition, although the latter will be at a high level . Feasibility analysis often includes vendor selection processes such as Request For Information (RFI) and Request For Proposal (RFP) and as a minimum, the BA should define the requirements and participate in the scoring process. In some organizations the BA runs the whole RFI/RFP process, but ideally this should be managed by procurement professionals.

Data analysis
This is another “technical” role that many BAs will not be required to perform. Note that data analysis is distinct from data modeling (conceptual or logical) which is a core BA skill, and should be part of requirements definition. Data analysis is concerned with understanding existing data items and data structure in order to specify detailed requirements or (more likely) inform the design and should really be considered a technical design activity rather than a business analysis one; however, some organizations will categorize this as the latter.

Process analysis
Whilst some organizations have specific teams dedicated to process analysis (often relating to LEAN concepts), Business Analysts often become involved in process analysis on a project. Most business change results in some impact on business processes, and therefore there is a need to determine which processes need to change (and how) and this is again a core skill for a BA. This activity involves both traditional analysis and facilitation, as well as resulting in high quality documentation relating to the as-is and to-be processes.

Organizational analysis
This activity is becoming more and more common, although it is still something of a rarity. organizational analysis itself is concerned with understanding what elements of an organization need to change to accommodate a business change. Many organizations prefer to use a third party consultancy firm to perform this, both from a transferral of risk perspective (having someone else to blame) and from a lack of awareness that these skills exist internally.

organizational analysis is classic analysis activity, in terms of defining the as-is and to-be states and analyzing the gaps between them, or analyzing specific impacts across an as-is organizational model. This can include both the structure of the organization in terms of reporting lines as well as precise measures such as spans of control. Note that this analysis is often focused on the hierarchical organizational model rather than on the overall operating model which is where Business Architecture comes in.

Business Architecture
Business Architecture encompasses organizational analysis (and indeed other types of analysis) but is distinct in that it brings a higher level perspective by focusing on the entire operating model. This could be across the whole organization, or it could be focused on a particular business area. It considers the customers of the subject area, the services or products that it offers and the channels that it uses to offer those services as well as how the business is organized and where it is located.

There are a variety of different frameworks used for Business Architecture including Zachman, TOGAF and POLDAT but all of them focus on holistic analysis of the subject area and the relationships between different elements.

The actual capability to perform Business Architecture is not too dissimilar to core Business Analysis, although it does require training to use a particular model. Given the exposure that this role is likely to have, it is suited to those analysts who have experience in influencing and negotiating with senior stakeholders as well as those who are comfortable with cross-functional analysis throughout the entire project lifecycle, as opposed to just detailed requirements gathering.

Part 2: Job titles and role

Several organizations distinguish the levels of experience of their Business Analysts through different job titles, for example Senior BA, Lead BA, Principal BA and so on. One of the benefits of this sort of structure is that it gives a clear career path. However, this can cause confusion in practical terms, as someone who is defined as a “Lead BA” may not in fact be acting as a lead on a project, whilst someone defined as a “Business Analyst” may be leading a team of other analysts but not have the title of “Lead”. Also, it does lead to certain behaviours by making the grade of the individual visible to all concerned (for example on your email signature). This can result in a team of ambitious BAs who are constantly pushing to move up to the next level for the kudos associated with a rise in rank and ultimately with more “managers” and less “doers”. I have seen situations following a promotion to a more senior role whereby the BA is less inclined to perform core analysis activity or where they won't be assigned to a particular project because the work that is required doesn't reflect their new title: “you can't assign Jane to that project, she's a Lead BA”.

There is nothing wrong with ambition, and people should be encouraged to perform at their full potential; however, organizations need to balance the demand for analysis resource with the need to reward high performers and if the only way to reward staff is to give them a management role then the organization may quickly run out of individuals that are actually doing any work.

This situation also has a negative effect on the individuals who are not being moved up to the Senior or Lead grade; they will see colleagues promoted that are subsequently considered “too senior” to work on the projects that they themselves are working on, thereby degrading the work that they are performing. This can have a huge effect on team morale, leading to a “them and us” mentality amongst BAs.

My preference is to separate the role from the grade and move away from the militaristic use of rank when referring to BAs. The role of “Lead BA” is an important one, but it should relate to the temporary role that a BA performs on a specific project, not their job title. I could act as the lead BA on one project, but as a regular BA on the next.

There is still a need for some form of distinction within an organization to define pay and rations and reward those who take on extra responsibility but I don't think this should be part of the job title. My preference is for 3 key roles, none of which imply any seniority over the others and none of which are necessarily job titles.

Business Analyst
The BA performs Requirements Definition, Requirements Analysis and System modeling on a specific workstream or project, receiving direction from a Lead BA. The BA will perform the key analysis activities on the project, such as facilitating workshops, producing models and analyzing requirements

Lead BA
A lead BA is the person responsible for the Business Analysis deliverables on a project with multiple analysis workstreams; they will be responsible for providing team leadership and direction to the individual workstream BAs, whether this is a physical or virtual team, and will perform this role throughout the life of the project. The lead BA may be responsible for shaping and scoping the BA deliverables at the start of the project, and may be the person who conducts the initial feasibility analysis. In this regard there can be crossover with the role of the Enterprise Analyst although the latter will tend to perform analysis before a project is defined.

Enterprise Analyst
This role tends to work on pre-project activities, working closely with the business to shape concepts, develop business cases and in some cases conduct feasibility studies. The Enterprise Analyst works cross-functionally, examining the impact and benefits of the proposed change across the whole business. Where required, the Enterprise Analyst will also fulfill the Business Partner role discussed in part 1 above.

Summary
Hopefully this article has explained that varied role that BAs can play throughout the project lifecycle, and has touched on the value that they can add. I also hope that the article has stimulated some debate around the different job titles that they can hold. I don't know how successful separating role from grade will be in practice and I'd be interested to hear feedback from anyone who has come across similar issues with job titles and how they've resolved them.

Author: Joseph Da Silva, Principal Business Analyst, Skandia 

Joseph Da Silva is a Conference Speaker for the Business Analysis Conference Europe 2010.

He will be presenting the following session: “Nobody Knows Your Business Like Your Own Business Analysts” at the conference.

Joseph Da Silva has been a Business Analyst for over 10 years, working on major business change projects for the likes of IBM, Virgin Media and now Skandia. His current role at Skandia involves heading up the Business Consultancy practice within the Business Analysis team which focuses on cross-functional feasibility and enterprise analysis, as well as process and quality improvements. He is a keen musician, runner and football fan.

IIBA UK Conference 2010 - Business Analysis Conference

 


Article photo © © Kurhan  - Fotolia.com

Like this article:
  25 members liked this article
Featured
17208 Views
8 Comments
25 Likes

COMMENTS

marutik posted on Monday, September 13, 2010 2:35 AM
Absolutely fantastic. Thank you very much Joseph! :)

It also helped me to categorize myself - was Business Analyst in my previous company, currently, my role is that of Enterprise Analyst including Feasibility Analysis.
Thanks again.
MkRoshan posted on Monday, September 13, 2010 5:45 AM
Very Uselful for people like me who have just started the BA carrier .Provides clarity on roles ,skills and job titles .
Thank you very much !
david.hughes posted on Monday, September 13, 2010 7:13 AM
As with MkRoshan, I am in the infancy of my BA career, and "Part 1: Activities" was extremely valuable in understanding the potential deployments a BA can find themselves (or a cross over between activities).
raga posted on Tuesday, September 14, 2010 9:49 AM
Thanks a lot Joseph, for this wonderful article on Business Analysis, its roles and job titles.

Its been a great help to me in understandig BA roles, skills and job titles.

Looking forward from you for more articles on Business Analysis...

EMYYAU posted on Tuesday, September 14, 2010 2:23 PM
A well structured article - i would disagree with 'most BAs will not be responsible for systems analysis' e.g in the banking and finance - you ll find BA spending majority of time in being a system analysis :)
ajmarkos posted on Wednesday, September 15, 2010 10:37 AM
Thanks for the article. However you state "Nowadays, most BAs will not be responsible for systems analysis, and some will deliberately steer well clear of it. " A group of people performing a process with no computers - just pencils and paper - IS a system.

A system is not necessarily a computery thing. I know, I know the BABOK implies that a system is a computery thing - but the BABOK is based on popular conventions - not on logic.


Tony
sikharavish posted on Monday, September 20, 2010 6:03 AM
Joseph,

The roles explained above doesnot give a clear picture of the career path, can you please provide a detailed career path?

Also the designation of BA is not consistent across industry. I mean Business Analyst of one organization can be offered a position of Associate Business Analyst (which is a kind of Jr. Business Analyst position).
Is there a way to evaluate, what roles you are handling in ur current organization a relevant or higher position is offered in the new organization?
Rahul_ASU posted on Thursday, March 15, 2012 1:43 AM
Thanks Joseph for posting such an enlightening article on the job title and role .

I have couple of queries for you.
Is MBA a must degree to pursue the career as BA?
How PMP certification helps BA to rise in the management chain?
Whats the future of BA in the short and long run?

I would appreciate if you can cc your reply to my Email ID: rahulpisces@yahoo.com

Rahul

Only registered users may post comments.




Latest Articles

Six Estimation Safety Tips
Oct 13, 2019
0 Comments
Estimation is a chronically thorny issue for software practitioners. Most people need to prepare estimates for the work they do, but in our industry w...

Copyright 2006-2019 by Modern Analyst Media LLC