I recently passed a milestone in the journey of my career. I’ve now spent over two years as a formal “Business Analyst” or “BA” here at Catalyst IT. In actuality, I’ve been a BA for a lot longer than that. Running my own business for 20 years meant I was performing the tasks of business analysis with every client, on every project. I just didn’t have a name for it back then.
So what is Business Analysis? And what do Business Analysts do? I am so glad you asked.
Let’s start with some definitions.
“Business analysis is the discipline of recognizing business needs and finding solutions to various business problems. In simpler words, it is a set of tasks and techniques which work as a connection between stakeholders.” – Pestle Analysis
“When a business needs to solve a current or future problem it’s a business analyst’s job to help facilitate a solution.” – Elabor8
“The Business Analyst is an agent of change.” – International Institute of Business Analysis
Some of the tasks BA’s undertake when working to develop or validate new requirements include:
- Workshop facilitation,
- Stakeholder interviews,
- Business process modelling,
- Wireframing,
- Data modelling,
- Evaluating available solutions.
Tasks need tools, and as luck would have it, one of the tasks a Business Analyst like me might find herself doing every now and again, is drawing diagrams to illustrate processes and relationships. I often turn to one of my favourite tools, Inkscape. I have re-created the Core Concept Model from the International Institute of Business Analysis (IIBA) with Inkscape, with a slight change to the order of the concepts.
The IIBA developed a Core Concept Model for Business Analysts to use to frame the work they do. The model outlines these six interrelated concepts:
- Context,
- Stakeholders,
- Need,
- Solution,
- Value, and
- Change.
I think of it like this: In any given context, stakeholders have needs requiring solutions that deliver value which may require a change.
Each concept relates to all the others. Uncovering and understanding the relationships between all six is what makes this model so powerful. The process of exploring each of these relationships helps us develop better questions in order to reveal underlying requirements.
Why? This is my favourite question; not to be impertinent, but to get to the deeper reason behind any given request. ‘The 5 Whys’ is a quick and useful method to get beneath the surface of any request or requirement. The IIBA Core Concept Model is a great framework for understanding the answers we hear when we keep asking ‘why’. Here’s an example of how the ‘5 Whys’ can help us uncover the real reason for a request.
In this case, we are in a hardware store. Ok, Why?
- To buy a drill,
- To make a hole,
- To connect a cable,
- To link to the internet,
- To resolve a bad wifi connection.
So, to come back to the IIBA Core Concepts, let’s tease out what this example might look like.
- Context: A private home with old, heavy brick walls, a fixed internet connection, and an old wifi router. Some family members are getting a good signal and hogging the bandwidth, exacerbating the poor experience for others. Some members of the family have concerns about whether the younger members should be using the internet in their rooms unsupervised.
- Stakeholders: All resident family members of this household.
- Need: Everyone wants to be able to access the internet anywhere in the house.
- Value: The bad wifi situation is causing disharmony. Solving this will be a huge relief for everyone. More importantly, it will let key members of the family finish their studies, do the household accounts, and let off steam playing games.
- Solution: Is drilling a hole the only solution? Now we can explore a range of options to find the best approach to the wifi issues this family is experiencing.
- Change: A concise description of what will actually happen to fix the problem, that specifies who will do what, and by when, with what resources.
To me, the words “Business Analysis” and “Business Analyst” don’t adequately convey the breadth and depth of the kind of work needed to elicit requirements. Sometimes project managers, delivery or iteration managers, and product owners also do this kind of work.
Business Analysis is part detective work, part therapy. It requires empathy and compassion. Observation, listening, and experimentation are BA tricks of the trade. In the worst kinds of projects, Business Analysts end up writing reports no-one reads. In the best projects, when Business Analysts get the time, resources, and authority they need to uncover real requirements, their teams are empowered to deliver real, useful, people-centered solutions. To me, that is what business analysis is all about.
