Page 1 of 5

The Eight Competencies of Highly Effective IT BAs

By Prasad Kamath Email: prasadvkamath1@yahoo.com, Tel: +91-9833990271, Mumbai,
India.

According to IIBA’s Business Analysis Body of Knowledge (BABOK), v2.0, “business analysis
is the set of tasks and techniques used to work as a liaison among stakeholders ……………….
to recommend solutions that enable the organization to achieve its goals”. A Business
Analyst (BA) is any person who performs business analysis activities, no matter what their
job title or organizational role may be.

When someone refers to a ‘Business Analyst’, he often ‘means’ an SME. However, over the
years, the industry realized that simply having subject matter expertise is not enough for
effective business analysis. The methods and practices used by the SME are equally
important. This fact, along with the release of the BABOK v2.0, made organizations work
towards enhancing their business analysis practices beyond simply recruiting subject matter
experts.

This article aims at highlighting the important competency areas a BA should possess in
order to do justice to his role, primarily on IT projects. The Figure shows the eight major
competency areas of an IT BA, some of which overlap with IIBA’s Business Analysis
Competency Model V2.0 and ESI International’s Business Analysis Competency Model. The
intent of this article is not to present a new competency model but to expand on the existing
competency models.

1. Business Analysis Practices

By business analysis practices, I mean primarily the 32 tasks (same as processes)
described in IIBA’s BABOK v2.0. The BABOK focuses on the processes to effectively
perform business analysis on any project. Hence, as one would expect, the BABOK is
not specific to any business domain and can be applied equally well to any business
domain.

It is imperative for any BA to internalize the BABOK tasks and techniques in order to
produce consistent results on projects, as far as business analysis is concerned. For
instance, many projects directly begin with a discussion of ‘requirements’, without
first obtaining a consensus on the business problems being encountered by the key
stakeholders. The BABOK includes a knowledge area called ‘Enterprise Analysis’ that
requires the BA to perform problem analysis (or opportunity analysis) and arrive at a
‘Business Needs Statement’, before the solution requirements can be fleshed out.

This approach remains the same, irrespective of whether it’s the Insurance,
Healthcare or any other business domain. That is the value the BABOK provides to an
SME – a set of global business analysis best practices.
 Page 2 of 5

5. Documentation
Business Analyst
Competencies

1. Business Analysis Practices

2. Usability Engineering 6. Business Domain

5. Documentation
(E.g. Requirements Documents)
3. Object-Oriented Analysis 7. Business Process Management (BPM)

4. Quality Control
8. Technology Awareness

2. Usability Engineering
Very often, project teams tend to develop solutions or products for the stakeholders
who communicate requirements to them, without being cognizant of the fact that no
matter who communicates the requirements, if the end-users cannot use the system
effectively, the project fails!

The Standish Group, a popular research organization that publishes ‘the top 10
success factors’ on projects, every year, based on its analysis of a large number of
projects in North America, has been including the success factor ‘user involvement’
in the top 5 factors every year. It’s strange to see that, in spite of that, a large
number of systems continue to be rejected by end-users, either partly or wholly, once
made available to them, typically during UAT or post-deployment. Usability
engineering is the answer to this issue.

Most people who don’t understand ‘usability engineering’ invariably think that it is
nothing more than designing UI screens and their look-and-feel. However, to be
precise, that is part of user-centered ‘design’, which is just one subset of usability
engineering. Usability engineering includes the entire lifecycle, right from UCA (User-
Centered Analysis), through UCD (User-Centered Design) and Usability Testing that
ensures that the solution is developed in close collaboration with the appropriate
end-user representatives. In fact, user-centered analysis is an integral part of
business analysis that keeps the end-user at the center of all business analysis
activities. It focuses on the end-user’s ‘mental model’, which is their sub-conscious
way of doing things.

It is absolutely essential for all BAs to have a strong understanding of the usability
engineering lifecycle, particularly, user-centered analysis and usability testing. User-
centered design does not fall within the scope of work of a BA.

3. Object-Oriented Analysis
The BABOK v2.0 includes a set of 34 generic techniques that can be applied to
multiple business analysis tasks. Many of these techniques are relevant to object-
oriented analysis. Since most software systems today are based on object-oriented
technologies, it is important for BAs to be well-versed with object-oriented techniques
relevant to their scope of work.
 Page 3 of 5

UML (Unified Modeling Language) enables BAs to convert requirements into different
types of ‘models’ or ‘diagrams’, each of which describes a particular aspect of the
requirements. Additionally, ‘use cases’ are a very simple, easy-to-understand
technique to document requirements, primarily, ‘functional specifications’ (though
they can be used to document business requirements as well), such that it becomes
easy and much less error-prone to convert it to technical design and subsequently, to
code.

It is important to acknowledge that one of the biggest communication gaps on

projects is between the BA and the project team that converts the requirements
specified by the BA to working software. UML makes it easy to communicate
requirements specifications in a form that is easy for the project team, especially
System Developers, to interpret and convert to low-level design, using simple UML
tools.

