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 @othercompany.com when the company’s email ends in @ourcompany.com.)

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 modernanalyst.com 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.