Does it make sense to talk about “enterprise analysis” or “strategy analysis” in the context of business analysis?

Jun 10, 2018

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.

Like this article:
  10 members liked this article
Jun 10, 2018


trisha_mcfadyen posted on Thursday, July 19, 2018 12:46 AM
Great article Adriana. I think these scenarios are somewhat universal! One change that has helped us achieve a cultural shift is the discuss 'trade-offs' rather than prioritisation. This brings in the opportunity cost component to the conversation and helps reduced siloed thinking on the initiatives's value proposition.
abeal posted on Friday, August 17, 2018 12:55 PM
Thank you, Trisha, and apologies for the delay in my reply (I have to comment to an article before I start to receive notifications of comments).

I like your approach of discussing trade-offs to prevent siloed thinking, but I don't see it as a replacement for prioritization. Here's an example to illustrate what I'm saying:

Let's say you have one developer available to work in system enhancements for an ecommerce platform. You might look at different scenarios and the trade-offs involved ("we could postpone the work of enabling promotional coupons to Q4 and use the developer to implement the loyalty program in Q3, but that means we won't be able to take advantage of the marketing campaign already scheduled for Q3").

In the end, after evaluating your trade-offs, you'd still have to make a decision and prioritize coupons vs. loyalty program or vice-versa, no? If I missed your point, please come back and clarify so others can learn from the exchange.
GeorgeHighfield posted on Wednesday, August 29, 2018 6:20 AM
I have a question! Do you think that we can count the show projects as a business! I ask it because I'm a participant of the show and I like it so much that I've decided to try my own business! How can I analyze my future business!
Only registered users may post comments.

Latest Articles

Six Estimation Safety Tips
Oct 13, 2019
Estimation is a chronically thorny issue for software practitioners. Most people need to prepare estimates for the work they do, but in our industry w...

Copyright 2006-2019 by Modern Analyst Media LLC