The Missing Business Analysts: Why BAs Are Rarely Seen at the Top

There are lots of expert capabilities involved in modern business: Design, Operations, Delivery, Technology, Data, Marketing, and Finance, to name but a few. And Business Analysts don’t really belong in any of them.

Despite the name, the Business Analyst doesn’t really even fit into the Business camp — that’s usually reserved for managers and advisors. BAs don’t have an obvious home. This is why you’ll find BAs reporting into the IT department in one organisation, delivery in another, but to a PMO in a third.

BAs operate in the space between different expert groups — they’re the proverbial piggy in the middle.

No, a BA is probably not an expert in Design, Business, Technology, Data, Marketing, or Operations.

But they understand enough of each speciality to engage meaningfully with the work in each. Want to talk a little tech? Your BA probably knows what React is and what AWS does. Want to review some wireframes? Your BA likely knows a bunch about UX and government standards. Want to strategise a product roadmap? Your BA probably knows what your competitors have been working on. Hell, want to talk about drones? Your BA probably has a passing familiarity with the topic.

I, for one, am surprisingly conversant on all things bovine.

BAs are (and should be) versed in whatever expertise is within your organisation and this does make the BA role a little bit of a jack-of-all-trades.

Requirements. The one ever-present task of the BA just ain’t sexy. Neither is it fun, exciting, shiny, or any other party word. But requirements are useful and necessary.

We live in a world of complexity. And we need a clear picture of what is needed and wanted (and that’s especially true when money is changing hands).

I don’t know any BA who’s especially excited about requirements per se (even me), but we are excited by what they represent: the closest thing to an executable definition of our shared understanding, documented in a way that leaves the absolute minimum room for misinterpretation possible.

And the truth is, everyone needs requirement specifications. My partner (to use a personal example) needs a fairly detailed specification when he goes grocery shopping or I’ll end up with some pretty unexpected, and potentially unwelcome, items. Editor: Hey!

Yet, even the most friendly format for requirements is the user story — a view with which I anticipate little disagreement. User stories are basically requirements in duplo format. And yet, even ten friendly user stories in a row can put a normal person into a coma. Why is it that stating things factually and in plain language is so boring?

It seems to me that requirements in any format are like the terms and conditions for a software update: something people assume we might need to have (or at least we’re pretty sure our lawyer would tell us is necessary), but something we’d much prefer to skip past because they’re just so dull.

So fine, we BAs are accountable for the most boring part of the whole.

Great.

Maybe BAs not being included in things is just the natural world trying to avoid the human equivalent of fine-print until you absolutely have to deal with it. But what a myopic approach!!

Let’s be clear: As long as there’s clarity between the parties, there’s really no one right way to do requirements for any given situation. This is why for a cross-functional development team requirements can be user stories and acceptance criteria, while for my partner doing the shopping, an email with a list of items (with a don’t get because we have heaps section) is usually sufficient. But for big procurement exercises — where there’s a lot of money and time and commitment involve — you need something a bit more hard core.

And I definitely believe that we BAs can sometimes be guilty of not shaping our approach to fit the situation. We like our ability statements and our acceptance criteria format and our user stories and come hell or high water, that’s what you’ll get.

And this just contributes to how we’re deployed in organisations.

All that aside, it still surprises me how infrequently we see Business Analysts really and genuinely included in big happenings within organisations. And I think it’s to the detriment of these endeavours.

But it’s also a self-fulfilling prophecy. Not utilising BAs at strategic level simply means great BAs who want to tackle harder problems end up taking non-BA roles to be professionally challenged. Often into product management, agile coaching, or business consulting.

And while those are valid career paths, and clearly utilise core BA skills, the value of a BA — as a role in and of itself — remains. Essentially, we’re not playing our hand well.

So here’s the call to action.

If you are part of an endeavour, take a look around and ask yourself: can someone with true BA skills support us to achieve our goal? Maybe, instead of defaulting to consultants to provide a cohesive picture, you should be utilising the middle-space-skills of your Business Analysts to complement your team of specialists?

Maybe a BA is the ace you’re missing.

And remember, if all you want is someone to bore you to death with requirements, that’s precisely what you are likely to get! So, save yourself the pain and invite your Business Analysts into the conversation.