Business Analyst Community & Resources | Modern Analyst

Interview Questions for Business Analysts and Systems Analysts

Recent Interview Questions | Search | Subscribe (RSS)

INTERVIEW QUESTION:

How do you define a role?

Posted by Chris Adams

// 43335 Views // 9 Additional Answers & Comments

ANSWER

A role describes a related set of activities that someone may perform to complete a process. Here are a few examples of potential roles.

Someone with the role of Business Analyst may:

Document business processes
Analyze business processes to identify improvements
Gather business requirements that need to be supported by an automated system
Analyze business requirements and model them in a way that makes them more easily digestible, etc.

Someone with the role of Project Manager may:

Document the tasks and activities required to meet specific project milestones
Assigned duration and effort to tasks
Create a project plan to track progress of the team
Document and escalate risks for the project, etc.

Someone with the role of Supervisor may:

Ensure that direct reports show up to work on time
Ensure that direct reports have the tools and resources required to perform their duties
Evaluate the work of direct reports
Mentor direct reports and assist them with careering planning
Make compensation recommendations, etc.

In order to more clearly understand what a role is, we can considered what a role is not, by comparing a role to something that is commonly mistaken for a role such as a job title.

A job title is typically created and used by an organization to group employees together that have some similarities in roles and responsibilities. This is typically done for a few reasons. First, it helps others in the organization quickly recognize some of the activities that employees within the same job title are responsible for. Second, it groups employees into large buckets to which the company can assign salary ranges and bonus compensation. In addition, titles usually have a very distinct hierarchy, whereas roles do not.

So how do job titles and roles relate to each other? The relationship between job titles and roles is many-to-many. Consider the job title of Business Analysis Manager. A Business Analysis Manager may perform the role of Supervisor, Project Manager, and Business Analyst, in addition to a number of other roles. However, just because a Business Analysis Manager performs the role of Business Analyst doesn’t mean other job titles can’t perform that role as well. The role of Business Analyst may additionally be performed by employees in job titles such as Business Analysis Lead, Business Analyst, Operations Manager, Process Engineer, etc.

Roles should always group together similar activities. How companies determine job titles is sometimes a bit more arbitrary since they are used to differentiate employees in so many different ways (responsibilities, reporting hierarchy, compensation ranges). When an employee is responsible for a number of unrelated activities, that is a sure sign that they perform multiple roles.

So to recap, a group of related activities define a role. Roles, reporting structures, and other parameters define a job title. An individual role can be performed by many different job titles.

--
Chris Adams
LinkedIn Profile

RATE THIS TOPIC

12345

ADDITIONAL ANSWERS / COMMENTS

Adrian M. posted on Tuesday, December 15, 2009 12:42 AM

Posted by David Medici on LinkedIn:

This is a good question. When I was on an Identity Access Management project in which we had to analyze the provisioning, authentication and authorization models of 33+ financially significant applications and then abstract a single model that would work for all applications, the question was essential to accurately answer.

As best as I can recall, we settled on the following: A role is a set of skills, knowledge, authorizations and accountabilities involved in the execution of a task.

Examples:
1. The role of teacher involves specific instructional skills used to impart knowledge of a particular kind (e.g., mathematics, history, English literature) within an institutional framework (i.e., the authorizations).
2. The role of application security analyst involves the use of specific analysis skills that apply security principles (i.e., the knowledge) to the evaluation of computer programs (i.e., the accountability) for the purpose of ensuring the protection of data and processes within an automated software product.

Adrian M. posted on Wednesday, December 16, 2009 11:31 AM

Posted by James Shoemaker on LinkedIn:

In my mind a role is what an Actor plays. And an Actor can play many roles in a Use Case Diagram

Adrian M. posted on Wednesday, December 16, 2009 11:31 AM

Posted by David Medici on LinkedIn:

Mr. Shoemaker, what does "play" mean? Can anybody "play" the role, or does the role require some kind of skills, knowledge, authorizations, etc.? See the point I am making? Believe me, we went round and round about how to define a role so that the definition implied the necessaries of the role.

Adrian M. posted on Wednesday, December 16, 2009 11:32 AM

Posted by James Shoemaker on LinkedIn:

Ok I see your point but can you see we are looking at the same thing at 2 different layers of abstraction. I am looking at it as a BA and you more of a Tech guy.

My layer of abstraction is Actors may represent roles played by human users, external hardware, or other subjects. Note that an actor does not necessarily represent a specific physical entity but merely a particular facet (i.e., “role”) of some entity that is relevant to the specification of its associated use cases. Thus, a single physical instance may play the role of several different actors and, conversely, a given actor may be played by multiple different instances

