Wikipedia defines the role as ‘someone who analyzes an organization (real or hypothetical) and designs its processes and systems, assessing the business model and its integration with technology’. If I were a student and had seen this at a career fair, I would have continued walking to find something more challenging and interesting.
The truth is however, in my experience as a ‘business analyst’ with Orckestra, I’m continuously challenged, engaged and exposed to new and interesting domains centering on ecommerce and the need for omnichannel commerce solutions. To be fair, every organization has their own take on roles and responsibilities of a business analyst (BA) but here’s a glimpse of what I do on any given day.
- Eliciting requirements: This one is somewhat obvious. As a BA, I would meet with ‘customers’ to understand their current ecommerce processes and pain-points and their desired processes and objectives/expectations. From this high-level view, we’d be able to begin conceptualizing solutions by breaking it down into one or more features needed to meet the desired business objectives.
- Analysis: For each of the proposed features, now’s the time to do more of a deep-dive and challenge them. What does it mean to ‘challenge’ a feature? Take this example from Chris Coyier and his article Features Are Complicated. It’s a great case of how a seemingly simple feature of being able to edit a posted tweet can prove to be much more complex than originally assumed. The analysis phase will also likely involve doing research to better understand the subject matter and in cases the competition. This can help shape a solution by understanding how others may have tackled and addressed similar problems.
- Negotiation: Paralysis by analysis. At some point, you need to define a scope for the solution if not, it is way too easy to over-analyze and lose sight of the problem at hand which will ultimately bring very little value to the table. However, how do you decide what gets addressed and what does not? This is where you need to brush up on your negotiation and communication skills to make sure that all parties involved are clear on what is to be delivered, all the while ensuring that it meets the business objectives of the customer.
- Documentation: Regardless of methodology, a BA will have to get their solutions down onto paper. Feature requirements need to be documented and modeled in such a way that the person implementing the solution has enough information to proceed. Notice I said enough information… It’s naïve to think that all edge cases will be addressed ahead of time.
- UI and UX Design: When developing a solution which will have a user-interface (UI), it’s important to take the time to properly plan and optimize the user-experience (UX). You may think that your solution is the greatest ever that addresses the business needs but if it’s a nightmare to use for the end-user then what’s the point? A BA will work very closely with a design team to ensure that neither functionality nor ease-of-use will suffer with the UI.
- ‘Go-to’ Person: Once the development of the solution is underway, you become the go-to person for any and all clarifications and issues which may surface during the implementation phases. In most cases, these should be details which will be answered on the spot but every once in a while you’ll encounter a road block which will require big questions to be answered and decisions to be made. Once again, negotiation and communication skills are paramount to be able to quickly assess and broadcast issues to the right people. You are then the middle-man to facilitate all the necessary dialog needed to solve the problem and ensure that business, delivery and budgetary objectives are all aligned and met.
- QA: Once the development of the solution is ‘done’, it will go through your quality assurance (QA) team which includes your final stamp of approval. Whereas your QA team is looking to ‘break’ the solution you need to make sure that what is being delivered meets the customer’s ultimate objectives and in an acceptable manner.
- Customer Management: Regardless of whether you’re working on a client-facing services team or on an internal product development team, you always have a customer. Throughout the lifecycle of a project, you will be in communication with your ‘customer’ and surprise-surprise, negotiation and communication skills are key to be able to manage their expectations and keep them happy from start to finish.
- Training: At one point or another in a project, you will be called upon to train someone on the final solution since the BA is the one most exposed to root problems being addressed and the finer details of the solution.
- Demos: As an extension of providing training on a solution, who better to present a solution to an audience and clearly demonstrate how it will solve specific problems? Time to put on the sales hat and get people excited about the solution and the possibilities it brings.
- Product Management: Once a solution has been delivered to a customer, this should be considered as the start of future opportunities rather than the end of a project. Follow-up with customers to gather feedback on the solution you delivered. Is it addressing the problem you set out to solve? What do you like? What don’t you like? How can it be improved? Throughout the analysis process a BA makes many decisions and assumptions based on how they believe the end-user will be interacting with the final solution. Sometimes it’s better to under-engineer a solution and rely on actual customer feedback to improve it than to over-analyze and try to address all possible edge cases without proving it in the first place. This experience will only help make better decisions in future projects.
- Methodology: Regardless of the organization, every team and every BA within that team will have their own way of doing things. It’s important to take a step back and collaborate with the rest of your team to improve and optimize your organization’s methodologies.
This is by no means an exhaustive list nor will it apply to all BA's, however it does go to show that there’s more to the profession and role than meets the eye.
Shammeera.
