What Does A Business Analyst Do?

So you’re wondering what exactly does a business analyst do?

The short answer is: depends.

‘On what?’ you might ask.

And I would like to answer that by saying that it depends on a particular job, company and industry, although there are some general trends and activities that a business analyst does. For example, chances are you won’t find a business analyst coding at the job.

Let’s actually answer some of the questions you might have then.

What is a Business Analyst?

The overseeing Business Analysis organization, IIBA (International Institute of Business Analysis), defines the business analyst to be

The person who performs business analysis activities, no matter what their job title or organizational role may be. Business analysis practitioners include not only people with the job title of business analyst, but may also include business systems analysts, systems analysts, requirements engineers, process analysts, product managers, product owners, enterprise analysts, business architects, management consultants, or any other person who performs the tasks described in the BABOK® Guide, including those who also perform related disciplines such as project management, software development, quality assurance, and interaction design (BABOK Guide).

So that’s the official definition of a business analyst.

You might wonder ok, but what does a business analyst actually do and what’s this BABOK that sounds like a monster from a children’s story?

What is Business Analysis?

Well, again, the official definition for Business Analysis is that it’s

The practice of enabling change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders. The set of tasks and techniques that are used to perform business analysis are defined in A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide).

To say it in layman terms, the business analyst uses business analysis processes to understand requirements, define needs, and ultimately provide solutions to those needs that satisfy the needs of all the different stakeholders (people who have a stake in the project).

He uses the BABOK as a guide (although not always needed) to help him make sure that the business requirements get matched to appropriate business solutions.

The general Business Analysis process, in broad strokes, is as follows:

1. Needs assessment
2. Business analysis planning
3. Requirements elicitation and analysis
4. Traceability and monitoring
5. Solution evaluation

We’ll briefly go over each and every one of these steps so that you get the idea of why and how it’s done.

Needs assessment

A needs assessment action consists of the business analysis work that is conducted in order to analyze a current business problem or opportunity. It is used to assess the current internal and external environments and current capabilities of the organization in order to determine the viable solution options that, when pursued, would help the organization meet the desired future state.

Why is it needed?

Needs assessments are performed to examine the business environment and address either a current business problem or opportunity.

What happens if it’s skipped?

When a needs assessment is bypassed, there is often insufficient analysis to adequately understand the business need.

How do you do it

You need to

• Identify the stakeholders of the project
• Investigate the problem or opportunity
• Gather relevant data to evaluate the situation
• Draft the situation statement
• Obtain stakeholder approval for the situation statement

Basically you find out who has a stake in the project, you then gather the problems, opportunities and relevant data to the situation, then draft the situation statement of the form

• Problem (or opportunity) A
• Has the effect of “B”
• With the impact of “C”

And finally you obtain stakeholder approval on it, which basically means that the needs are correctly identified.

Business analysis planning

The business analysis approach is simply the methods the business analyst uses when managing and performing the business analysis activities on the project.

Why is it needed?

Planning the business analysis work is critical for project success. When business analysis planning is bypassed, it is difficult to understand the scope of work, stakeholder’s expectations, and the appropriate amount and level of business analysis required for the project.

What happens if it’s skipped?

When business analysis planning is skipped, the scope of work, stakeholder’s expectations, and the appropriate degree and in-depthness of business analysis required for the project is misaligned with the business objectives.

How do you do it?

Well, you need to establish the following:

• What to include in the business analysis plan
• Understand the project context
• Figure out how the project life cycle influences the business plan
• Make sure the team is trained for the entire project life cycle
• Think of past experience when planning
• Define the 
  • Priorities
  • Traceability
  • Communication
  • Decision-making
  • Requirements change
  • Requirements validation
  • Solution evaluation process

At the end of the day, you need to figure out how you will conduct the business analysis process. This is to know and explicitly write down the things and methods you interact with, such as the planned project life cycle, your past experience and observations regarding the current project, the well-defined priorities, communication methods between stakeholders, requirements validation criteria and others.

Requirements elicitation and analysis

The requirements of a project are usually discovered through a process called elicitation. The business analyst schedules elicitation sessions with the different stakeholders of the project, in order to draw out information about either the business problems of the project, or the business opportunities. 

