If you are managing business or systems analysts, trying to identify the skills and competencies required of your analysts is not an easy task. The expectations placed upon the analyst vary widely from organization to organization. The variations are so drastic that the actual title doesn’t not say much about the type of work your analysts do.
I have interviewed business analysts who have only worked on the business side and were never involved in the creation or modification of a system. On the other hand, I have met business analysts whose only responsibility was to create functional specifications.
OK… so what does this mean?
First, let me say this:
“It’s not what you’re called, it’s what you do!” What this means is that you should not try to figure out the skills and competencies of an analyst by their title – you need to know exactly what types of tasks you are expecting your analysts to perform.
In order to do that I like to put some structure around this topic to help you discover the skills and competencies expected of your analysts.
Let’s try!
- The
Analyst bridges the gap between
business &
technology.
- The
analyst plays a number of
roles.
- To perform each
role, the analyst draws knowledge from a set of
disciplines.
- Each
discipline defines a set of
activities which the analyst performs.
- Each
activity takes inputs and produces outputs.
- Each
activity requires a given set of
competencies.
- These
competencies may include
analytical,
business, and
technical skills.
Simple Definitions:
Analyst = this refers to the person whose title is generally business analyst or systems analyst but may have titles as diverse as: IT Business Analyst, Requirements Engineer, Computer Analyst, Functional Analyst, etc.
Role = The role refers to the analysts’ expected function in a given project or team. It speaks to the behaviors, rights, and responsibilities that are expected from the analyst in a given context. This is where we often get in trouble as the role of the analysts changes from project to project and task to task. Many analysts have what is known as “role confusion” in the situations when he/she has trouble figuring out exactly the role(s) they are supposed to play.
Discipline = A discipline represents a branch of knowledge (part of a larger body of learning) which defines a set of activities to be performed as well as the competencies needed to perform the given activity. For example, “testing” is a discipline which defines a set of activities and competencies needed by a QA analyst while testing software,
Activity = An activity represents a task or effort that is expected to be performed by the analyst in the context of a given role. Each activity must be clearly defined as is usually represented as having: a purpose (why perform the activity), outcome (what are the results/artifacts of the activity), and a method (how to perform the activity).
Competency = In general, competency refers to one’s ability (qualification and capability) to perform a given activity. In the case of the analyst, this requires an appropriate mix of knowledge (theoretical understanding), skills (practiced ability) and attitudes (way of thinking and opinions).
At a high level, I like to categorize the competencies needed by business analysts and systems analysts as follows:
- Analytical competencies – because first and foremost, the analyst is supposed to “analyze” – obvious but often overlooked by many organizations.
- Business competencies – because the analyst is expected to understand and solve business problems.
- Technical competencies - because, in many cases, business problems are solved using technical solutions (information systems).
Any thoughts? Would love to hear your feedback!