If you look for the definition of a Business Analyst, you’ll come away with lots of words in your head. If you come away with a clear understanding of what a BA does, you’re far cleverer than I am – reading some of these definitions left (the non-BA) me none the wiser. The established authority in this field, the IIBA, describes the role as “a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals.”
It’s ironic that for a profession that is supposed to be the beacon for clear and concise communication finds it so hard to explain in simple language what it does. And let’s face it, I’m not going to tread where loads of experts have gone before. Let’s face it, once you have a few years under your belt, you’ll not only understand these definitions, you’ll probably think they’re pretty good.
But what I could do is lay out what I do as a BA and that could be a starting point if the context makes sense to you.
I’ve only ever worked as a BA in companies that develop and implement software. I can tell you what I did as a typical BA in a development or implementation team does in these companies. However, not all companies are the same, not all teams do the same things, and no two BAs work exactly alike – so you’ll need to find your own flavour of BA for your own special set of circumstances.
What I do as a BA
If you’re reading about BA stuff, you’ve probably encountered the ‘five Ws‘ and ‘five whys‘ already. If you’re doing BA type work in any capacity, you’ll know that people always tell you WHAT first, not WHY – even though the latter is what you actually need to know first. So lets do the BA thing and start with the WHY, not the WHAT or HOW.
Why: My team needs to build the right thing, so that we can maximize our value to our business, and minimize the work not done.
The company that you work for has a product or solution that needs to satisfy a business need of current and future customers. Your team is employed to build or implement something that increases the business value of the product or solution, usually within a set of time constraints. According to the iron triangle, you have budgeted resources (your team), you have a schedule (the next release date, or project completion date), and you have the scope of the work for the project.
Because your budget and schedule are (generally) inflexible, the only variable is scope. It is absolutely essential to the success of the product or project that this scope is well managed.
– If you try to do too much with the allocated time and resources, you won’t finish in time.
– If you don’t do enough to satisfy the business value of the product, or the business needs of customers, your work is wasted.
Which brings us to:
What: The BA needs to find that delicate balance between what will satisfy the business needs of the customers whilst being careful to ensure that time or budget isn’t wasted building ‘extras’ that aren’t essential to the success of the product.
It’s that easy. Sounds simple, doesn’t it? It actually is. You’ll just need to figure out exactly what you are building… and why.