Too many questions? Spotting problems early? Five real complaints about IT project Business Analysts, and why each one proves you need one.
Business Analyst … busy-body more like it!
Business Analysts have an image problem.
As a BA I hear lots of praise. Of course I do – BAs are brilliant!
I also hear the occasional grumble.
Here, read five actual complaints I’ve heard about the work I do. I emphasise “heard” because they’re always overheard – never said to your face.
The funny thing is – they don’t half amplify the value of a BA!
So, for fun, here are five reasons (based on real feedback) why you definitely don’t want a Business Analyst on your next project.
1 – We ask far too many questions.
I overheard a project team member say this on the phone through a toilet cubicle wall!! He didn’t know I was on the other side!
Indeed! The ambiguous “build me a thing” is much more fun than a BA insisting on finding out which thing, for whom, why, and what success actually looks like. I mean, how needlessly thorough.
A far better approach is to let a vague brief drift through three departments, get reinterpreted twice, and land on a developer’s desk as “something like what marketing wanted, probably.” Sure, you’ll end up building the wrong thing efficiently. But at least nobody had to sit through a requirements workshop.
2 – We have an irritating habit of spotting problems early.
I learned this about myself via an accidental reply-to-all email after I poked my nose in where it wasn’t wanted. A week later I flagged inefficiencies that could have been seriously damaging to the project if left unchecked..
Nothing kills the fun of a production incident quite like someone identifying it back in week two, during a stakeholder conversation, using a word like “dependency.” Where’s the drama in that?
A properly unmanaged project saves its biggest problems for launch day, ideally the day the client’s Ops Director is presenting it to their board. That’s when you find out the “simple integration” was never actually possible.
Character-building for everyone involved, right?
3 – They keep getting everyone in the same room.
A colleague shared this gripe at the water boiler as we made a brew ahead of “another bl**&! meeting” – forgetting it was me who called it!
Developers, users, stakeholders, subject matter experts, all talking to each other, comparing notes, checking assumptions.
How irritating!! What a waste of time!!
Aside from how well that works, of course.
Much better to let each group build their own private version of the project in their heads.
The sales team believes it does one thing.
The developers are building another.
The end users, when they eventually see it, will have opinions about both.
Nothing brings a team together quite like everyone finding out, at the same meeting, that they’ve been building three different projects.
4 – They turn vague ideas into something people can actually understand.
Requirements, processes, journeys, diagrams, acceptance criteria: give a BA a brilliant, hand-wavy idea and within days it’s been reduced to something specific enough that people could actually build it.
How deeply unsporting!
Vague ideas are more fun. They let everyone imagine the best possible version of the project, right up until it’s delivered and turns out to be the average of everyone’s guesswork.
I’m afraid that a BA ruins that suspense by writing down, in advance, what “done” is meant to look like.
Where’s the mystery in a shared understanding?
I’ve heard variations on this theme over the years – basically the complaint here is:
“you’re making me think when I just want to crack on and do – regardless of whether what I do is right or wrong”
5 – They’re constantly challenging “the way we’ve always done it.”
This is a regular pushback! To give you some perspective, to me, often an inefficient process is as obviously wrong as watching a gardener mow a lawn with a pair of nail scissors. You just know there’s a better way.
BUT, surely just because a process has been quietly inefficient for ten years doesn’t mean it needs improving. I mean … Who do I think I am!? It’s tradition, baked into your culture, at this point.
The latest that I challenged was a workaround for a workaround someone had built back in 2016. Nobody had touched it since, presumably out of respect for its redundant complexity!
Who was I?
Wandering in and asking why the approval step exists, who it’s actually for, and whether the three separate spreadsheets talking to each other via someone’s memory is really the optimal system. How deeply disrespectful to a process that has survived for a decade.
The cost of skipping the awkward questions
You can see why I said each moan illustrates the value of a BA. What tends to happen on projects that don’t have one is:
- Requirements get interpreted rather than confirmed.
- Problems surface at the worst possible moment instead of the cheapest one.
- Stakeholders discover, late and simultaneously, that they wanted different things.
- Ideas stay exciting and vague right up until they become a delivery date, at which point someone has to work out what “it” was actually supposed to be.
- And processes that nobody likes but everyone’s used to carry on exactly as they are, because nobody with the standing to ask “why” ever did.
Individually, each of those is survivable.
A misread requirement here, a late-surfacing risk there, projects have always absorbed a certain amount of that kind of friction as a matter of course.
The thing is, you’re probably like me. My projects no longer have the budgetary “wriggle room” to absorb much friction.
Rework is a luxury we just can’t afford!
Also, these avoidable issues have a habit of compounding. #
That vague brief plus an unclear success measure plus a stakeholder group that never quite aligned tends to produce exactly the kind of project that limps to the finish line:
Over budget.
Three months late.
Doing something close to but not quite what anyone actually wanted.
A good BA’s job is to catch that friction nice and early, while it’s still cheap to fix, rather than later, when it’s expensive (and in public).
That can ruffle a few feathers.
I often have to tell project teams and sponsors things they do not want to hear but we’re not there to slow a project down with process for process’s sake.
We’re there to ask the questions in week two instead of week twenty, ensure the room (physical or virtual) has the right people in it before decisions are made, and make sure “done” means the same thing to the development and delivery teams and the client signing the cheque.
Of course, ff you like misunderstood requirements, duplicated work, unwelcome surprises, and meetings where everyone leaves with a different idea of what just got agreed, crack on.
You probably don’t need a BA.
Everyone else, probably does.
