Business 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:
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.
Article photo © © Kurhan - Fotolia.com