Be(com)ing a mediocre BA: your guide to glorious ineptitude.
So you want to be a Business Analyst (BA)? Great! It’s a role that bridges the gap between the business world and the technical side of things. Are you okay with being the misunderstood hero, the valiant translator of grunts to glorious user stories? Do you understand what it takes to be a mediator, to look your CEO in the eye and say NO to their request?
It sounds like a daunting task, yeah?
But fear not, aspiring superstar, for there is an easier path, the path to becoming a truly terrible BA which does not require you to be this stressed but yet, is far more rewarding, as you will soon see!
Here’s your handbook to achieving spectacular mediocrity.
Never try to understand the why!
Out of all the things you can choose to understand, why why? The project has a vision, and so what? Why should you be bothered about that when there are so many other things you can be mediocre at.
The whys or vision for any project is for top-level management and should end in their top-level meetings, that is not why we are here!
True Stakeholders come around eventually.
Another great tip to edge closer to glorious ineptitude as a BA is to go around sourcing for stakeholders like you were shopping for groceries. They say it’s Stakeholder mapping. Come off it bro, you don’t need all that, true stakeholders that are meant to be on the project will find their way to you and if they don’t, they are never meant to be Stakeholders anyway.
The end user will be fine, who cares if he is frustrated, or we overengineer our features, all we care about as mediocre BAs is that there is a solution. Is it useful? None of your business!
Communication? Who Needs It?
When your Stakeholders finally come to you, you guys should be on a need-to-know basis, why communicate? Whose fault is it that they don’t know how to read minds or are technically challenged?
As a terrible BA, just work with the assumption that they already know what you want to say, so why waste everyone’s time on that meeting or shooting a mail, keep it going big man.
Those that are true stakeholders at heart will come around to understanding the project eventually. We have to separate real from fake.
Requirements? More Like Wishlists for Kids!
Forget about eliciting actual needs. Nobody is in need, that’s why they get paid. Why settle for the mundane when you can craft requirements that resemble a five-year-old’s Christmas list? Every feature must be included, regardless of practicality or budget. Does the user need a self-cleaning coffee mug warmer with built-in weather forecasting? Slam dunk! Remember, a good BA never questions, only amplifies the glorious chaos.
Documentation? Pfft, Who Reads That Stuff?
Who needs pesky things like flowcharts, user stories, or even the occasional BRD? True BAs rely on the power of telepathy. After all, meticulously documenting requirements is for control freaks and micromanagers.
Let the developers be delightfully surprised by the ever-evolving feature set!
Embrace the Art of the Disappearing Act!
Once requirements are “delivered” (read: vaguely mentioned in a hallway conversation), vanish like a magician! Emails requesting clarification? Ignored! Urgent meetings? “Sorry, double-booked with a football match!” Remember, a good BA cultivates an air of mystique.
Let the developers chase you down, begging for the wisdom you oh-so-casually withhold.
Become the Master of the Passive-Aggressive Sticky Note
Passive aggression is a BA’s secret weapon. Leave cryptic messages on developers’ desks like, “Just a friendly reminder that clarity is key ;)”. Master the art of the backhanded compliment: “Wow, that code is…interesting. Did you consider the unicorn integration?”
Remember, a good BA keeps developers perpetually on edge, never quite sure what masterpiece of misunderstanding awaits them.
Meetings? More Like Nap-Time Sessions!
Meetings are sacred. They are your opportunity to showcase your impressive ability to multitask. While someone drones on about user stories, catch up on the latest celebrity gossip or perfect your online poker skills. Remember, a good BA prioritizes personal productivity over things like project progress.
Meetings are a drag, gatherings of the feeble minds! So why not skip most of the details? Briefly touch on what the business needs, but leave plenty of room for interpretation. Think of it like a game of telephone — the more confusing the message gets by the time it reaches the developers, the better! Emails are okay, but keep them vague. After all, a little mystery never hurts anyone (except maybe the project deadline) and clear communication is the enemy of glorious ambiguity!
Never Admit You Don’t Know Something!
Feigning omniscience is a core BA skill. When a developer asks a clarifying question, respond with a vague generality or a historical anecdote about carrier pigeons. Remember, a good BA never reveals the cracks in their knowledge façade. Let the developers spend hours deciphering your riddles!
Don’t fix what is not broken.
Why are you sweating over improving a process that works just fine? What’s this fuss over improvement? Is it working, yes! Is it functional, big yes.
So why are you trying to do any more work on it. As a BA, your time at work is to be reading articles like this that gives you more insights on how to be mediocre. Not duplicating efforts in the name of process improvement or optimization.
Lastly, Change is constant.
I have told you before, and I’ll say it again, you do not need to get worked up over what the change management process will be like. If some way, somehow, you have managed to deploy your solution (the mediocre is silent), then no need to push for adoption.
The only constant thing is change, the users will change from their old ways and repent to using your new solution. It is God’s will that all man comes to repentance and to the knowledge of your solution, so don’t sweat it at all.
And like I said for stakeholders, it holds same for your end users, your true users will gravitate naturally towards your solution.
There are many more ways to achieve your lifelong dream of being mediocre, but by following these few simple guidelines, you’ll be well on your way to a destination of glorious ineptitude.
Remember, your goal is not to bridge the gap between business and development but to create a chasm so vast, that communication becomes an Olympic sport.
Embrace the chaos, revel in the ambiguity, and leave a trail of bewildered developers in your wake! Just don’t be surprised when your project goes over budget, over schedule, and ultimately resembles a flaming dumpster fire.
After all, isn’t that the true mark of a mediocre BA?
