Image by Intersection Consulting, CCBY2.0

I am a Business Analyst.
I know, I know.
We suck.

Business Analysis is all about useless documentation and templates, right? BAs are sticklers for detail and overloading process onto projects. And did I mention all. the. documents? I mean, who has time to read those? Projects could be so much more agile if we just skipped having a BA on the project. Amiright?

Let’s face it: BAs get a lot of flack for being inflexible document masters and scope mistresses. But we don’t have to be. Nor should we be.

I think BAs get a bad rap because it’s really easy to be a bad BA.

Thankfully, it’s also just as easy to be a good BA.

But, how do you know if you’re a bad BA? Here are some potential signs that you’ve got bad BA habits:

You document everything formally

“Here’s a list of documents we’ll be producing for the project. Why? Well, because that’s what you do on these types of projects.” SMH. Yes, it’s important to capture scope clearly and get client sign-off to manage timelines and budget. But do you really need to formally document every single step along the way? Why are you putting so much emphasis on tomes that take so long to write? What’s the point of spending months on something no one will read?

Ask yourself: Who asked for it? What will they do with it? What kind of information do they need to take the next step? What’s the best way to capture that and move on? Because the best kind of documentation is the kind that gets read and used. Sometimes low-fi is the right deliverable. Sometimes photos of the whiteboard session is as much as you need to get acceptance on direction. Forget about what type of documentation you are supposed to produce for this kind of project. Figure out the best kind of documentation your team actually needs.

You take what the client says at face value

“We need a (tool) do (outcome).”
Really? Do they? Why that tool for that outcome? Can that tool even get them that outcome?

You’re an analysis expert. Your job is to listen, evaluate the situation, discover the true need and determine the best solution to generate the outcome they want. Provide advice. Sometimes the client is constrained to a specific tool and there is no leeway to provide advice that counters their direction, but it’s still your job to do the analysis and at least flag the risks of not exploring or maximizing the tool-outcome fit. Otherwise, you’re just a document mule and really, is that why you do this work in the first place?

You forget that your client is an expert in their own right

That said, yes, you’re the expert and they brought you in for your expertise. But they are also an expert — in their line of business — and while they might not understand your process, they shouldn’t have to in order to work with you.

Stop explaining your methodology to them. Stop getting frustrated because they don’t understand how it works. You are there to understand their business, their motivations, their mandate and purpose, how they work and what they do. That’s your job. And if you walk in there like some hot-headed saviour, you’re going to put them on guard really quickly. Use your expertise to explore their expertise.

You make them fill out your templates

A good BA talks to you, discovers your needs and figures out your requirements.
A bad BA makes you fill out their template.

Do the work: have conversations, meet people, job shadow, elicit requirements, run workshops, do user interviews… gather the data and document it yourself. Don’t download the work to your clients.

You put process over client experience

Sure, there’s a formal methodology to business analysis. In fact, there’s an entire user manual. But that doesn’t mean you need to follow every single step each and every time you take on a project.

Industry practices and methodologies are your reference guide: figure out what works given your client, the project, the team, the timelines, the budget, and only do what’s necessary. Are you trying to shoehorn your project into a framework you know and understand? Or are you adapting your methodologies to suit the needs of the project and team? Process for the sake of process helps no one. And it makes you awfully un-fun to work with.

You hold your client at arms length

Stop working in a vacuum. Don’t put your results in front of your clients and ask them if they agree or if anything is missing. Stop presenting foregone conclusions.

The only way to validate your results is to present people with the raw data and see if they come to the same results. Seriously. Run a session where they work with the data (e.g. card sorting, journey mapping, etc.) and see what conclusions they come to on their own. Then compare and contrast with your own to identify gaps and commonalities. Then discuss those — the gaps and commonalities — with the client to prioritize. Stop putting stuff up for reaction. Your client deserves better. They deserve to contribute.

You forget that Business Analysis is a design process

Your job is more than just documentation. It’s designing and facilitating interactions between people in order to reach the goals of the project.

Being a BA is about design: you design interactions between people, you design the deliverables to suit the project and team, and you design how you work in between. We’ve got a lot of great tools in our toolkit, but what makes a good BA isn’t the ability to apply them, it’s the ability to customize them — even redesign them — as needed to suit the project. From workshops to facilitated discussions to working sessions, you should be spending a significant amount of time thinking about and designing how the work will get done, not just working toward outputs.

Breaking bad BA habits

Bad BA habits ruin projects. They lead to excessive, unnecessary work and documents that the tech team don’t use. (“Did I use the latest functional spec? No, I designed using the wireframe you showed the client last month.”) They put process before people.

At the core of the business analysis practice is flexibility. Which is ironic, since we are so often perceived as inflexible.

Good BA habits include designing the project itself, not just generating documents. We need to spend the time analysing the project, the clients and the team to determine what work needs to be done in the first place, then designing interactions to facilitate that work.

It’s easy to be a bad BA. But, thankfully, it’s just as easy to be a good one.