(Author’s note: On August 16 and 17, 2017, I had the honor of presenting “Strategic, Tactical, and Operational Business Analysis – Three Emerging Business Analysis Careers” to the IIBA® (International Institute of Business Analysis™) Cincinnati Chapter and the Bluegrass IIBA® Chapter. Part 1 of this presentation is available here.
Strategic Business Analysis
Strategic Business Analysis (aka Enterprise Analysis) encompasses all of the pre-project work to identify business problems, define business opportunities, develop a business case, and recommend whether to initiate a project. This level of business analysis is relatively methodology independent because it has nothing to do with software development per se. The only impact is the form in which the outcome is expressed. If a traditional methodology is in place, Strategic Business Analysis delivers business strategies, goals, and objectives and develops Project Scope and Business Requirements.
For an Agile SDM, Strategic Business Analysis defines the high-level of the project in terms of Themes and Business Epics, which are less formal and postpone details until the developers need them. In either case, those performing this level of business analysis need a broad set of tools and techniques to ensure that the resulting projects support the organization’s business goals and objectives.
Tactical Business Analysis
targets the project level and is more the traditional “Business (System) Analyst” role. The selected SDM will impact this level of business analysis in two ways:
- Timing of Analysis
- Level of Detail of the Outcome
Fundamentally, Agile software development depends on Just-In-Time (JIT) analysis. Developers clarify the User Epic and/or User Story that they will develop today. This form of Tactical Business Analysis exists in traditional methodologies to ferret out Stakeholder Requirements based on the business requirements for the project. This level is most heavily impacted by Agile methodologies.
Tactical Business Analysis assumes sufficient knowledge of specific business analysis techniques to get the current job done. People who do not have a business analyst title often perform this function. At this level, Agile primarily implies a change in the timing and depth of business analysis activities. Whoever is wearing the business analyst hat maintains a backlog of Stakeholder Requirements in the form of user stories and decomposes Epics into User Stories as the development team needs them. This moves all analysis results closer to their moment of impact. The Agile team’s ability to do effective business analysis activities is one of the primary determinants of their likely success.
Operational Business Analysis
is the level most concerned with the business use of information technology. It uses Stakeholder Requirements in the traditional sense or User Stories in the Agile world to define Solution (Functional and Quality) and Transition Requirements. If the project involves packaged software, functional business analysis identifies configuration changes necessary to meet these requirements. Within an Agile project, developers themselves use business analysis techniques at this level to flush out the details of a user story or work item to the level of comfort they need to code the software. Which specific business analysis techniques work best depends heavily on the application architecture.
