What does a business analyst do? (& The Skills to Do It)

In the business world, the ultimate goal for any organization is to deliver products that fulfill customer needs. But the difference between what we think customers need and the reality is often staggering, and decision makers can fall into a number of process traps or miscalculations about what to provide. That’s where the role of a business analysts come in handy.

In short, business analysts guide operations by collecting requirements from different project stakeholders, ensuring those requirements provide value to the end user, and communicating that information to all contributors.

I’ve been looking at the best overview for this job for some time now and compiled it below.

Briefly, what is business analysis?

To understand what business analysts do (software, digital, or other), we need to know what business analysis is. At a high level, business analysis is the breaking down of functions and processes within a business unit and improving them. But this may not look like what you think.

More specifically, business analysis is the collection of functional and non-functional requirements from stakeholders and the application of these requirements within the organization in order to improve or create a product or service.

Notably, business analysis includes communication. It’s the ability to understand and interpret requirements from people who may not understand what the end user really needs. And this is the first of two key exchanges. The second is being able to communicate those requirements to entire teams.

This may sound simple, but the business analyst role actually requires a high degree of people skills, comprehension skills, and technical understanding. Let’s look in more detail at the nuances of the role.

What does a business analyst do? (with example)

In many ways, business analysts occupy the role of facilitation. Business analysts spend a lot of time helping other parties identify what they want, refine it, and communicate this new information to the relevant stakeholders. Their work is different from a project manager or product owner because they (usually) don’t make decisions — they facilitate.

Example

For example, let’s imagine you’re a business analyst in an insurance company. The company would like to develop a new insurance line for commercial scuba diving companies (as a fun, fictional example).

Your work would consist first of requirement elicitation. As a business analyst, you would organize meetings with stakeholders, take notes on their perceived requirements, and start building a formal description of what the commercial scuba diving product might be.

Your next step would be to discuss these requirements with the relevant teams (other stakeholders). Let’s just take the sales team and risk management teams as examples. Sales says that the product is too expensive as positioned in the initial proposal. The risk management team says lowering the price would make it unsustainable, since there are hundreds of thousands of squid attacks every year (exaggerating for fun here!).

Now you have three stakeholders with unworkable requirements. You have your first business analyst conundrum. At this stage, you have two options. Either you report that the initial model will not work and propose an alternative, OR you look harder at where the problems lie within the current proposal.

You have now elicited and interpreted requirements.

Refine possibilities

Let’s say you see that if you only service low-squid attack areas, the product can be profitable and acceptable to everyone. This would be a solution. But you also want to be prepared in case the decision makers don’t like this choice. You therefore decide to have an alternative of proposing the same insurance, but on a recreational (non commercial) basis, which would keep the product profitable.

Once refined, you take this idea back to the sales and risk management teams, who both support the two alternatives. Then it’s time to take it to the decision makers, who decide narrowing the serviced areas is best (option 1). You’ve just provided constructive feedback and moved the project forward!

Now you need to inform the sales and risk management teams, as well as the communication and IT teams, who will integrate the offer through the company’s online portal. You collect functional and non functional requirements form these teams.

At this stage, you also need to ensure that customers actually want the product. So you organize several focus groups and send out questionnaires through a data collection partner. At this point you need to engage the data analysis team to understand the results from these vis qualitative analysis and other data analysis techniques.

Don’t forget, you can get Intro to Data Analysis for free.

You should then be able to establish if there exists a statistically significant chance that enough customers will buy the new product. In other words, you’ll know if the product solves the customer’s problem. If you see that it doesn’t, then it’s back to square one. You need to revisit the original idea and elicit requirements from decision makers. You repeat this process until the product goes to market!

Proposing improvements independently

In some cases, decision makers call upon business analysts to make their own, original suggestions for process improvement. This is why you often see “process improvement” as part of the business analyst job description. Speaking of job descriptions…

Business analyst job description

Using the example above, we can outline a job description. The 7 main parts of a business analyst job description are:

