#011 - Being a Business Analyst doesn't mean Being Anything
Welcome to Issue #011 of The Forcing Function - your guide to delivering the right outcomes for your projects and your users.
🤔 Made me think: Airlines don't generate profit by flying passengers.
👨💻 Worth checking out: Avoiding creating bad Powerpoint + avoiding a worst case power cut scenario.
If you ask 10 business analysts what they do, you'll get 10 different answers
Over the 40+ projects I've delivered as a business analyst (BA), if you ask my team what I do, you'll get different answers - even on the same project.
Those views can range from a rigid expectation of what I should do all the way to a complete misunderstanding of what my role entails. This is compounded by the high level of adaptability, flexibility, and variety that's integral to business analysis.
So, as a BA, how do you define your role before it's defined for you?
The origins of business analysis
To start answering this, you should know that business analysis is far broader than you may think.
It's the early 1940s. In the Battle of the Atlantic, Allied merchant convoys run the gauntlet of the hunting U-boat wolf packs. The Axis powers strangle this critical lifeline for the UK and the Allied war effort to retake occupied Europe.
It's the early 1970s. Fedex starts operating its overnight delivery network across 11 cities. 3 days later it shuts down with a mere 6 parcels delivered on the first day.
Linking both examples are the predecessors of business analysis. Firstly, operational research (OR) which came into its own in World War II. Then, management science which applied OR to the corporate world.
Different times, different reasons, and different audiences. But the same principles and the same purpose: to improve decision making.
The Battle of the Atlantic: By analysing prior crossings, the Allies discover the optimal convoy size, speed, and timing. This helps reduce sinkings from 1 in 10 ships to 1 in 200 - saving countless lives and much-needed resources.
FedEx: By challenging the founders' gut instincts of the original 11 cities, their advisor (Charles Brandon) quantifies the market potential of ~112 cities. A month after shutting down their service, they restart with a vastly different 26 city network and the rest is history.
Simply put, it's taking a scientific approach to understand the underlying problem, to systematically analyse and problem-solve, and to derive the best-fit solution.
The multitude of overlapping BA types
Today, a multitude of related fields can trace their origins or history back to OR and management science. Several of these fields, as they have evolved, now have their own take on what a BA does.
Some fields use the same "BA" label whilst others use a different label. But regardless, all are rooted in the same base archetype. Hence the similarity of roles, the varied types of business analysis, and the potential for misunderstanding.
A few roles which I've frequently been confused with include:
System analyst: Like a BA, they use IT systems but focus on the technology need.
Data analyst: Like a BA, they use data but focus on designing, maintaining, and mining data for analytics.
Subject matter expert: Like a BA, they use domain expertise but focus on building and understanding their knowledge.
Project manager: Like a BA, they manage stakeholders but work towards a different goal - as I wrote about in Issue 009.
And my favourite: the non-IT business analyst.
With the advent and advancement of computing, business analysis is typically closely related to IT delivery. But there are BAs who analyse companies and markets to derive business intelligence for their company.
So, it's no wonder confusion abounds. Especially when, as a BA, I do wear several of these hats at the same time on the same project. Sometimes - all of them at the same time!
Don't cover so much that you're not covering anything at all
One of the best parts I enjoy as a business analyst is working at the centre of the project.
Collaborating with stakeholders on one side and a variety of project team roles (from developers to testers to business change managers) on the other. Going from the strategic, in refining the business case, down into the minutiae of a decision matrix that's being built and tested. Being challenged to critically think not just what needs to be done but the edge cases that haven't been considered.
But all that flexibility has a dark side too.
If you're not careful:
You get stereotyped as the meeting booker, the documentation monkey, the status tracker, etc..
You become the dumping ground for anything that isn't obviously someone's role - such as coding. I've frequently had to cover the testing role and the business change role because no-one stepped up or was assigned.
You end up hiding small problems by covering for role vacancies and for team members who aren't pulling their weight. Which may then become major issues because they weren't addressed early enough.
Cope's rule in evolutionary biology suggests that species typically evolve to grow bigger. There are inherent size advantages in fighting off predators, capturing prey, and killing competitors. However, being bigger requires more energy and thus more resources. That also makes such species vulnerable to extinction.
This is a parallel for what you take on as a business analyst - both voluntarily and involuntarily. You'll undoubtedly be seen as more indispensible for taking on as much as you can. But take on too much, you won't be able to adequately fufil the role you're meant to be doing.
Thus, risking your "extinction" from the project by getting criticised or even replaced.
What does the project need?
The answer to what we should be doing mirrors what we, as BAs, ask on all of our projects: what's the requirement?
What does each of them need from me?
What services am I providing to my stakeholders, to my project team, and to the project overall?
Where are the gaps in expectation, approach, and delivery?
What's the plan and the trade offs involved in getting those gaps closed?
The answer will not be clear cut.
That's fine. It's about making everyone aware so everyone is clear on what you are doing, why, and the limitations you have.
At worst, it reduces the risk that you are spread too thin. And hopefully, you're more likely to get to do what you want to, can do, and helps grow your career.
🤔 Made me think
Airlines don't make money by flying passengers.
As someone who collects Avios points, it was fascinating learning that American Airlines (AA) values its frequent flyer scheme at ~ $25 billion. That's over 4 times their market cap.
Even more surprising is that AA lost 0.43 per passenger mile in 2018. Their profit came primarily from their frequent flyer scheme. They realised that their revenue from selling points was far higher than their cost for running the flights the points were redeemed for.
So, in a way, airlines fly passengers as a side hustle to their frequent flyer programs.
PS: In coincidental timing for this issue, British Airways just launched their Avios subscription service to buy discounted points.
👨🏻💻 Worth checking out
🔗 Really Bad Powerpoint (Seth Godin): Whilst I'm lucky to avoid doing decks, this advice from 2007 was true then and is true now.
⚡️ PowerHouse 555 (Anker): With the National Grid warning of rolling 3 hour power cuts in their worst-case scenario, the launch of this new battery (with an early-bird discount) was timely.
🖖Until next Thursday ...
If you enjoyed this newsletter, let me know with the ♥️ button or add your thoughts and questions in the comments. I read every message.
And, if your friends or colleagues might like this newsletter, do consider forwarding it to them.
For now, thank you so much for reading this week's issue of The Forcing Function and I hope that you have a great day.
PS: Thanks to P for reading drafts for me.