You are on page 1of 6

How Do Business Analysts Operate in your Organization

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:

 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.

You might also like