Business Analyst – The Team’s Interpreter

Business Analyst – The Team’s Interpreter

Written by Cheryl Murray, Business Analyst for Solü Technology Partners.

I have become adept at explaining what a business analyst does. That’s because whenever I tell somebody that’s what I do, they inevitably ask, “And that is…. what exactly?” Sometimes I give a full explanation, sometimes it’s a variation on “it’s my job to think” …and once in a great while when I’m feeling feisty, I might say, “I analyze businesses, of course.”

The reality, of course, is that what an analyst does depends on several factors. It depends on the needs of the project and the team, on the norms of the company, and it depends on the expertise of the analyst.

Throughout my BA career, I have provided a wide array of analyst services, from traditional ‘requirements gathering and analysis’ to more non-traditional data analysis and validation. I have facilitated meetings, maintained and prioritized work backlogs, and I’ve functioned as the primary point of contact between business stakeholders and the development team. I have even dabbled in writing training modules when my team needed to learn an unfamiliar business.

While those tasks might seem unrelated to each other, there is a common thread that weaves through the tapestry of business analysis: interpretation. The process of helping people understand both the problem and potential solutions is at the core of business analysis and it’s one of the primary responsibilities of an analyst. We find ways to help our colleagues understand complicated concepts.

When I talk about “complicated concepts”, my listeners usually assume that I’m referring to the process of explaining tech-speak to business stakeholders. And that is certainly a component of my job as interpreter. But it’s a two-way street. Tech teams sometimes need business-speak explained to them, too.

One of my teams once worked on a project for an investment banking client. If you ever want to amuse yourself, say the phrases “collateralized mortgage obligation” and “mezzanine tranche” in the same sentence. You can make an entire room of developers and testers glaze over and start drooling. It’s like magic.

In truth, a development team needs to understand at least enough of the business to grasp why their work is needed. The business stakeholders need to understand at least enough of the technology to have reasonable expectations for work progress and deliverables. That’s where the analyst comes in.

We live at the intersection of business and technology. It’s a busy place. There is a perpetual need to learn things so we can teach them to somebody else. At any moment, I need to be equally prepared to explain what a REST service endpoint is as I am to detail the difference between the index and margin in an adjustable-rate mortgage. Analysts gather and study information, then we interpret and explain what we found – to whoever needs to hear it.

I know my team, I know my project, and I know my stakeholders, thus I’m uniquely positioned to fill any role necessary to ensure the team’s success. I often assist the product owner in refining business requirements. I help the scrum master apply agile principles and processes to make a more effective team. And I do all that while performing requirements analysis. I am, in short, whatever my team needs me to be. And no matter what, I’m the team’s interpreter.

Want to know more about our Business Analyst opportunities? Whether you are looking to implement a BA on your team, or you are seeking a new career opportunity as a BA, we are here to help! Get in touch!