1. Requirement elicitation from all stakeholders
2. Requirements interpretation
3. Balancing internal and external priorities for project
4. Problem solving given the parameters provided by stakeholders and the market
5. Proposing alternatives to decision maker ideas
6. Working with data analysts to understand the market
7. Communicating decisions and innovating

These are high-level descriptors, but business analysts perform a host of more operational tasks as well. Many of these include:

• Writing reports
• Budgeting and forecasting
• Planning and monitoring
• Data analysis
• Pricing new products
• Define business requirements if requested
• Write technical documents to guide teams through development processes
• Logical analysis

As we can see, the business analyst’s job description focuses on a series of well known tasks. There’s a good amount of crossover between finance analyst and data analyst tasks. I believe the three are strongly related and should understand each other’s jobs well. That’s why I build this website for them. If you want to learn more just check out some other articles.

While many of the above are technical tasks, business analysts also spend a good amount of time in non-technical tasks. Ability to perform on these tasks is really what set the great business analysts apart from the pack:

• Communicating with different teams
• Understanding requirements
• Interpreting requirements
• (Good) question asking
• Managing confrontations
• Managing expectations
• Motivating teammates

In fact, I think it’s curious that business analyst professionals don’t put more emphasis on the we spend on these “non-technical” tasks, and how important they are to success. When we ask the question, what does a business analyst do, the best answer is that they facilitate interaction between other parties.

Business analyst responsibilities

A helpful addition to the job description is responsibilities. After all, regardless of what BAs do to reach their goals, they’re only responsible for the goals themselves. Typically, a business analyst’s responsibilities include:

• Delivering requirements documentation
• Delivering market research reports
• Lead change management efforts in meetings
• Delivering proposals or alternatives reports

These are the items a business analyst must provide to his/her superiors, which is why we call them responsibilities. They are not, however, most representative of what a BA does on a daily basis. Let’s take a closer look at some of the functions we’ve discussed so far.

What does a business analyst do day to day? (with examples)

Using the example and lists given above, a business analyst daily tasks would include the following:

1. speaking with stakeholders,
2. drafting documentation,
3. performing data analysis, and
4. budgeting.

We’re going to look at each of these with examples to give you a better idea what a business analyst does. It’s important to note, moreover, that each of these tasks depends inherently on the industry. That’s why we’ll need to look at how the job differs in different industries, the most notable of which or IT/software and banking.

Step 1: Speak to stakeholders

Speaking to stakeholders is a special task. A business analyst’s goal must always be threefold: obtain the needed information, provide helpful feedback, and project a positive image of his/her department to decision makers.

When you’re trying to extract information, the most useful tool is asking questions. You need to have a list of specific questions that will get you the information you need to fill any gaps in your knowledge. At the same time, these questions must not come off too strong, or you may find yourself off the project.

For example, when the decision makers said they want a commercial scuba diving insurance line, you may want more details. Perhaps you need to know if the vision is to service tiny scuba companies in small towns like Daytona Beach, FL, or to service major tourist companies with a minimum yearly profit in Southern California.

You could not simply ask “how much do they need to make to qualify?” You need to ask vision-oriented questions, like “what do you want people to say about this insurance plan in 1 year?”

On the other hand, you need much more targeted questions when speaking with sales and risk management. Their job is to be concerned with the details. You might say, “how much profit do companies need to make for this insurance line to be profitable?” In discussion with IT teams, you might ask “what is the going design principle for presenting a new line of business on a corporate website?”

In other words, business analysts spend a lot of time asking the right questions to stakeholders in order to elicit requirements.

Step 2: Draft requirements documentation

Between discussions you have with stakeholders, you will need to document requirements and associated project docs. While documentation is becoming less important over time–yielding to preferable face-to-face discussions–it will always remain a critical job for business analysts. Why? Because we will always need a paper trail of our thoughts. Without them, we cannot improve on past performance.

Business analysts use the following documents for requirements and associated information:

