The missing business analysts!

Or, where da BAs at?

Business analysts are great! They examine, inspect, and define problems and solutions; create clarity; identify impacts and dependencies; network; and record critical information for anyone coming along later. Great ones build shared understanding and help organisations actually to implement changes. That’s rather a lot of helpful things!

But… for some reason BAs (short for business analysts) are usually relegated to lower-tier positions within organisations and on projects, and I’ve been doing some thinking on why that is. 

TL;DR:

⮑ Business analysts can be the piggy in the middle
⮑ And people often (mistakenly) think BAs are the masters of none!
⮑ But there’s huge skill in navigating the complexity between experts.
⮑ The truth is, sometimes a BA is the ace you need!
⮑ And we BAs can, and should, continue being awesome in the meantime 💛

Piggy in the middle

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

Despite the name, the business analyst doesn’t really even fit into the “Business” camp—that’s usually reserved for managers and advisors. We 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.

Piggy in the way

If you are trying to get answers from an expert, it is really easy to look past the business analyst role to the expert, and find the BA, well, in the way.

to do.

I hate to say it but we can be in the way.

We’ve all personally experienced the business analyst (or other middle dweller) who inhibits your ability to just talk to the person with the answers. You know, typical gatekeeping behaviour that disables communication, and rent-seeks on information flow—behaviour I’m obviously not going to defend.

Shitty behaviour aside, I think the interpretation that BAs are in the way is lacking some perspective, and I suspect that that’s because it’s easy to see it from the perspective of a single query, rather than the network that enables the query to be answered. 

If you step back, you may see that a BA can be a nexus, and not a barrier, to getting information. 

to do.

And where does the network come from? Well, mostly, it comes from the BA’s annoying and intense curiosity about everything. I don’t think I’ve met a real BA who, when encountering a new type of expert, wasn’t the first person in the room to ask, “What do you do? No seriously… what do you really do?”.

Business analysts quickly become SME-Es (subject-matter-expert-experts if you will)—walking rolodexes of internal and external contacts. 

Categorising the BA as a blocker means you miss the chance to leverage the BA’s network throughout the business. Leveraging that network to find and share information is the smart move.

But even that fairly obvious value is misunderstood.

The jack of all trades, master of none fallacy

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.

to do.

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.

Master of none?

But using the insight that a BA is conversant with many expert topics—and let’s not forget that there’s a big difference between familiarity and expertise—to conclude that BAs are the master-of-none is simply false as it assumes that there is no skill in operating in that middle space.

Which is why it’s common to add to the jack-of-all-trades-master-of-none saying a caveat: “but oftentimes better than a master of one”.

An idiot savant (to go to the extreme) struggles to operate in any space beyond the one they are extremely talented within. Now don’t get me wrong, I’m not saying that all experts are idiots, but it is fair to say that businesses and business endeavours are increasingly complex in nature, and in response, we have increasing numbers of highly skilled, but specialist roles.

And there’s a downside to specialisation, along with the specialist skills, you get a specialist mental model. Great! Now you have a specialist to solve your complex problem, but what if you have two? Or a hundred? Maintaining a shared understanding of what you’re working towards, and identifying the impacts of a change, is increasingly complex when there are so many perspectives involved.

...or master of some?

Navigating that complexity requires generalists that can not only work with a wide range of perspectives and mental models, but who thrive in that space. 

I believe firmly that the adaptability required to juggle the multiple—at times conflicting—mental models of different specialists, while connecting them back to a shared and cohesive whole is a specialist skill in itself. One that requires abstract thinking, communicating, influencing, and more. 

to do.

So no, BAs are not ‘experts’ in the traditional sense, but many are experts in wrangling divergent perspectives, mental models, and languages into understandable outputs. And it is true—before you point this out—that service designers also play in this space, but they don’t often link right through to data 😉.

That brings us to an uncomfortable truth about BA work: all of those linking, connecting, building shared language, and clear understanding skills are skills that other roles could bring to the project—these are not ‘BA specific’. But like the specialist you bring in to solve your complex migration problem, or the communications expert you hire to shape your comms strategy, the BA does this connecting for the benefit of the collective whole. 

But there is some discomfort in filling a role that doesn’t exactly ‘own’ anything. And I think that the discomfort does sometimes result in some unhelpful BA behaviour—in particular information gatekeeping, or not being communicative about what we’re working on (perhaps in an amusing effort to make our work seem more mysterious and cool).

Did I say we didn’t ‘own’ anything? I lied! We’re yet to talk about the best element of the BA role: Requirements!

Requirements aren't sexy

Requirements. The one ever-present task of the BA simply isn’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).

So no, I don’t know any BA who’s especially excited about requirements themselves (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 as little room for misinterpretation as 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. 

But even the most friendly format for requirements (a view with which I anticipate little disagreement) is the user story. 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?

to do.

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!!

Maybe not sexy but what about flexy?

Let’s be clear: As long as there’s clarity between the parties, there’s really no 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, 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 involved, you need something a little 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.

Aces in their places!

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. Basically, we’re not playing our hand well.

So here’s the call to action.

to do.

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. 

And for the aces themselves

And for the BAs in the room, let’s keep being awesome. And don’t start job hunting for that product management role just yet!

But I don’t like leaving it with a bland “be better”. So find some tips to avoid these pitfalls below. And in the meantime, stay excellent.

Tips to avoid being the piggy:
❌ Don’t block conversation (“let me find that out for you”)
✅ Do offer connections (“let me introduce you to Kamaal who’s all over this issue”)

Tips to avoid being considered a master of none:
❌ Don’t work in isolation
✅ Do be open with your work and approach
✅ Be super clear about the boundaries of your expertise

Tips to make your requirements less dull:
❌ Don’t wait until the end to document requirements
✅ Do flex the requirements to the situation, and to the process that is creating them
✅ Do ask, What is the purpose of what I’m doing, and is what I’m doing fit for that purpose?