Adrian M. posted on Wednesday, December 16, 2009 11:33 AM

Posted by David Medici on LinkedIn:

Mr. Shoemaker, I have been a Business Analyst, Process Analyst and Systems Analyst for 19 years, so when I look at questions like this I do see them from many angles.

You are correct in that a "single physical instance" (what I would call a person, device, or application) can play many roles. Of course an Actor "plays a role," but what precisely is a role? Let us use the example of an Actor (which is just another metaphor). An actor has dialog and physical activities (knowledge and skills) that only he can perform (authorization) and which he is expected to perform at a particular time and manner (accountability).

Just for giggles I checked Wikipedia, article "Role". The opening paragraph is, "A role (sometimes spelled rôle as in French) or a social role is a set of connected behaviors, rights and obligations as conceptualized by actors in a social situation. It is an expected behavior in a given individual social status and social position." Notice the words "set," "behaviors" (=skills and knowledge), "rights" (=authorizations), "expected behavior" (=accountability). Interesting, is it not?

Adrian M. posted on Wednesday, December 16, 2009 11:33 AM

Posted by James Shoemaker on LinkedIn:

Well I like Butter or Jelly with my roles but with out baking them first you just have butter and Jelly.

I see that actor / role what they initialize or what is the goal of the actor. This is what we should concentrate on during functional requirements. Your perspective is from a analysis and design view. I think they way you answer the question depends on the job you are applying for. Remember there are different type of skill sets for a BA and those who are an expert in Requirements gathering views roles more like me, those who view Roles more like you as more of tech view which is right also. My point is not to jump to analysis and design ( Jelly and Butter) until we have the requirements view stabilized (Baked Roles).

Adrian M. posted on Sunday, December 27, 2009 1:32 AM

Posted by Steve Blais on LinkedIn:

One could then deduce from the Wikipedia definition that rather than asking someone what their position is, or their job title, or what they do, we should observe, elicit, and analyze their behaviors - that is the activities they perform in doing their jobs and achieving their objectives - and then create roles from those behaviors. When a set of behaviors is consistent - they occur every time as the result of a specific event or trigger - or a set of behaviors is performed uniformly (not necessarily exactly) by more than one process worker then we can define that set of behaviors as performed by a single role. I think that it is best to restrict every role to one set of cohesive behaviors rather than combine sets of behaviors into a single role. The roles might have names like "voucher enterer", "employee hirer", "environmental data supplier (a non-human role)", "incoming mail sorter", and so forth, many of which sound patently ridiculous to many. However, the names of the roles when rendered as singular nouns and which fully describe the set of behaviors falls within the general guidelines of the definition of actors in use cases. And, most importantly, they help us understand clearly the functionality of the system or business process we are enhancing or creating.

Adrian M. posted on Sunday, December 27, 2009 1:33 AM

Posted by David Medici on LinkedIn:

Mr. Blais, you are precisely correct. This is why Process Analysis, in my opinion, is so intimately related to Business Analysis. One cannot analyze the business without analyzing the processes in which the business practitioners engage. The analysis about which you write should elicit the skills, knowledge, authorities, and accountabilities involved in executing certain activities, and all of that comprises a "role".

Keep in mind, too, that a practitioner often moves imperceptibly from one role to another. That is, we all wear many hats, and we switch hats as a normal course of doing business without always thinking about the fact that we are intending to use a different set of skills, knowledge, etc. This is because a role only has context with respect to an objective, and when the objective changes the role also changes.

Understanding that point brings to light another truth: roles are determined by how a business decides to segment its activities, and segmentation of activities is driven in large part by definition of objectives. To use your example, the "incoming mail sorter" does certain things (activities) for the express purpose of achieving a certain objective within a certain business, namely, sorting only the incoming mail. But at another business there may be no "incoming mail sorter" role because that business has segmented its activities differently (perhaps just having the role of "mail sorter").

Adrian M. posted on Sunday, December 27, 2009 1:34 AM

Posted by Steve Blais on LinkedIn:

You are right, David. Many business analysts do not take the time or make the effort to define the business process they are working on. They simply engage the process worker in a conversation to determine what the business wants and write up the results as requirements with no regard as to how the change in the process necessitated by the requirements will affect the process. Defining the roles of the process workers is just a part of the definition of the problem domain but an important part.

Only registered users may post comments.

Do your homework prior to the business analysis interview!

Having an idea of the type of questions you might be asked during a business analyst interview will not only give you confidence but it will also help you to formulate your thoughts and to be better prepared to answer the interview questions you might get during the interview for a business analyst position. Of course, just memorizing a list of business analyst interview questions will not make you a great business analyst but it might just help you get that next job.