• Stakeholders outline – the stakeholder outline document can either be standalone or part of the stakeholder analysis document. It simply identifies stakeholder by name, their role in the project, and gets their sign off to recognize participation. It’s a kick off document.
• Stakeholder analysis – this document provides information about meetings with stakeholders and their understanding of the project, such as deliverables, goals, scope, deadlines. It’s a living document that will grow over the course of the project.
• Business analysis plan – this is the document that describes the steps the business analyst will take (requirement elicitation, data analysis of market, strategy reviews) in order to achieve the project goals. This document also informally recognizes in what ways the BA depends on other departments to succeed.
• Use case – The use case document may be standalone or incorporated into the business analysis plan. It provides an example of how a customer will learn about, explore, purchase, and speak about a the product or service. As with any example, use cases help provide clarity on the general idea behind the project.
• Current state analysis – current state analysis may be standalone or incorporated into the business analysis plan. It’s exactly what it sounds like: an analysis of the current state of a service, product, or in the case or internal changes, the current state of a process. This document is important because it serves as a benchmark for future progress.
• Scope specification – another document that can be standalone or incorporated into another, in this case either the business analysis plan or the stakeholder analysis doc. The purpose of this document is to identify the limits of the project. Indeed, it’s easy to get carried away while working in the details of a project. Scope specification helps keep the project narrow enough to be completed but general enough to encompass the maximum amount of value.
• Functional and non-functional requirement specification – the famous functional and non-functional requirements must be standalone and not part of another document. They’re simply too important and lengthy. In a sentence, functional requirements are the behaviors that a product must actually be able to do, whereas functional requirements are metrics goals it must reach. For example, a website functional requirement is having a checkout cart, whereas a non-functional requirement is that is must be able to sell to 100 people at any given moment.
• Prototype development – in many cases, business analysts must be able to create mockups or wireframes of the final product. These often take the form of documentation. This process gives BAs an upper hand of the project because they concoct the initial idea given all the information available to them from the stakeholders. This document is either standalone or part of another.
• Test plans and test cases – during the proof of concept phase, business analysts need to team up with data analysts to create ways to test ideas, collect data on it, and provide feedback. They outline test plans and perform test cases. Let’s look at this more closely below, as it requires more hard skills than any other document.

Step 3: Data analysis

In parallel to documentation, business analysts need to perform a host of qualitative and quantitative analyses. In most cases, data analysis in the business analyst role occurs for 1 of 2 reasons. Either

• Perform market analysis for testing a new product or service, OR
• Analyzing current functions in the company to improve processes

While complete details of these analyses would be outside the scope of this article, let’s look at some common analysis steps and techniques that business analysts use for data analysis.

In any data analysis process, you’ll need to collect, inspect, correct, and… analyze the data (sorry, couldn’t make the last one rhyme!):

1. Collect – most business analyst outsource data collection for market analysis since it requires a lot of specialized knowledge, but they may choose to source information internally for analyzing current functions.
2. Inspect – business analysts will consult collected data, making sure its normalized and ready for analysis
3. Correct – any inconsistencies or recognition problems with the data must be fixed
4. Analyze – run a number of visualizations and statistical analyses to understand your customers or processes. Typically, you’ll need to focus on qualitative research for market analysis and quantitative research for internal processes

For example, imagine we want to collect information about what some commercial scuba diving companies think of the new insurance line that we want to implement in our offering. For this, we outsource the study to a service provider and receive the data from them. This would be qualitative data including responses that individuals and the group gave to questions asked.

We would then need to inspect the data for problems, correct them, and perform our analysis. Typically, the analysis needed for a situation like this would be either a word frequency analysis or exploratory data analysis.

In a sentence, this means either searching directly for suspected words OR identifying recurring ideas and themes. It’s important to note, also, that all oral or video report must be translated to written format before any analysis is possible.

Step 4: Budgeting