Most BAs I have seen stay a mile away from UML, thinking that it is ‘technical’ and
hence meant for the System or Technical Analyst. UML includes a set of over 10
types of models or diagrams that are developed at various stages of the SDLC. What
many BAs probably don’t know but need to know is that the initial set of diagrams is
the responsibility of the BA (though this sometimes overlaps with the responsibility of
the System Architect). These diagrams developed by the BA get further converted by
Technical Designers to lower-level diagrams that form part of the low-level technical
design, during the Low-Level Design activity.

The BABOK includes ‘Scenarios and Use Cases’ as well as 5 other UML diagrams in its
Business Analysis Techniques section. If the techniques are described in the BABOK,
they come within the scope of the BA’s work and hence the BA must certainly know
them. Again, as I have proved to BAs in every Business Analysis class of mine, UML is
no rocket science and there is nothing ‘technical’ about it. It can be easily mastered
by the so-called ‘non-technical’ BAs, if they do away with their mental block towards
UML. The industry certainly prefers BAs with an understanding of UML.

4. Quality Control
Since it’s a BA’s responsibility to ensure that the solution delivered to stakeholders
meets the business need(s) for which the project was undertaken, it’s important for
the BA to ‘verify’ and ‘validate’ the requirements (part of the requirements review
activity) as well as ‘validate’ the solution (typically part of UAT) to confirm that it
actually does meet the business need(s). These activities are a subset of Quality
Control activities.

A BA must be skilled at planning and facilitating user acceptance tests. This includes
ensuring that ‘all’ the right stakeholders are included in the test and the right aspects
of the solution are validated as part of the test. I have seen many UATs that are
nothing different from System Testing, except that they are performed by end-users,
that too, not the right ones. It’s not very surprising then that in spite of an apparently
‘thorough’ UAT, the solution throws up many problems in the production environment
that are not really related to the environment.

System Testing does not fall within the scope of a BA’s work, as there is no
corresponding task or process in the BABOK. However, a BA might often be required
to support the System Testing activity. Whether a BA is involved in System Testing or
not, it is certainly important for the BA to understand how functional and more
importantly, non-functional testing (such as performance testing, security testing,
usability testing etc) are performed. This is because it is the BA’s primary
responsibility to elicit and document ‘testable’ non-functional specifications, a
 Page 4 of 5

requirements-related activity that I have seen many BAs not even familiar with. It
would be difficult for a BA to write ‘testable’ non-functional specifications, if he does
not understand how they will be tested.

5. Documentation
This is one competency area that I would say, is the single biggest contributor to
effective and successful business analysis, though the others are certainly very
important. It is a known fact that a large percentage of the defects discovered during
the System Testing and UAT activities are associated with poor quality requirements
documentation. One of the major reasons for this is that the BA invariably assumes
that the consumer of the documentation, primarily, the System Development team
that actually builds the solution, possesses the same level of understanding of the
business domain, as him or her. This makes him subconsciously exclude a lot of
important details that deserve to be specified.

This problem gets compounded by the fact that most project team members,
including BAs, ‘detest’ documentation, if I may use that word. The interesting aspect
of an ambiguously written requirement is that the individual reading and interpreting
the requirement might believe that he has perfectly understood the requirement,
when his interpretation might actually be quite different from what was meant by the
BA who documented the requirement. Unfortunately, the only time both might get to
know that is during the UAT, or worse, during the production run, that leads to an
unacceptable amount of rework. That explains the need for ‘unambiguous’
documentation.

6. Business Domain
By business domain, I mean industry verticals like finance, insurance, banking etc.
Though the BABOK explicitly mentions that the role of an SME is distinctly different
from that of a BA, it also mentions that often both might be performed by the same
person. That is very true, on many IT projects. The BA would probably not be called a
BA if he is not an SME in the relevant business domain. And to a great extent, a BA is
likely to be more effective in his role if he possesses a fair amount of breadth and
depth of knowledge and experience in the business domain relevant to the project.

7. Business Process Management (BPM)

As mentioned at the beginning of this article, a BA is primarily a problem-solver. One
of the things that enable him to identify and analyze problems (or opportunities) and
to recommend the best solution is his ability to understand and analyze business
processes. Modeling and analyzing the ‘as-is’ business processes in scope and then
the ‘to-be’ processes is one of the key business analysis activities. Hence, it is
essential for a BA to have a good understanding of BPM concepts and techniques.

The ABPMP’s (Association of BPM Professionals) BPM CBOK (Common Body of

Knowledge) describes nine different knowledge areas of BPM that a BA must
understand well. Though some aspects of BPM like business process modeling and
process analysis (to a smaller degree) have been addressed in the BABOK, there are
other aspects of BPM like process design, transformation and performance
management that are equally important and central to the role of a BA. They are
essential in order to solve a business problem.

8. Technology Awareness
Though a solution need not necessarily have an IT component, in all probability, most
of them will, because most businesses today are IT-enabled. Hence it is imperative
for every BA to possess the ability to understand how IT systems and technology can
help solve business problems. In addition, since an IT BA works within the context of
 Page 5 of 5

a software or IT project, a good understanding of the SDLC is essential to perform

business analysis activities effectively. In fact, the SDLC methodology (waterfall,
iterative, agile etc) selected for the project directly influences what business analysis
activities would be performed and how.
____________________________________________________________________________________