The term enterprise analysis, or its revised form, strategy analysis, is often used to describe the work done by business analysts to determine the business need across an organization and recommend solutions to allow the organization to meet its strategic objectives.
The impetus for adopting terms like these seem to come from the fact that business analysis is typically seen as a tactical, solution-oriented activity. When we define business analyst as a professional who “works at a tactical level solving specific business problems, typically through the implementation of information systems”, we naturally see the need to adopt a different term to describe the work of identifying, scoping, and prioritizing projects and initiatives aligned with the company strategy.
The latter is precisely the work I was doing recently while consulting with a large company in two “strategy refresh” projects. A general manager in charge of multiple lines of software products hired me to help figure out which products deserved to continue receiving investments in development and marketing, and which should be shifting into “maintenance mode” and preparing for retirement. While my activities involved recommending business initiatives aligned with the corporate goals and strategy, using the term enterprise analysis to describe my work would have been misleading. The company has several other lines of business that weren’t part of the scope of my projects, so I wasn’t addressing needs at the enterprise level.
I suppose this work could be classified as “strategy analysis” given the fact that I was identifying actions to be initiated and efforts to be stopped to better align execution with the company strategy. But why can’t we call that work “business analysis” too? To me, changing the name only serves to create the wrong impression that the analytical approach has to change when we shift from tactical to strategic focus.
Sure, while doing “strategic work”, my deliverables don’t include detailed functional requirements documents like in a “tactical” job. But in reality, the techniques I use in these kinds of projects are precisely the same I apply when doing tactical-level BA work defining the requirements for a new software project. They include things like brainstorming, interview, observation, problem analysis, root cause analysis, visual models, design thinking, etc. And the goals are still to get to the essence of the business need, ensure we’re working on the right problems, and devise the best solutions.
A benefit that I see of moving away from terms like enterprise analysis and strategy analysis is that removing this division between “flavors” of business analysis helps us see more clearly how BA activities can add value at all levels of the organization. Whether we’re making project portfolio recommendations or specifying a tiny software feature, the purpose is the same: help stakeholders clarify the real business need and determine the best solution to address it.
No matter how small our project or initiative is, it’s still critical to understand the big picture surrounding the effort: the problem or opportunity to be addressed; why it matters in the context of the company strategy; the desired outcomes; the success metrics.
As Roger L. Martin wrote for HBR back in 2013, strategy is what allows an organization to develop a coherent portfolio of projects and initiatives:
“That strategy is a singular thing; there is one strategy for a given business — not a set of strategies. It is one integrated set of choices: what is our winning aspiration; where will we play; how will we win; what capabilities need to be in place; and what management systems must be instituted?
That strategy tells you what initiatives actually make sense and are likely to produce the result you actually want. Such a strategy actually makes planning easy. There are fewer fights about which initiatives should and should not make the list, because the strategy enables discernment of what is critical and what is not.”
Regardless of the level in which they’re operating (organizational, process, system, software application level), a tough question BAs need to be able to answer in each initiative they’re assigned to is: “How does this project/feature/requirement I’m working on contribute to the organization’s strategy?”
Even a relatively small change request can and should have its value judged based upon its contribution for the company strategy. Take for example a request from a business stakeholder to modify the company’s payment processing system so that a payment method favored by small and medium businesses can be accepted. If the company strategy is to move away from the SMB customer segment and focus on large enterprises to increase profitability, the business analyst should be challenging the idea of prioritizing this feature for delivery. A larger contribution will result from flagging a requested feature in conflict with business objectives than from going down the path of specifying what appears to be the “perfect” requirements that developers implement to deliver zero or negative value.
In any organization there are always more problems to solve and opportunities to pursue than there is time and resources to work on them. Effective business analysts spend considerable time thinking more broadly about the intent behind each new proposed initiative, project, or feature. They use a disciplined approach to help their organization establish the linkage between strategy and execution and prioritize the projects that are most important to support the company strategy. The approach to business analysis these BAs take is such that any attempt to separate “strategy analysis” from “business analysis” can easily become a moot point.
What about you? Do you find it useful in your organization to make a distinction between business analysis and enterprise or strategy analysis? Does your organization’s approach to business analysis enable BAs to connect their individual work to the company strategy?
Author: Adriana Beal
Adriana Beal has developed a successful career in business analysis and product management, having lead the investigation of business problems, defined winning solutions, and written requirements documents for a large number complex software projects. She is the designer and instructor of Crafting Better Requirements, an online program that has helped hundreds of business analysts improve their requirements documentation and communication skills, and Understanding the Problem, a self-study e-course that helps BAs develop more effective problem-solving habits. She’s also the author of the e-books Measuring the Performance of Business Analysts and Tested Stakeholder Interviewing Methods for Business Analysts.