Business analysis is the process of studying a business or any other organization to identify business opportunities / problem areas and suggest potential solutions. A wide range of people with various titles, roles and responsibilities actually perform business analysis within an organization.
There are three fundamentally different flavors or levels of business analysis:
- Strategic Business Analysis (aka Enterprise Analysis)
- Tactical Business Analysis
- Operational Business Analysis
Strategic Business Analysis is the study of business visions, goals, objectives, and strategies of an organization or an organizational unit to identify the desired future. It encompasses the analysis of existing organizational structure, policies, politics, problems, opportunities, and application architecture to build a business case for change. This analysis employs techniques such as Variance Analysis, Feasibility Analysis, Force Field Analysis, Decision Analysis, and Key Performance Indicators to support senior management in the decision-making process.
The primary outcome of this work is a set of defined, prioritized projects and initiatives that the organization will undertake to create the desired future. If the initiative includes the development of software using an Agile Software Development Methodology (SDM), strategic business analysis identifies themes and/or epics, and initiates a product backlog.
Tactical Business Analysis is at the project or initiative level to flush out the details of the proposed solution and to ensure that it meets the needs of the business community. Commonly used techniques at this level include Stakeholder Identification, Interviewing, Facilitation, Baselining, Coverage Matrices, MoSCoW Analysis, Benchmarking, Business Rules Analysis, Change Management, Process and Data Modeling, and Functional Decomposition.
In an Agile environment, Tactical Business Analysis adds to the Product Backlog and/or Release Plans expressed in Themes, Business Epics, Architecture Epics, User Stories, and User Story Epics. In a traditional setting, the primary outcome of Tactical Business Analysis is a set of textual and/or modeled Business and Stakeholder Requirements.
Operational Business Analysts work on specific business applications. In an Agile approach, they are members of the development team and will be heavily involved in User Story elaboration and Iteration or Sprint Planning. If they are the stewards of a packaged application, they will deal primarily with identifying how to manage the application parameters to meet evolving business needs.
Their primary techniques include Meeting Facilitation, Checklist Management, Prioritization, Process Mapping and Analysis, Business Rule Analysis, Lessons Learned Analysis, and Interface Analysis.
Few organizations staff all three levels of business analysis and even fewer use the terminology of Strategic, Tactical, and Operational Business Analyst. In many organizations, “Business Analyst” is not a job title.
In very large organizations, individuals with job titles such as Product Manager, Product Owner, Developer, Manager, Subject Matter Expert, etc. actually do business analysis at every level. In smaller organizations, a single individual is often responsible for all scales of business analysis. Regardless of who is wearing the business analysis hat, he or she may or may not have the title Business Analyst.
The Requirements Solutions Group (RSG) recently surveyed over 1700 individuals with many different job titles who were involved with business analysis at some level of detail irrespective of the SDM their organization applied to identify the tools they most commonly needed:
- Eighty percent model and identify business processes with tools such as Business Process Modeling Notation (BPMN), Activity Diagrams from the Unified Modeling Language (UML), and Data Flow Diagrams (DFD).
- Seventy-five percent model and identify business data requirements using tools such as Business Analytics, Entity/Relationship Diagrams (ERD). Business data requirements express data elements, entities, types, structures, and user views that subject matter experts need to know to be able to do their job effectively.
- Seventy-five percent identify business rules as a routine part of their jobs. Business rules describe how the organization wants to conduct its business independent of the information technology.
- Seventy-five percent do User Story and End User Acceptance Testing to ensure that the delivered IT components meet the business needs.
Seventy-five percent use backlog maintenance procedures, traceability matrices, RACI (Responsible, Accountable, Contributing, and Informed) matrices, to manage product and iteration backlogs and other forms of requirements.
- Sixty-five percent facilitate Story Workshops, Release Planning Sessions, Iteration Planning Sessions, and Requirements Discovery Workshops to identify business problems and express business, stakeholder, and solution requirements.
- Sixty-five percent use Story Points, Function Points, and other estimating techniques for release planning and project scoping
Fifty-five percent write Business Use Cases, a specific form of functional solution requirements that focus on the interaction between the technology solution and the people using it.
The question then becomes, “What are the techniques used for business analysis?”
For an answer to that question, we can look to the International Institute of Business Analysis (IIBA®).
The IIBA® is an organization dedicated to defining standards and practices for the business analyst community. A 2008 survey of around 1200 business analysts asked what specific techniques business analysts needed to do their job. The responses are revealing as a list of topics that those who need to do business analysis work should know:
- Ninety-five percent use brainstorming as a tool for business problem identification and solution definition
- Ninety-two percent deal with change requests for managing requirements
- Ninety-one percent need interviewing skills to elicit problems and requirements from stakeholders
- An equal percentage apply requirements-based acceptance testing
- Eighty-nine percent use visual diagramming techniques such as process models, data models, activity diagrams, etc.
- Eighty-six percent depend on a Stakeholder List as a tool for ensuring requirements completeness
- Eighty-three percent identify defect/issue tracking as techniques required for their job
- Eighty percent facilitate Requirements Workshops to ensure subject matter expert buy-in and acceptance
Business analysts need many other techniques depending on their responsibilities in a specific organization. Examples include topics like prototyping, impact analysis, surveys/questionnaires, structured walkthroughs, document analysis, test case development, and more.
Bottom line, the duties of a business analyst are non-trivial, the variety of tools and techniques used are substantial, and the amount of training needed to be effective in that role is significant.
Finally, all of those statements apply to you when you are wearing the business analysis hat even if you do not have the “Business Analyst” title.