The Forgotten Middle Child - The Business Analyst

Semantics matter! - Business Analysis is NOT Business Analytics

In my humble opinion, Business Analysis is a severely overlooked, misunderstood and underestimated role. Especially when compared to its much newer, shinier and trendy sister, Business Analytics. 

Unlike Business Analytics, Business Analysis is not a role about data, trends or forecasting – though they can be a helpful tool occasionally. It is about people, processes and the creation of meaningful business value. (Learn more about their differences here).

Nothing frustrates me more than seeing budding IT professionals continuously getting them mixed up. Worse still, there’s no tertiary degree, no comprehensive diploma or specialised curriculum that fully encompasses what it means to be an IT professional specialising in Business Analysis. Just a singular module amongst 24 or 32 others that is constantly outshined by trendier topics like AI or Data Science. Adding salt to injury, we often get saddled with the job title of a “Business Analyst”, an identical designation to one who specialises in Data Analytics for Businesses or, my dreaded nightmare, Finance.

So what does it actually mean to be a BA that is an “IT professional specialising in Business Analysis”? What makes this role survive the test of time and change, and yet continually be overlooked, misunderstood and underestimated? What does it take to stand firm amongst the hubbub of this ever-changing and evolving industry?

BAs are more than just Requirement Gatherers and Solution Designers

Ironically, the best BAs that I’ve met do the exact opposite. They don’t stand out (on their own). They constantly adapt and evolve. They don’t jump into problem-solving. I mean, yes they solve problems, they just don’t do it first.

What is constant amongst all the best BAs I’ve worked with is their focus, their empathy and their curiosity to solve business problems. We spend more time understanding the WHYs behind the requirements, the NEEDs to be satisfied and the PAIN POINTs to be eliminated. Even if the requirement is as simple as “I need an app to log and track maintenance issues”, our follow up question is always “Why?”. Specifically, why does the existing process not work for you?

This line of questioning doesn't just stop there. It's everywhere - posed to every requirement and most answering responses. It goes back and forth, like that really annoying conversation with your two-year-old nephew. It's asked at every turn throughout the project, not just at the start. Everyone is interrogated, not just the client, but also our developers, testers, ourselves. 

“Why does this problem matter?” 

“Why hasn't it been solved, or better yet been avoided, in the past?” 

“Why now?” 

“Why? Why? Why?”

It is truly astounding, the level of empathy one develops for another human when we put understanding the problem first. Better yet, the simplicity of the solution(s) we can put forth when the true root of the issue is uncovered. 

Almost unbelievably, a majority of the recommendations we make at Mavericks aren't technical solutions. They are process adjustments and role changes, in other words, people changes – changes in the way that people work and think. 

Which makes sense when you think about it. Most, if not all problems in the world are created by people, so it would stand to reason that a good number of problems can be solved by people! 

To us, technology is more of a supportive aid to help empower a better way of working. Because if the fundamental way of doing things is ineffective and inefficient for the business needs, then no amount of sexy technology and ingenious solutions will make it work – short of taking humans out of the equation entirely and replacing it with AI, I suppose.

Being a BA: Separating the average from the BEST

So my takeaways from working with some of the brightest BAs in tech:

1. No two problems are truly the same

There are far too many confounding factors to a problem for them to truly be the same. From the tools and technology used, the Frankenstein processes made from patchwork fixes, to the very people with their different personalities and perspectives. 

So treat each business problem like a new one. Take the time to investigate, empathise and truly discover the essence of your client’s problem. Imagine each visible problem as a visible symptom. The tip of the iceberg, if you will. And remember, we’re here to solve our client’s problems, not our interpretation of their problem. 

Don’t. 

Make. 

Assumptions. 

2. Every action (and inaction) has a consequence

This variation of Newton’s Third Law of Motion means so much more to me now than when I was in my Physics classrooms. 

Organisations are a living breathing organism. It’s made up of systems (processes), organs (departments) and cells (people). So it’s only appropriate to treat every problem, every solution, every change with some degree of caution. We don’t want to create unintended consequences, especially when they could have been avoided by asking the right questions to the right people. 

Since my time at Mavericks, I’ve come to understand the importance of “Systems Thinking”. A quick Google Search will land you with the definition that “systems thinking is a holistic approach that views problems and solutions within the context of a larger system, emphasizing interconnectedness and relationships between parts rather than focusing on individual components”. 

But what few articles seem to emphasise is that it’s virtually impossible, and very, very impractical, to expect that a singular person fully understands every nuance of the current system. Worse still, that the current system will stay the same or maintain some level of predictability in times of change.

The only real variable that can be relied upon is that there is and always will be people involved in the decision-making, and being affected by said decisions. Hence, rather than spending days or weeks analysing and hypothesising on what things might be, our approach is to take the initiative to observe, question and challenge the status quo. Involve the people. Invite new perspectives. Collaborate on solutions. Truly immerse ourselves as part of the ecosystem. Until we can run it like we own it.

The Conclusion

So back to the original question, why are the best BAs overlooked, misunderstood and underestimated? 

I think it’s precisely because the best BAs don’t stand out. They don’t want to. It’s never their priority. They spend their time helping people realise their own problems and finding the right people to collaborate on a meaningful solution. There’s no glory to claim as their own because the tangible, visible, positive change comes from their team that they helped to build. 

When I first heard my mentors lovingly lament that their job was “always about solving people problems”. I couldn’t agree more. The best BAs facilitate rather than manage. They lead, but mostly in servant leadership than any other form of leadership. Because problems borne from people can really only truly be solved by people. Not a person, singular.  

And maybe it’s because of this that there’s no real need for a degree or some kind of institutionalised qualification for it. Afterall, the solving of people and process problems requires more than just intelligence or an IT background. It takes empathy, curiosity and patience (way, way too much of it). It requires becoming the master of your self, to put others first and letting them shine as you move in the shadows.