How are top-performing business analysts different than an average BA?


During a recent presentation to business analysts, I used one of my consulting projects as an example of how to apply an analysis technique we were discussing. A member of the audience asked,

“What made this company hire you as a BA consultant to tackle this project, when they already have so many in-house product managers and business analysts on their teams?”

What is interesting about this question is that it brings light to a reality that I think isn’t discussed enough by the business analysis community:

Companies are compelled to hire external business analysts not only when they have reached capacity and need extra help, but also when they’re not seeing the expected results from their internal team of BAs or product managers.

My conclusion, based on what I’ve observed during my eighteen years of experience in business analysis serving dozens of companies with 40 to 40,000 employees, is that the main cause of this performance gap is the fact that average BAs treat stakeholder requests as the focal point of their analysis.

To illustrate what I mean, let’s look at an example from a company that develops software applications used by thousands of client organizations. When a feature is requested by a significant number of customers, the product manager prioritizes the request and documents the requirements for the development team.

I was hired to help the company reduce customer churn. As part of my review of the product roadmaps, I learned that one of the applications had a popular request: the ability to create accounts for users with an email address different from the customer’s domain. (For example, create an account for an email ending in when the company’s email ends in

The rule “accounts can only be created for email addresses matching the company’s domain” had been implemented at the request of a set of customers who saw this as a desired mechanism to minimize the risk of unauthorized people gaining access to sensitive information they store in the application. Now the team was planning to build a capability to allow individual customers to turn this restriction on or off so they could use their preferred policy.

However, when I talked to a few customers who submitted the request, it turned out that their main scenario was a lawyer or external subject matter expert needing to immediately check some content residing on a single screen of the application so they could provide an opinion on the content and how it was displayed. That meant that creating a user account for the external user wasn’t necessarily the best solution for the problem. An admin would have to create the account and then delete it once the task was accomplished, or costly capabilities would have to be built to enable accounts to be set up with an expiration date in order to mitigate the risk of future unauthorized access.

Armed with this knowledge, it wasn’t difficult for me to identify other potential solutions (including a simple screenshot of the content to be forwarded to the third-party email address with a review request). The winning alternative, based on an analysis of value, usability, feasibility, risk, and cost of implementation, was substantially different from what had been requested, and left the customers much happier than they’d have been if they’d been granted their original wish:

Instead of having to log in to the system to visualize a single screen, external users would receive a temporary, secret link via email that would grant them them access to the screen during a 48-hour interval.

Let’s compare this solution with the original request submitted by customers and prioritized for delivered by the product manager:

Original solution: Enable people with external email addresses to obtain login credentials so they can access information stored in the system.

  1. Customer admin configures the application to enable the creation of accounts with external email addresses.
  2. Internal user requests admin to create an external user account.
  3. Admin user creates account and notifies internal user that the request was granted.
  4. System sends credentials to external user.
  5. Internal user sends instructions to external user on how to navigate to the content they’re supposed to review after logging in.
  6. Internal user logs in and follows the instructions to access the content.
  7. Internal user informs admin that the external user account is no longer needed.
  8. Admin deletes the external user account.

Implemented solution: Enable people with external email addresses to use a temporary link to access information stored in the system.

  1. Customer admin grants permissions to internal users to create external links.
  2. Internal user goes to the screen that has the content to share, and selects the option to send a temporary link to the email address(es) they type in.
  3. System creates the link and sends it via email to the specified recipient(s) with a notice that it will expire in 48 hours.

The recommended solution left everybody happier:

  • Admin users don’t have to get involved in the process of sharing content with external users.
  • External users don’t have to remember a username and password combination and learn how to navigate to the content they need to review.
  • Internal users don’t have to contact an admin to request an external user account, instruct the external user how to access the content, and remember to request account termination when it’s no longer required. They only have to go to the screen to be shared, select an option “share with external user”, and provide the email address to which the temporary link will be delivered.
  • The company mitigated the risk of an external user gaining unauthorized access to sensitive information in the application (only the specific piece of content is shared via a temporary link that automatically expires).
  • The work of the development and testing teams was substantially reduced. The effort to create the temporary link was much smaller than the changes required to create a user role with limited privileges to limit external user access (not to mention the potential need to develop the ability to automatically expire external user accounts to eliminate the risks of they accidentally remaining active for an indefinite length of time due ).

As you read this case study, you probably experienced one of these three reactions:

  1. Come on, this is so obvious! Clearly it must have been an incompetent BA who failed to validate the problem and explore alternative ideas before specifying a solution based on the customer requests.
  2. Well, it’s easier said than done. When an external or internal customer comes to me with a request, I try to get them to explain why they need the feature, but often they’ll insist that they already know what is needed, and tell me to just document the requirements so the development work can start.
  3. Wait! I thought I was doing the right thing by listening closely to my stakeholders and documenting requirements that reflect their wishes. Are you saying this is not what my employer wants?

Each of these reactions says something about your competence level in business analysis--let’s look at them one by one.

Category #1: Unconsciously or Consciously Competent
“It’s obvious that a BA should spend time understanding the problem and exploring the solution space before starting to specify the product to be delivered. Any analyst who doesn’t do that isn’t worth the title.”

If this was your reaction to the case study, congratulations! Most likely you’re unconsciously competent in the art of identifying the right problem to solve and evaluating the candidate solutions before recommending a course of action.

It’s also possible that you fit into the category of consciously competent in this skill. You are capable of breaking down the process into steps that get the job done--even if it requires a significant amount of effort on your part.

BAs who are consciously or unconsciously competent in articulating business problems may be unaware of the struggles other BAs face to acquire this skill. Earlier in my consulting career, my assumption was that I was being hired by companies particularly bad at recruiting business analysts. In my mind, they would hire untrained BAs, neglect to educate them properly, and then shrug their shoulders and bring in a more skilled consultant whenever they had a high-stakes project that didn’t leave room for mistakes. Only after I started to provide one-on-one coaching for BAs at Fortune 500 companies I realized that a surprising high number of BAs with many years of experience, lots of training, and even BA certifications, fail to properly articulate the business problem they’re trying to solve. It’s not that these BAs are unskilled or negligent; they typically fall into the category #2 below.

Category #2 - Consciously Incompetent
“It’s not that I don’t try; my stakeholders simply refuse to answer my questions, and I don’t know how to convince them to dedicate time to clarifying the business problem they’re trying to solve.”

BAs with this kind of reaction can be classified as “consciously incompetent”. They recognize their deficit (and hopefully the value of developing skills to address it), but just haven’t yet achieved a level of competence that allows them to get to the bottom of the business problem to be solved.

The biggest obstacle for these BAs tends to be finding a good coach to help them develop the skill with the help of deliberate practice and direct feedback. Some may try to learn on their own using books or other resources, and give up when the results are not there, assuming that their stakeholders are just difficult and unlikely to change, when the problem is actually the approach they’re using.

For example, I’ve seen many books suggest the Five Whys as a useful technique to get to the root cause of a problem. While I agree it’s a valuable tool for BAs analyzing a problem, during stakeholders interactions it frequently backfires. “Channeling your inner child” to ask why repeatedly is unlikely to go well with many of our interlocutors. Stakeholders may get defensive, thinking their ideas are being challenged. Or they might become frustrated due to their conviction that they’ve already identified the best solution, and pausing to explain their rationale is simply a waste of time.

Another contributor for the shortcomings of the “consciously incompetent BA” is the unrealistic expectations they tend to place on their stakeholders. For example, they expect business people who bring up a solution idea to be able to offer clear answers to questions like “what is the business goal behind this project?” or “what problem are you trying to solve?”. Most people aren’t good at articulating their perceived issue, and instead will default to describing the concrete solution they’re proposing.

Fortunately, these are fixable problems. The solution starts with learning to ask better questions. The questions that tend to produce the best results are the ones that help your stakeholders think about the change they want to see in the world. For example:

  • If this project is completed successfully, what will be different? What will users be able to do then that they can’t do now?
  • Let’s say the company decided not to address this problem. What would be the consequences of doing nothing?

This line of questioning tends to be much more effective than hoping your stakeholder will come prepared with a well-defined problem statement when they bring a new idea or change request to the table.

Category #3 - Unconsciously Incompetent
“I don’t know what you’re talking about. I listen closely to what my stakeholders say and deliver requirements that describe precisely the solution they’re asking for. Isn’t that what I’m supposed to be doing?”

It’s unlikely that anyone reading this article will fit into this category. After all, a business analyst who dedicates time to reading articles at Modern Analyst is certainly aware of the importance of defining the problem to be solved and evaluating alternative solutions--including the option of “doing nothing”--before starting to document detailed requirements for their project.

Still, it’s useful to recognize that this category exists. When you encounter someone who behaves like this in your workplace, see if you can steer them in the right direction. For example, online resources like the ones found here at can help them change their mindset from being an “order taker” to the anecdotal input from stakeholders as just one of the inputs to their analytical process.

# # #

A BA who treats customer stated needs, wants, demands, desires, ideas, specifications as the focal point of their analysis is likely to solve the wrong problem or address a problem manifestation rather than the underlying issue affecting the business. There is a steep price to be paid by organizations that leave this problem unchecked.

Companies that care about maximizing the value delivered by their software projects will look for BAs who are consciously or unconsciously competent in the matters of problem definition and solution evaluation. The project sponsor or hiring manager may not be able to articulate what they’re seeking on those specific terms, but this is the real performance gap that drives them to look beyond their “pool of average BAs” when staffing an important project.

Author: Adriana Beal, Principal Consultant, Beal Projects LLC

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. As the principal consultant at Beal Projects LLC, she works with SaaS and software development companies to improve the value delivered by software projects. Adriana is the author of the online program Crafting Better Requirements and the ebooks Tested Stakeholder Interviewing Methods for Business Analysts and Measuring the Performance of Business Analysts. She is a regular presenter at IIBA conferences and monthly events, and the host of the Business Analysis Leadership group, an online community founded in 2016 to help members get new ideas, tools and processes that can mean the difference between failure and success as a BA manager.

Like this article:
  91 members liked this article


Serj Kornev posted on Saturday, February 10, 2018 10:09 AM
This is an excellent piece of knowledge that spotlights an important issue within the core skill set of a BA - the ability to analyze requirements gathered from stakeholders. Indeed, it is easy to lose track of digging to the root cause while welcoming stakeholders' input on their perceived problems.
A high-performing BA is not only able to elicit the true business/user needs from the feedback that varies in depth and consistency, but also is she capable in articulating the underlying problems and synthesized solutions to the stakeholders so they can rest assured their ideas are getting implemented in the best way possible.
Adriana Beal posted on Wednesday, February 14, 2018 9:46 AM
Thank you for taking the time to leave your comment, SerjKo.

I'm glad to see people recognizing the importance of changing the focus of the initial analysis from feature specification to problem definition. Knowing what problem needs to be solved is often more difficult than solving the problem. BAs who stick longer to the "problem space" before jumping into the "solution space" invariably accomplish more than their peers.
Douglas posted on Tuesday, February 20, 2018 10:01 AM
This article highlights the need for BA's to REALLY LISTEN. Being able to decipher the core requirements is critical. A good requirement is more than "create this report". Experienced BA's will understand how a user consumes the 'required' report. If the report leads to more manual tabulation, then should the data be automated or integrated? We need to continue the elicitation process until we mentally place ourselves into the user's environment and understand the 'why' underneath the 'what'. The user often has a solution in mind based on their limited vision of the options. Successful BA's help developers create a simple solution exceeding core requirements while minimizing technical debt.
Adriana Beal posted on Tuesday, February 20, 2018 10:51 AM
Very true, Douglas. Users often have a solution in mind that isn't ideal because it's limited by what they already know is possible or desirable, and successful BAs play a key role in finding a superior solution to address the real need.

I'd only suggest tweaking your example because before we start to investigate how a user will consume the "required" report and whether it should be automated or integrated, we need to validate that a report is indeed the best solution for the problem at hand.

Many times during my career as a business analyst I was asked to document the requirements for a new report when what was truly needed was a completely different solution (such as an alert issued when some threshold in the data was reached so a manager could take action, or a filter added to an existing report).

In order to deliver the solution that will create the most value, we must go through the 5 steps in problem-solving I describe here: And the first step is digging deeper to get to the essence of the business problem behind a request like "create this report" before starting the requirements work.

Thanks for joining the conversation!

SeasonedBSA posted on Friday, August 17, 2018 12:33 AM
Excellent article, Adriana. In instances like this, I think everyone would benefit through collaboration, creating a win-win situation for all. Of course, apart from developing the art of listening, a competent Analyst would also go the extra mile to dig deeper behind a "problem" or "request" to know the "why" aspects; However, I do have a question for Adriana :) - supposing the entire project team is in unanimous favor of overriding your solution, even though, your solution appear more sensible in the business context and usage, what do you do? would you rather go with the flow and later on make them eat their words?
Adriana Beal posted on Friday, August 17, 2018 12:47 PM
Hi SeasonedBSA,

