As I sat in a meeting the other day struggling to understand a topic that the two other subject matter experts seemingly understood quite well, I began to question my purpose at work which often sends me into an existential (yes I tend to overuse that word) tailspin about my overall purpose in life and what I contribute to society as a whole. I’ll save the latter topic for another blog post, and focus on the work question here.

So the two guys that understood the topic rattled on about it til they agreed on what finally needed to be done. My involvement was to document what needed to be done, track it, and then remind people over and over again about it to ensure it actually got done.

Now the term “business analyst” is of course overloaded to mean different things in different fields. In some disciplines, it means a person who is sitting there crunching numbers or running analytics. However, in the world of Corporate Tech, it refers to the person who works with the stakeholders to gather the business requirements and translate them into specifications that can then be used by system developers so they know what to build. You just need to have good writing skills, an ability to play nicely with others, and a functioning brain. Think Office Space and the “I have people skills!” scene.

Now this all made sense in the old school world of waterfall development where you had a massive project with several needs and a long timeline. However, when dealing with simple requests spanning only one stakeholder group and one tech team, does there need to be a middle person awkwardly inserting themselves into the process, playing broken telephone? The other day, a colleague had the nerve to say “it would help if you came to the meeting to take notes, if nothing else”. What a way for me to feel like a winner. On a side note, I did for once have the guts to give him a piece of my mind.

Now let’s think about this logically for a minute: if I, the business analyst, am not involved in the day to day work that spawned the request in the first place and am not the one that intimately knows the application/system where the change needs to be made, what is my purpose here?

The advent of agile development further begs this question. Here, the focus is on delivering a minimum viable product in short sprints and quickly soliciting user feedback so there’s really no need for long drawn out requirement documents, sign-offs, and pretty little mockups and flow diagrams.

Perhaps Corporate Tech needs to evaluate what this role really brings to the table and start over by asking what the true need is. Is there really a need to bridge the gap for every singular request? Can’t the stakeholder and developer just speak to each other, especially if it’s just two people? Why yes, they probably can. There’s no need to pay someone a six figure plus salary to set up mtgs and take notes; it’s wasteful and demeaning.

The real need is someone with the pitbullness and authority bestowed upon them to get the larger, more complex stuff done. That role can be the business analyst, product manager, project manager, and quality assurance tester rolled into one. Senior management, save your money, merge these roles together, keep fewer of us around and pay us something closer to what you’d pay the superstar sales people or engineers, you might actually get more out of us and your money’s worth.