The difference between an average and a high-performing business analyst

When asked to describe their role, many business analysts working on customer-facing software products or internal information systems use terms like “liaison”, “bridge”, “communication line”, and “translator”, typically referring to work they do to make sure “what the business has in mind for a computerized system is accurately understood by the technical team”.

This interpretation of the BA job is very limiting. It comes with an implied assumption that someone on the business side has done the proper analysis of the business problem, and the job of the BA is limited to finding a common language and ensuring the objectives between the two groups are aligned so that the need communicated by the business can be fulfilled by the IT or software engineering team.

Every time I started a position involving business analysis, I took a different approach, making my #1 job not develop requirements that translated the business and user needs into a technical solution, but to make sure all software solutions I worked on had a clear business motivation in sync with the business strategy.

This shift in perspective can quickly take you from a reactive to a more proactive position in your organization. Here’s an example to illustrate the difference:

Jim, the average BA

Tom, the business stakeholder: “Hi, Jim! We just received a report from the customer success team showing that we have a large number of customers complaning about the latency of the Orders Placed page. It’s imperative that we fix this issue so we can increase customer satisfaction. Can you make sure the IT team makes the Orders Placed page run faster?”

Jim, the average BA: “Sure, Tom! Let me get right to work.”

Jim goes talk to the development team, discovers that the Orders Placed page takes between 8 and 12 seconds to download, and that with some significant work, can have its latency reduced to 4-6 second. He then writes the requirement:

“The Orders page shall download completely within 6 seconds over a 20 Mbps or faster Internet connection.”

Tom signs off on the requirement, and the work is handed to the development and testing teams. Two months later, the change goes live, but with little impact to the business in terms of customer satisfaction or retention. What went wrong?

Jane, the high-performng BA

Tom, the business stakeholder: “Hi, Jane! We just received a report from the customer success team showing that we have a large number of customers complaining about the latency of the Orders Placed page. It’s imperative that we fix this issue so we can increase customer satisfaction. Can you make sure the IT team makes the Orders Placed page run faster?”

Jane, the high-performing BA: “Sure, Tom! Can I look for a 15-min slot on your calendar for us to go over your findings and make sure I have all the information I need to proceed?”

Tom, the business stakeholder: “That works, thanks!”.

Jane talks to Tom to gather more information. She also schedules some time with the head of the customer success team and the system’s tech lead to better understand the context of the complaints received, and learns the following:

  • Only customers using the old version of the application are complaining that the Orders Placed page is too slow.
  • The latency of the Orders Placed page has not changed between the old and the new version. What changed was simply that the new version uses incremental rendering to start displaying content as it becomes available, rather than waiting to display the complete page only after it’s fully downloaded. Even though in the new version the customer still has to wait until the page is entirely downloaded in order to interact with it and get the information they need, the perception of slowness is no longer there.
  • The customers in the old version are legacy customers who aren’t considered “ideal customers” for the business. Their lack of commitment to upgrade to the new version is just one more sign they’re not extracting enough value from the relationship to remain customers in the long run.
  • The current focus of the business is to increase satisfaction and retention rates among its  group of “ideal customers”, who are already in the new version and happy with the performance of the Orders Placed page.
  • The chief complaint within the “ideal customers” group is not that the Orders Placed is too slow, but rather that the information offered about the estimated delivery time is often wrong.

Armed with all this information, Jane can go back to Tom with a better diagnosis of the problem.

Jane, the high-performing BA: “Tom. looks like making the Orders Placed page run faster is not going to help you achieve your business objectives. Here’s what I learned [ summarizes the key points from her investigation ], and here’s how I recommend we proceed…”.

Jane can now work with Tom on a plan to increase the accuracy of the estimated delivery time. Any changes that are required in the system to achieve this objective (e.g., querying the shipping carriers more often, refreshing the EDT more often) can be tackled by the developers who would otherwise be busy making the page load faster with little to no impact to the desired business outcomes.

# # #

When a BA is doing only reactive work, he or she is more likely to have people questioning the need for the role. After all, why can’t Tom the business stakeholder go directly talk to Jeff the developer about “making the Orders Placed page faster”?

The more proactive your work becomes, the less risk you face of your job being considered superfluous. A business analyst can deliver incredible value to an organization by going beyond understanding and translating the wants and desires of the business stakeholders to technical stakeholders. High-performing BAs also avoid the risk unnecessary scope creep that reactive BAs constantly face. You’ll know you’ve become a high-performing BA when you’re helping the business answer two fundamental questions before getting into “solution mode”:

  • What is the real problem to be solved here?
  • Is this problem even worth solving?


# # #

Interested in getting better at problem definition?

Register to our free email course “Understanding the problem: A key step to being a successful problem-solver” using this form.