The business analyst primer!

It has been a while since I was last in an environment where business analysts weren’t a common feature in the “getting stuff done” landscape. I mean, I know I’m a business analyst so everywhere I was, there was – technically speaking – always a BA. But it was never just me.

There were lots of us! And we were everywhere!

So when I was told by a couple of managers some time ago that they “don’t usually work with business analysts” and “it’s not common where they are from,” I was really thrown! 🤯

But, it also explained A LOT about the dysfunction I was seeing in the project. The delivery team had BAs. But also had leaders who didn’t know how to deploy them.

Now, pretty much all my other writing is about how you want business analysts on your team, but the truth is, you don’t actually need business analysts. But here’s the kicker. If you do have business analysts – using them in the wrong way will cause more damage than not having them at all.

In other words: either have them or don’t, but the very worst thing is having them, but not enabling them to be their best.

So, this article is for anyone who works with business analysts and wants to get the best from them. I want to help you to do that.

And it is actually really simple. There are five things you have to nail to get the most from your business analyst(s). They are👇

1. Bring ‘em in at the right time ⏰
2. Feed ‘em problems 🍔
3. Plug ‘em into the network 🔌
4. Let ‘em do their job! 🏁
5. Trust is essential 💫

But first, a short introduction to business analysis for those of you who haven’t worked with a BA before (as shocking as that is to me) …

My go-to proper definition for a business analyst is:

An internal consultancy role that has the responsibility for investigating business situations, identifying and evaluating options for improving business systems, defining requirements and ensuring the effective use of information systems in meeting the needs of the business.”

Paul, D. et al, “Business Analysis”  2010, BCS, Swindon

Helpful, no?

But is a bit too abstract for our purposes. Let’s make it more concrete.

A business analyst is a common role in projects or in delivery departments of medium to large organisations. BAs typically report to a product owner, product manager, or project manager. An interesting feature of the role is that it almost never holds decision-making power. That sits with the product owner or other manager.

The role is varied, and exactly what the business analyst does depends on the environment. But some typical BA responsibilities in the delivery space are:

1. Digging into the details of a process or problem to find out what is needed by the business: “so the accounting team apparently wants a new report - I’ll find out exactly they’re looking for”
2. Liaising with subject matter experts to make sure the situation is understood on both sides: “so when you receive the order it gets marked as ‘in progress’ – is that right?”
3. Documenting what’s going on: “this process map captures what happens currently”
4. Analysing options and making recommendations: “we have a number of options, but #2 is the best because it minimises the security risk involved while not adding workload to the support team”
5. Defining acceptance criteria so the team knows what needs to happen: “on submission of the application, a case is created”
6. Working with the Product Owner to prioritise the backlog: “this, this, and this are the absolutely non-negotiable bits of the feature, and these other tickets are the enhancements”
7. Working with the team to iron out the details: “now I get it! If the microservice is already enforcing that formatting, then that means that adding more validation isn’t necessary!”

There’s far more to it, but that covers a lot of what you can expect from a business analyst in the delivery space.

But, better than me nattering on, here’s a comment from someone on LinkedIn:

I do analysis. I’m not about the product/solution/service, I’m about all three and how they fit across the wider landscape of the business, its sector and society. I inspect what needs to be inspected. I visualise what needs of be visualised. I bring together people that need to be brought together to articulate the big picture. I do this with no motives, an adaptive set of tools and techniques, and boundless enthusiasm to make a positive change. Call me what you like … I’m me and I identify as a BA!

Isn’t that just the neatest summary and best comment ever?

If it’s not obvious, you are missing out if you haven’t worked with business analysts before. Missing out big time.

But now that you know what a business analyst is and does, let’s jump into the five things that you have to nail to get the best from them!

To set your business analyst up for success, you want to bring them into the conversation at the right time. And the right time is usually much earlier than you’d think!

If your business analyst uses inadequate or wrong information as inputs to their analysis, then you won’t get great results. Garbage in, garbage out, as they say. 🗑️