Thank you for the compliment and the great question.

"Supposing the entire project team is in unanimous favor of overriding your solution, even though, your solution appear more sensible in the business context and usage, what do you do? would you rather go with the flow and later on make them eat their words?"

If you haven't convinced at least a few team members that your solution is better (to then employ as allies in an effort to convince the rest), one of the following are likely to be true: a) you might be wrong about your solution being superior; b) there might be hidden motives (legitimate or not) at play for people to remain attached to an inferior solution; c) you are right, there aren't hidden motives, but you did a poor job building the case for your alternative course of action.

To address "c", I've written another article that you can find here:

If people decide to go with an inferior solution after you successfully proved your point, there's not much you can do. After a final decision is made, even if you're still convinced you're right, it's your job to get behind the direction set by the decision-maker (i.e. "go with the flow" as you put it). If you can't see yourself doing that, the right thing to do is to resign so you're not sabotaging the team's effort.

And let's say people ignore your recommendations and later you're proved right. I'm yet to see people freely admit their mistake and "eat their words"--even when the project has to be redone from scratch using your previously rejected solution. From experience, it's a good idea to free yourself from the expectation of being vindicated. The best approach in these cases is to simply derive satisfaction from the fact that you had better vision, came up with a higher-value solution, and did your best to present your case.
Serj Kornev posted on Friday, August 17, 2018 1:22 PM
Excellent reply, Adriana!
(Happy to be subscribed for comments)
To me, this well-articulated note sounds like a great add-on to the article as it sheds light on another aspect of how high-performing BAs are different from the rest of the market. To excel
Serj Kornev posted on Friday, August 17, 2018 1:28 PM
To excel as a BA, you are going to need to find ways of pitching problems/solutions to stakeholders and dealing with rejections.
Adriana Beal posted on Friday, August 17, 2018 1:46 PM
@SerjKo: Thanks, and I agree, learning how to pitch your ideas well and deal with rejection are both key to becoming a high-performing BA.

Due to the nature of their work, analysts often develop a better picture of what represents a superior solution, but that doesn't mean their ideas will always win the minds and hearts of decision-makers. In my career I learned that keeping track of our predictions and how they turned out is a great way to improve and validate our good judgment, not to mention gain the satisfaction of knowing we were right even if no one recognizes it publicly ;-).
SeasonedBSA posted on Friday, August 17, 2018 8:56 PM
Thanks, Adriana and SerjKo, for your fantastic replies. Thanks for pointing me to that link.

It is true that at times I have fallen into one those 3 brackets you've mentioned above, during my work! Those times, I have taken things too personally, my motivation dropped, when all I was trying was to add value to work; There were also times, senior stakeholders, after having realised previous folly, made them think twice before any outright rejections and actually acknowledged my positive suggestions that have resulted in favour of the business. Sweet moments. But, what you've mentioned is so true, that even the most high-performing BA can falter at times. After all, it is not an individual contest. Thanks again, Adriana and SerjKo.
Please keep your articles coming here, it is wonderful to read and learn from them :-)
steve posted on Thursday, December 13, 2018 4:52 PM
Adriana, As Siskel and Ebert used to say, "Two thumbs up!"
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC