Who Exactly Is a Business Analyst?

If you are working as a business analyst, or any other role (tech or non-tech), there is a chance you’ve heard this question before – what exactly do business analysts do? The easiest explanation would be a person in charge of identifying and helping solve a business problem by using information technologies.

TL;DR this or summary on BA insights:

• Discovering and analyzing information to identify core problems


• Using design scope framework when determining features


• Simplifies the level of data and details to be written


• Bond and mutual language for both key stakeholders and the development team


• Oicial documentation delivery including validation and update


• Defining fundamentals on change management valuable for product lifecycle


• Harder, better, faster, stronger analogy

Business Analyst role – what do experts say?

Of course, depending on the organization’s specialties and maturity, you can see alternative names for a Business analyst role such as Data analyst, Process analyst, Application analyst, etc. This happens mostly because organizations get caught in rapid industry changes for which they need to act fast and include the right profile roles.

Often they adjust those roles to their business needs; however, the main goal is to design and deliver products while co-existing with traditional roles in a fast-growing ICT society. That’s where a Business Analyst jumps into a workplace environment. 🙂

Oicially, the International Institute of Business Analysis (IIBA) and The Business Analysis Body of Knowledge (BABOK) Guide defines a business analyst as:

Business analysts are responsible for discovering, synthesizing, and analyzing information from a variety of sources within an enterprise, including tools, processes, documentation, and stakeholders. The business analyst is responsible for eliciting the actual needs of stakeholders — which frequently involves investigating and clarifying their expressed desires — to determine underlying issues and causes. Business analysts play a role in aligning the designed and delivered solutions with the needs of stakeholders.

BABOK stands as one of the business analyst frameworks explaining techniques and competencies relevant to perform BA tasks.

It’s good to point out that the European ICT professional community back in 2005. started to define the e-Competence framework based on business areas, level of expertise, and competencies by particular ICT role. By e-CF Business Analysts engagement is clarified in areas PLAN-ENABLE-MANAGE while his core mission is:

Analyses the information and the processes needed to support business plans. Formulates functional and non-functional requirements of the business organization and advises on the lifecycle of the information solutions. Evaluates the impact in terms of change management.

Further reading can help you precisely determine the BA scope of work, specialties, and value to both product and team.

Business analyst vs. other project roles – overlapping responsibilities?

Let’s face it, often does the BA role get misunderstood with the role of a Project manager or Product owner. Some organizations even merge these roles into one which can aect the value and quality of work done.

Of course, it depends on the organization essence and the type of project we are talking about:

• Discretionary vs. mandatory


• Single-handover vs. multiple-handover


• Internal vs. customer project etc.

A typology of projects is well explained in Oliver’s F.Lehmann work: Project Business Management. It helps to better understand projects’ similarities and dierences that can influence dynamics of work and roles needed leading to success and failure scenarios.

To distinguish BA from other roles it’s important to understand that the business analyst role is to focus on product value to be shipped. That is achieved by defining best-case and edgy cases, acceptance criteria, and all relevant assumptions and constraints.

A business analyst works closely with the following roles:

• Project Manager


• Product Owner


• System/Infrastructure Architects


• Development team (consisted of developers, designers, and QA)


• Subject matter experts.

They make a solution team that aims to the same goal – deliver product and project on time. Steven P.Blais explained each of these roles well in his work Business Analysis – Best practices for success.

Main responsibilities and work per project roles are wrapped up in the following image. It’s important to notice that the synergy of all included parties is crucial for success, no matter what their level of knowledge, expertise, and experience is. Once that is achieved, the solution team can work in harmony and make results.

Document first in, develop, validate and update doc last

Oicial technical documentation per project or product is a topic for itself. There are thousands of articles and studies questioning, standardizing, and improving this process however, business analysts‘ responsibility is to provide the written form of inputs valuable for all parties included. Form type isn’t really important as much as content and quality matter.

This is especially sensitive in the design/analysis phase where a business analyst needs to act fast and find mutual language for both key stakeholders and the development team.

The diagram below sums up sources of data business analysts use while writing and updating oicial documentation.

Main tasks revolve around:

• identifying main priorities for process improvements


• interpret representation data from key stakeholders


• categorize and analyze gathered information


• supporting diversity over communication platforms and dev tools (often chat transcripts or emails are hidden gems of useful data)


• provide the written version of a solution according to strategy understandable for everyone.

Nevertheless, as the analysis phase is important, there comes development, testing, and that magical production period when everyone feels relief and moves on to new upgrades. That’s when business analysts should validate and update oicial documentation with the alignment of all included parties.

This is especially important for:

• production maintenance


• change management lifecycle or


• any further action over the project or product.

Unfortunately, it is also something that lots of completed projects end up without and it strongly aects the quality and speed of future work.

When creating documentation business analysts should keep in mind to cover solution scope by features and key activities, represented as follows.

Finally, as an intro in writing eective technical documentation, a warm recommendation for an oldie but goldie Alistair Cockburn: Writing Eective Use Cases. Yes, it’s a mature book and already 21 years old but the great thing about it is that Cockburn covers briefly use cases, not using any specific framework. It explains the main goal of use cases, target audience and simplifies the level of data and details to be written.

Impact of Business Analyst, in a Daft Punk way

In Q BA’s daily activities revolve around:

• product discovery engagement


• product strategy process


• participation in ongoing projects


• consulting services while identifying the problem.

Based on the maturity of the client’s idea and how well-defined it is there are two options:

1. Requires a smaller level of ideation and shorter definition stage – product discovery.

2. High-level ideas requiring research and defining digital product – product strategy.

During both product strategy or product discovery processes, BA closely collaborates with the solution team. Q’mans noticed during project retro analysis there is an urgent need for Product Strategist roles. All together they are creating the product layout, look & feel, and a plan for later development stages. While analyzing key business objects and requirements business analysts create user stories and get highly engaged in the ideation process and validation of target groups aiming to build a product strategy. As a result, delivered documentation, estimations, and scope prioritization can be done.

In ongoing projects, the business analyst gets involved in project-related ceremonies. One thing to mention here is that BA should always be passionate about his work and motivator of all activities in the project.

Main project activities are:

• backlog refinement and specification updates during development


• confirmation of the scope for an upcoming sprint with the client


• support for both project manager and development team


• test scenarios and bug prioritization


• deliveries for change management product lifecycle

To be honest, covering all the topics and responsibilities previously described can be a heavy, multifunctional everyday job. The most valuable are practical resources and ongoing projects that we carefully discuss and analyze in retrospectives. Sometimes they serve as a starting point for improvements on activities we see as pain points and spots where we can work it harder, make it better, do it faster…

Yes, Daft Punk’s funky lyrics can be used as a correlation for our overall mission when building and developing products. Okay, they imply building perfect robotic models but it’s applicable for the product development also.

We are all aware things get outdated, technology and processes can always improve and get innovative. That’s where we step up and try to help as much as possible. This leads us back to working it harder, better, faster analogy. 🙂

Conclusion

I hope this helped you understand better BA role. Contact our sales department for any open questions, we’ll be glad to assist.

Just remember – business analysts help to create alignment with all parties included and make order out of disorder. When working as BA don’t forget to be accurate, detailed, and after all – human and kind. Kindness is the key! 🙂