Business Analyst Roles and Responsibilities – Where does it begin and where does it end?
This article will outline the description of the Business Analyst Roles and Responsibilities whilst aiming to stay in alignment with the industry standard for Business Analysis (according to the IIBA®).
What is the role of a Business Analyst?
The role of a Business Analyst is that of a person acting as a bridge or link to interpret, analyze and translate between what is typically referred to as the Business side (the group experiencing a Business need or problem in the organization) and the Technology teams (people offering a solution to a problem or need). The role of the Business Analyst is therefore to not only interpret and make sense of a business need or problem, but also to translate those needs into a language, which can be interpreted and understood by Technology or solution teams. This involves a variety of specific and specialized Business Analysis skills and techniques, which makes up the Business Analysis Profession.
What are the responsibilities of a Business Analyst?
Understanding the business need or business problem is the first step in the Business Analyst Roles and Responsibilities description. The Business Analyst must elicit and analyze the business need or business problem in close partnership of the stakeholders who is raising the needs. This very initial Business Analyst responsibility is often still a high level and conceptual level discussion at an enterprise analysis level and can typically include Business Analysis techniques such as: SWOT Analysis, Root Cause Analysis, CATWOE, Problem Analysis, Scope Modeling, PESTLE Analysis, MOST Analysis, Feasibility Study and Business Case support among others.
Once the Business Analyst understood and validated the conceptual business needs the next step is to start capturing the business requirements by working closely with all the relevant stakeholders. Business requirements are captured via Requirements Elicitation Activities such as Requirement Gathering Interviews, Requirement Gathering Workshops, Observation and Surveys.
During the Requirements Elicitation activities the Business Analyst will document the Business Requirements in one of a few different potential formats. These formats are often dependent on the Project Methodology used (Waterfall Model or an Agile Methodology) and could therefore be completed as Business Requirements or Stakeholder Requirements Documents or User Stories.
During the Business Requirements documentation stage of the project the Business Analyst will use a variety of Business Analysis tools to translate the Business Requirements into a language, which can be understood by the intended solution providers or technology teams. Some of the tools or diagrams that is very often used by Business Analysts to achieve this purpose include: UML Use Case Diagrams, UML Activity Diagrams, Business Process Modeling (BPMN Notation), Prototyping, Wireframes or conceptual Current State and Future State diagrams to assist in the translation of Business Requirements into a language which will be understood by the audience.
As part of the Business Analyst Roles and Responsibilities the Business Analyst must also perform activities to do Business Analysis Planning such as Business Analysis Approach (which tools & techniques will be used for Requirements Elicitation, Approvals etc.), Stakeholder Analysis (do a RACI Model), Work Breakdown of all activities, work estimation to feed into the Project Schedule and Business Analysis Resource Planning.
The core Business Analyst Roles and Responsibilities are summarized above but it should be plain to see that it is a very diverse role and yet very specialized. Business Analyst Roles and Responsibilities are of such a nature that it can be applied within any subject matter area and within any industry. This is why being a Business Analyst of whatever experience level is such a rewarding career.
On the flip side of the coin, Business Analyst Roles and Responsibilities are often not well understood within the general organization and consequently poorly applied by ignorant Project Managers and Business Leaders. This can cause some frustration among Business Analysts but thanks to the Professional Business Analysis Pathways being promoted and implemented worldwide, this may not be a frustration for too much longer.
Let’s spend a few minutes though to now look at tasks often performed by uneducated Business Analysts that should really not be performed by them!
The 3 most common tasks that is NOT part of the Business Analyst Roles and Responsibilities but are often performed by Business Analysts:
TASK 1: Taking minutes in Steering Committee Meetings is not a Business Analysis task. It may be a task that is rotated among all project team members in the absence of a Project Analyst and not just assigned to the Business Analyst in these circumstances.
TASK 2: Creating Risk and Issue Logs for a Project. Although the Business Analyst will contribute to the Risk and Issue Logs of a Project, it is not part of the Business Analyst Roles and Responsibilities.
TASK 3: Performing Testing is another famous task that gets assigned to the Business Analyst especially in under resourced projects. This is often because the Business Analyst knows the Business Requirements so well that they are asked to also perform the testing (especially user acceptance testing). This is a very bad practice for a project in general and should be left with professional testers and business end users. Ideally, the Business Analyst should only contribute by reviewing and clarification of business requirements during the creating stage of Test Scripts.