I cannot overstate the value of fully understanding the background of an issue, the context, the opinions, the options considered, and even discounted solution ideas (and why the issue wasn’t taken forward). These are all helpful datapoints that should inform any subsequent analysis.

The irony of mis-timing bringing your business analyst in is that it will actually slow things down later. If you’ve missed the correct on-ramp, then you can expect a lot of (what can feel like very annoying) questions about all the work and thinking done to date. You’ll have to do a lot of repeating of stuff you picked up along the way. And even with that effort, you’re likely to miss things and that will lead to lower quality analysis outputs.

It is far easier to bring your BA in at the right time so that you can save yourself regurgitating old decisions and conversations.

A recent PO I had was really great at bringing me in early. They took me along – just in case – to any meeting that had even a whiff of business analysis work in it. As a result, they got my meeting notes and honest reflections, and I found out about things as they were happening. And if there was an action or something to dig into, then they didn’t have to take time to brief me on the context afterwards as I already had the background.

Post-meeting, all we needed was to confirm actions and I could get going! 🏃‍♀️

Win win. All because I was brought in at the right time.

You’ll find that people who haven’t worked with a lot of BAs tend to mistakenly categorise BAs into the “delivery” side of the “resource register”. As a result, they assume that the correct thing to do is to commission the BA to deliver a specific solution or artefact. You know, just as you would do with most other roles on the delivery team.

It might seem counterintuitive, but if you are feeding your BA a steady diet of solutions, you’ll actually find it harder to get things done.

Why? Because we are problem solvers. When given a problem, or if we find one, most BAs will pick it up excitedly and try to fix it. We love a good problem!

Except, we might love problems a little too much. And in the absence of a good problem that we’ve been directed to solve, we have magic powers to uncover entirely new ones.

Imagine a situation where you, the manager, are absolutely sure that you have the right solution, and you’re proudly presenting it to your team for delivery! You might not get the enthusiastic response you’re expecting from your BA.

You are more likely to get: Have you considered X, Y, and Z? What about the impacts on A, B, and C? And should we just check under this rock over here for some other issues we need to address?

Because even if you offer a solution, the business analyst will analyse. Except in this scenario they won’t usually default to analysing the solution, instead they’ll want to understand the problem and solve that and more often than not, they’ll just re-litigate decisions that have already been made.

It is as frustrating for the manager as it is for the business analyst.

To have a thriving BA on your team, don’t supply them with solutions, supply them with problems.

They will thank you for it.

PS: There are of course times when a solution has been selected and the ask is simply delivery. In that case, do still involve a BA (they’ll help smash out the specified solution) but make sure they understand the constraints. And avoid making it a regular thing.

A business analyst runs on information. And while some information is sourced from documents and systems, most of the information we need we source from people.

Great business analysts are master networkers, but even master networkers need to get in the door.

And you can help!

Ensure your business analyst is introduced to the right people, and understands any politics or dynamics that are in play.

This could be as simple as an intro email to key stakeholders at the start of a project. Or as nuanced as deploying your business analyst to support a difficult stakeholder who has a problem before your project begins to impact the stakeholder’s area (thus earning brownie points 🍪).

We often need to have time with stakeholders. And most (all?) of our stakeholders are busy. You can help us get the information we need to progress your project faster if you ensure that people know what we’re working on, or even better, why we’re working on it. Connecting the dots for us sets us up for success when we are in investigation mode!

If we’re unplugged, we’re likely to get sub-par information from the wrong place, and experience delays in information gathering.

Without help from leadership building a network will take longer than it should.

I had a really awesome example of this this very week! 💗 My boss’s boss sent an email out to key stakeholders asking for their support on a piece of analysis work that we’re undertaking. The email explained what we were doing, why we were doing it, and what the ask of them would be.

This means that the next week when I booked blocks of time in people’s calendars, no one was surprised, and so far all our meetings have been accepted.

Without that level of support from above, we probably would have got lots of questions and far less support from the stakeholders involved. 🙌

It was a masterclass in plugging our little team into the network.