For many departments, budgeting is a dreaded task. In my opinion, it’s one of the biggest perks of being a business analyst. Because project manager and product owners often dislike managing the budget, it falls on business analysts. Budget is power, and with the right Excel skills, you’ll be in a great position.

But what is budgeting? Budgeting is planned spending of an allotment of money. Typically, the treasury department will work with other members of the finance team to allot a fixed sum of cash towards developing new products/services or improving current operations. This is an example of budgeting at the highest level.

Business analysts then take the cost allotment and create cost estimates for their projects. This acts as another limitation when developing the product, since startup costs can in some cases be larger than budget. In any case, the business analyst must follow 4 steps when budgeting:

1. Collect the budget
2. Collect cost estimations for his/her project
3. Outline the budget in an Excel document
4. Make requests for supplementary budget where necessary

What does a business analyst do in IT/software company?

We’ve talked about what a business analyst does in general, with particular reference to the insurance industry, but how does this differ from what a BA does in an IT/software company?

In short, business analysts in IT companies have to be more technically knowledgeable than in other industries due to the subject. If s/he is not capable of working with developers to better understand the product, then you can forget about functional and non-functional requirements.

What does a business analyst do in a bank?

While we often throw banks and insurance companies into the same “old school” category, a business analyst’s tasks can vary widely between the two.

In short, a business analyst in a bank needs to have a good amount of financial knowledge. While a host of bank BAs work in implementing digital interfaces and solutions, they must be able to understand how commercial products work in order to implement any kind of change.

If you’re looking to get a job as a business analyst in a bank, make sure you brush up on your finance knowledge.

Business analyst skills

What a business analyst does necessitates a number of skills. As we’ve discussed, these tasks are both technical and people-based. This means the skills needed are both hard and soft. Here’s a list of some common skills that business analysts need to be successful:

Soft skills

• Communication – although communication is a hard skill to explain briefly, the takeaway here is that business analysts need to be able to explain complex ideas in a simple way and understand unclear explanations by asking good questions.
• Relationship building – beyond good communication, business analysts must be excellent at building informal rapport with colleagues so they have a steady flow of information from team to team. Without it, they can find themselves hard pressed to source valuable business information in a bind.
• Self-managing – business analysts need to be good self-managers. Because the business analyst role is largely one of facilitation, BA’s must be motivated to manage themselves.
• Resilience – resilience is a useful skill for any profession, but it’s critically important for business analysts because, like sales, you’re completely at the mercy of other peoples’ “no’s.”
• Problem solving skills – problem solving is simply the ability to take any given problem, regardless of the situation, and find a solution by sourcing the knowledge and skills you need either from other people or learning them yourself. There’s a lot of problem solving in business analysis.
• Critical thinking skills – critical thinking is letting go of non-critical information, such as personal opinions and emotions, and discovering conclusions through the analysis of certain truths. A famous example goes “All dogs have tails. Joe is a dog. So Joe must have a tail.”

Hard skills

• Data analysis – as mentioned above, data analysis is a key skill that requires some dedication over time. The goal is to pull insights from large databases using manipulation, visualization, and statistical techniques.
• Advanced Excel – as with any analyst position, excel is an invaluable hard skill. While I don’t think learning it’s VBA coding language is the smartest way to spend you time (Tableau is better), you should be familiar with Pivot Tables, basic statistics packages, and be able to manipulate the program without touching the mouse.
• Basic SQL – as a business analyst, SQL is not a critical skill per se, but it can save you loads of time if you work for data-heavy companies. If not, you will be at the mercy of the data analysis teams for everything you want to accomplish. Accessing the databases directly and being able to read them is critical.
• Basic Tableau – I highly encourage anyone interacting with databases to spend time learning Tableau. It’s an incredible data visualization software, and you can begin learning it for free with their public application.
• Markup & wire-framing – being familiar with markup languages such as XML and online wireframe tools (see a basic free version at WireFrame.cc) are also important if you want to be able to push projects forward and gather consensus from your teams.