Everybody appears to be searching for the business analyst competencies:

• Job seekers want to know what keywords to put in their resumes.
• Career changers want to know what skills and knowledge to acquire.
• Recruiters want to know what to look for in potential candidates.
• Training companies want to know what skills to teach in their courses.

And the list goes on…

While IT analysts are playing a pivotal role in the life of any business, the business analysis profession is in relative infancy. What is expected of today’s analyst varies so widely from organization to organization and from project to project that it is neither possible nor practical to come up with a one-size-fits-all comprehensive list of competencies.

The quest for competencies should begin with identifying the various roles that analysts fulfill and the tasks the analysts are expected to perform. Only then will recruiters, trainers, employers, and analysts be able to begin to tackle the question of competencies.

As I have mentioned in one of my previous blog entries (A framework for defining competencies for business systems analysts):

The analyst plays a number of roles with the support of various disciplines which define a set of activities to be performed, which in turn require a set of competencies.

Recently I have been doing a lot of thinking about the role of the business analyst and I think it would be useful to first narrow our focus before trying to define the role of the analyst.

That is, what type of analysts are we talking about?

There are many roles and job titles out there with “analyst” in the description such as business analyst, financial analyst, security analyst, data analyst, forensics analyst, etc.

The analysts I’m talking about generally fulfill a strategic function (as opposed to a tactical one) in the life of a business or organization. What I mean by this is that the analyst helps the business do a better job, helps the business achieve its goals by helping the business do more (make more money, offer more services, increased productivity) with less (decreased cost).

The following is an oversimplified diagram which shows what the business analyst does:

(Click image to see larger version.)

As you can see, the business analyst, depending on the organization, is expected to perform a variety of activities at various different points in time.

The reality is that there are very few people who can do it all – from cradle to gave. Most analysts are specialized and their specialization (focus) depends on the type of project, organization, skills, tools, etc.

This will probably always be a murky subject but I'm beginning to see some very distinct variations in the roles that someone with a “Business Analyst” title may fulfill.

Here they are:

* Business Analyst – Here I’m referring to a very specific role (not the generic BA title). This is the analyst with very strong business skills and understanding of the business and who is generally specialized in a given industry or domain. The key role of this analyst is to analyze the business processes, procedures, organization structure, etc. in order to identify problems and determine solutions. Generally, the solutions created by this analyst are in the form of new or modified business processes, new or modified procedures, etc.

This category also includes many of the consultants at the “Big 5” firms.

Some of the job titles commonly used for this role, in addition to “business analyst”, are business consultant, management consultant, process engineer, business process analyst, etc.

Please note that “business analyst” is also the term used indiscriminately for other roles and, as a result, is the source of all kinds of confusion and misinterpretation.

* Business Process Analyst – This is more of a specialization of the “business analyst” role above. I’ve included this role in the list because of the recent buzz around Business Process Management as well as SOA (Service Oriented Architecture) combined with workflow/business process modeling systems.

While this role is still maturing, I see the business process analyst as a modeler of business processes. This is the guy or gal who uses the process/workflow software to create process models which can be simulated and even executed. They help the business executives in decision making by modeling/simulating “what-if” scenarios.

* IT Business Analyst – This is the analyst who is generally associated with requirements elicitation/analysis and solving problems using information technology solutions. This role is the bridge between business & IT.

My guess is that the majority of the members of the IIBA (International Institute of Business Analysis) fall in this category of IT Business Analysts.

The analysts in this role generally begin their work once a given IT project has been initiated. They are the ones eliciting requirements from stakeholders, analyze the requirements, document them in BRDs (business requirements documents), and create functional specifications. In this role the analyst also interacts with the development and quality assurance teams.

* Systems Analyst – This is more of a specialization of the “IT Business Analyst” role above. The systems analyst’s focus is mostly solution centric (does not generally participate in the requirements gathering process) and is involved in the creation of functional and technical specifications. This is the analyst who, once requirements are clearly defined, creates the functional solution and, by working with the technical team (architect and developers), creates technical specifications and designs.

I would also like to also discuss a couple of more titles which are often used in the industry and how they relate to the above roles:

* Business Systems Analyst – This term is often used to refer to the analysis professional who’s responsibilities start with requirements gathering and end with functional/technical specs. For the most part “Business Systems Analyst” = “IT Business Analyst” + “Systems Analyst”.

* Requirements Engineer (Requirements Analyst) – This term is often used interchangeably with the IT Business Analyst though many people see this role as being limited to requirements gathering and documentation. The reality is that there are no industry standards for the scope of the requirements engineer. From my experience, this term refers to a role that sits somewhere in between the IT business analyst and systems analyst.

Here is a graphical view of these roles and titles:

(Click image to see larger version.)

Again – the reality is that most organizations just give the BA any title they can come up with in a jiffy while the actual expectations can indeed very from project to project and team to team.

Now I need YOUR help!

I invite you to comment on this topic because I would love to hear your thoughts and also because, given the confusion around this subject, we need to put our heads together and provide some clarity to the newcomers to our profession as well as to our stakeholders, trainers, recruiters, and executives.

I've created a forum thread to make it easier for everybody to participate in the discussion:

http://www.modernanalyst.com/Community/Forums/tabid/76/forumid/-1/threadid/279/scope/posts/Default.aspx