I have no idea what the network looks like at your organisation – it could be formal, informal, cliquey, or friendly – but I can guarantee there is one. Supporting your business analyst to leverage it will make their work so much more effective, as well as your own!

Your business analyst is an expert. We might not deliver code, or have a computer science degree, or even use fancy tools. (We are probably the only member of your team that thinks Excel is an underrated tool.)

Even quality assurance work feels more mysterious to managers and business folk than business analysis.

And in all fairness, much of what we do falls into the “I could do that, I just don’t want to” category.

The result? The true value of business analysis expertise is often overlooked.

But make no mistake, we are experts.

You wouldn’t tell your architect how to design a system or a data exchange. Neither would you tell your designer what tools they should use. So don’t tell your BA how to do business analysis.

Get out of the way and let them do their job!

Nuff said.

The best kept secret about business analysts is that they are force-multipliers.

Deployed correctly, they speed up your developer, smooth the way for your tester, and help your designer get the info they need. Best, they help you make good decisions.

But the magnitude of their force-multiplicity is directly correlated with the degree of trust between them, and whoever they’re working with.

📈 High trust = high force-multiplication.
📉 Low trust = low force-multiplication.

So, let’s say that you’ve nailed the previous 4 things: you’ve brought your BA in at the right time, you’ve given them problems, you’ve plugged them into the network, and then you’ve got out of the way. You still might not be getting the best from your business analyst!

Because at heart, the business analyst role is an advisory role. And for an advisor to be effective, trust is essential.

But let’s say that trust is lacking. That means that you are going to have to check the accuracy of your business analyst’s report (work for you). You’re also going to have to do all that stakeholder management because you can’t delegate it (more work for you). And since only you can be the person who interfaces with the higher ups, you’re going to have to really understand the details of the solution (even more work for you).

The counterfactual is clearly better. You trust the report but think it is too light in a section, so you throw it back with some instructions. You know you’ll get it back with the changes you want tomorrow (easy!).

A quick chat with your BA and you understand which stakeholders they plan to invite to that meeting. You tell them to hold off sending invitations until tomorrow so that you can touch base with their manager. Best she gets a heads up so it goes smoothy (a brief call with the manager and it’s off your plate again). And that big meeting? You take your BA with you and you know they’ll have your back if the questions get too detailed. Hell, they make you look even more important and managerial! (Win win!).

It’s not complicated. You need to be able to trust them so they can help you to move fast.

Trust unlocks other value as well – such as the much-overlooked bouncing board bonus!

Want to chat about your idea to re-platform an internal system? HERE FOR THAT. Need to dissect some exec politics? I’LL BOOK A ROOM. Thinking of outsourcing a service? LET’S CHAT IT THROUGH! Considering taking up knitting? LET ME GET MY CUP OF TEA!!

Business analysts are advisors. Somewhat unsurprisingly, they like opportunities to advise!

So beyond simply commissioning work from your BA, invest in building a trusting relationship. You can only benefit. In every single one of my most productive professional relationships, the common thread has been very high trust. I knew that they had my back and would support me, and they knew that I wasn’t gunning for their job. It is amazing what you can get done if you have a buddy.

And a business analyst is the best, nerdiest, most enthusiastic buddy you can have. 👯

For fun, I don’t want to end on too friendly a note!

Instead, I want to leave you with a warning.

I said at the start of this article, not enabling BAs to be their best selves can cause damage. Let me elaborate …

Managers, especially those who don’t understand the BA role, think that the BA is just “one of the team”. But the role is a lot more nuanced than that. Yes, we are part of the team. But it is more accurate to say that we serve the team.

And therein lies the danger.

A dev who isn’t enabled will just write less code and complete fewer tickets. The same is true for a tester.

A business analyst who isn’t enabled will get less done, but may also prevent the dev from getting work done, and possibly the tester too. We might even end up needing extra amounts of time with stakeholders, keeping them from their own work.

We are an optimiser.

Or a potential blocker, if given the wrong environment.

And you can choose which.

So choose wisely.