The amount of information that needs to be drawn out or organized is ideally enough to base a comprehensive solution on.

Why is it needed?

Not only because it’s necessary to gather the requirements to build all that’s needed to solve the business problem/opportunity, but also because it stands at the base of every other business analysis task, such as supporting executive decision making, applying influence successfully, resolving conflict, etc.

What happens if it’s skipped?

Skipping the requirements elicitation analysis means that the business analysis plan comes up to a halt.

How do you do it

You need to

• Determine the participants
• Determine the questions for the session
• Do the actual elicitation session

Usually the actual elicitation session is the hardest one. All the mistakes made in the previous steps surface in it

Traceability and monitoring

Traceability means the ability to trace and track the evolution of the product requirements all the way to the final deliverables. Generally traceability is proportional to the complexity of the project: the more elements the project has, the more needs to be tracked.

Why is it needed?

Because the progress of the requirements need to be tracked and monitored until the deliverables are provided.

What happens if it’s skipped?

Skipping this step means that you might reach a point where the deliverables are not the result of a harmonious development of the requirements. 

Meaning that you might end up with irrelevant requirements that do not add any business value.

Plus, the scope of the project is difficult to manage.

How do you do it

The gist of it requires you to

• List the relationships and the dependencies
• Approve the requirements
• Baseline the approved requirements
• Make use of the traceability matrix
• Figure out the life cycle of the requirements
• Manage changing requirements
• Control all changes related to defects

Requirements are generally contingent on various relations, so you first must make sure you map out every relationship to its dependency. Then, as you go, you must approve the requirements as they evolve, which will result generally in a baseline with the approved requirements. Since these are ever-evolving, some might be scrapped as things go on. As requirements change, you need to manage them and control for defects related to them.

Solution evaluation

Thanks to the previous processes described above you should now have available a solution candidate.

The solution evaluation step is the final one in our business analysis effort, and provides all the necessary processes to validate or invalidate a proposed solution.

You will see how much do stakeholders appreciate the solution and how much does it actually fit the needs / opportunities of their business.

Why is it needed?

In order to find out if the provided solution is actually solving the business requirements and achieving the desired results.

What happens if it’s skipped?

There is a predisposition to skip this step once you have the solution formed. The mistake here is that even if you have what seems to be a viable solution candidate, you still need to go through the process of making sure that the solution is actually adding value.

How do you do it?

You need to do the following:

• Have the right mindset
• Plan the evaluation & figure out what to evaluate
• Figure out when and how to validate solution results
• Evaluate the acceptance criteria
• Obtain the green light for the solution
• Evaluate the long-term performance

It’s important to keep a mindset that makes you evaluate early and often, and even though we presented traceability as happening before this step, you need to think of both of them as complementary. Before you start the evaluation process, you need to come up with a clear action plan and focus on what needs to be evaluated – KPIs, sales, marketing efforts, successful ads, etc.

As you evaluate the acceptance criteria, you need to clearly define expected results against actual results.

If everything goes well, you must ask (or you’ll get) the green light for the solution, and be able to advance with the project.

Even before the solution is fully implemented, you can make long-term performance projections, but generally you’ll focus on defining periodic milestones when to evaluate the performance of the solution.

How we do it at Mobiversal

As stated in our book, From A to App Success: How to turn ideas into apps that make a difference, as a general rule we don’t necessarily approve of rigid frameworks, and this applies to business analysis too. The business analysis process described here is a fool-proof method of solving business problems and opportunities.

But it doesn’t mean that it’s the perfect solution for us, and it might even mean that it’s not the perfect one for others. But it’s a good framework to base your process on.

If you want to learn more about our business analysis process, we dedicated a whole chapter to it in our book, so go ahead and download it (it’s free).

Conclusion

If the job of a busienss analyst seemed a bit hazy before this article, we hope that we provided you with a general overview of the scope and work that the business analyst does.

For those of you who want to learn more about business analysis, we highly recommend the following books:

1. Business Analysis for Practitioners: A Practice Guide
2. A Guide to the Business Analysis Body of Knowledge (BABOK Guide)
3. Business Analysis For Dummies
4. Business Analysis

See you in the next one!