Evozon encourages employees to learn and grow continuously, explore new avenues, and better themselves. That includes supporting colleagues that want to try different roles than the ones they currently occupy. As such I’ve worked with developers, testers, human resources, and project managers to transition them to the role of business analyst. And I would like to share my experience with you.

So if you’re looking to transition from one of these positions to the role of business analyst this article will help you.

Overview

When switching from developer, QA, HR, or PM to a BA role there are several changes that need to take place, especially in mindset.

Each role comes with its advantages and difficulties to adapt to the BA role. Additionally, we will look at how your mindset will have to change in order to get into a BA mindset. And finally, we will look at the main characteristics of the BA mindset.

You might be tempted to only look at the sections dedicated to your position. But I recommend reading the other roles as well to gain a better insight into what it means to transition into a BA role

Transitioning from Developer to Business Analyst

Developers that are likely to want to transition to the role of business analysts want to know more about the business context, and about the “why” behind the tickets they implement. They also like to communicate and document their findings and are more willing to participate in additional meetings.

Advantages

As developers you can leverage your experience in the software industry as follows:

  • You understand the technical language and software development concepts and constraints. So you’ll be able to identify if a request coming in might be feasible or not.
  • You know the software development life cycle and different methodologies used. This means you’ll be familiar with the work process.
  • You usually come up with solutions for problems in your work. And that will help in the design phase of the project.
  • You have analytical thinking which will help you break down larger issues into more manageable chunks.
  • You have an understanding of what a developer expects from a user story. As such you’ll be able to create user stories that developers can understand and use.

Difficulties

When moving into the BA role from a developer position you might encounter the following difficulties:

  • Having to focus on people and communication instead of focusing on the code and the solution.
  • Explaining the same thing several times will be frustrating. But you have to be patient and generous with your time.
  • You will be constantly interrupted and this will be difficult to handle. Especially since developers tend to be protected from interruptions.
  • In the beginning, it will be difficult to limit yourself to listening and digging for the problem. You will be tempted to come up with solutions. But you must first understand the real problem. A great solution to the wrong problem is useless.
  • As a BA not only are you involved in many meetings but you will organize and facilitate them.

Role Differences

There are a few key differences between the role of the developer and the business analyst:

  • Developers work only with the development team, whereas the BAs work with the customers and the development team.
  • Developers focus on the code performance and their own work., while BAs focus on all the stakeholders’ needs. This includes the team members and the customer.
  • Developers have little to no responsibility toward the customer. Meanwhile, the BAs are responsible for the outcomes that the team provides.
  • Developers are involved in as few meetings as possible and are seldom interrupted in their work. But the BAs are constantly interrupted to answer questions from the team. And not only do they participate in meetings, but they also facilitate most of these meetings.

Transitioning from Tester to Business Analyst

From the technical team, testers are the most likely to think of transitioning to the business analyst role. That is because they usually interact with the BAs to create their test cases, they have analytical thinking, and are used to working with customers as well as developers.

Advantages

As a tester, you can leverage your experience in quality assurance as follows:

  • You run the demos for the team and then the stakeholders. This will help you be more at ease when interacting with many different stakeholders.
  • You have good attention to detail – it will help you identify potential missing requirements. Stakeholders tend to oversimplify when answering questions so it’s important to go into details as well.
  • You have experience prioritizing bugs. And this experience will help you prioritize the entire backlog.
  • You have a good knowledge of existing applications and business processes. As BA you’ll also need to be familiar with the business processes and applications. Perhaps even more so.

Difficulties

When moving into the BA role from a tester position you might encounter the following difficulties:

  • When addressing the business you have to use a business-oriented approach: think ROI, what’s in it for them. And make sure you avoid very technical details. Doing so will eliminate confusion for your stakeholders.
  • The BA profession comes with its own vernacular and it takes some time to get used to the new terms.
  • As BA you have to always take a step back and look at the big picture and the benefits/need for a specific feature. Furthermore, you must understand that some particular cases, while technically possible, are unlikely. So you’ll need to skip them. Even though that will be difficult to accept as a former tester.
  • Spending time in many meetings is also something that QAs are not used to and can find difficult.

Role Differences

There are a few key differences between the role of the tester and the business analyst:

  • Testers work mainly with the development team, while the BAs work mainly with the customer.
  • Testers rarely communicate with customers. BAs, however, are in constant calls with the customers and exchange many emails.
  • Like the developers, testers tend to focus on their own work. But BAs focus on the work of the entire team. All while making sure stakeholders provide the necessary information and are satisfied.
  • Testers have smaller responsibility towards the customer. While the BAs are accountable for the work of the whole team.
  • Testers are usually able to execute their own tasks. Meanwhile, the BAs are dependent on others to accomplish their tasks.
  • The testers‘ work affects the team’s work somewhat, whereas the team is heavily impacted by the BAs’ work.

Transitioning from HR to Business Analyst

Thanks to their great communication and conflict management skills, human resources do well in the business analyst role. Especially if they also have business domain knowledge.

Advantages

When moving into the BA role from an HR position you can leverage your experience in human resources as follows:

  • As you have enhanced communication skills due to your work revolving around people, you can easily capitalize on that in your BA role; 
  • You encourage and give feedback which helps improve the outcomes of the team.
  • You are a liaison between different employees. And you will continue to be a liaison in your role as a BA between the technical team and the stakeholders. AndAand in some cases between different stakeholders.
  • You know how to gain your customer’s trust which is essential as a BA if you are to get all the information and support you need from your stakeholders.

Difficulties

When moving into the BA role from an HR position you might encounter the following difficulties:

  • Moving away from an HR attitude (solving teammates’ problems) to BA where you are only a support role.
  • Adapting to the IT/development lingo is difficult at first. That is because development comes with its own terms and definitions. And on top of that, you also have to learn the BA vernacular.
  • It is difficult to identify at first how large, complex, and/or detailed “good enough” acceptance criteria are supposed to be.
  • Being the only one with this role in the team is something that is not common for HRs, they are usually part of an HR team.

Role Differences

There are a few key differences between the role of the human resources and the business analyst:

  • HRs are independent and act and decide on their own. Meanwhile, BAs depend on customers to get information and requirements. And they need the developers to implement the solution.
  • HRs are more action-oriented and documentation is less needed. While the BAs have to document requirements, decisions, and progress.
  • HRs are usually part of a group of peers working through issues together. Whereas BAs are usually alone on the team and don’t have a support group.

Transitioning from Project Manager to Business Analyst

Going from a PM role into a BA role is not a usual career move. But what can happen is that the PM on a project might also take over the BA role for that project.

Advantages

When moving into the BA role from a PM position you can leverage your experience in project management as follows:

  • You have experience in managing stakeholders and communicating with them. And you will continue to do as a BA.
  • You have practiced interaction skills both within the team and with the customer. This will be useful in negotiating and prioritizing requirements.
  • You are familiar with the business and the business processes. That is because you are one of the first people involved in the project.

Difficulties

When moving into the BA role from a project manager position you might encounter the following difficulties:

  • Not having enough time to analyze the requirements in-depth.
  • It is difficult to keep up with tasks for both roles.
  • It is difficult to choose between on-time delivery and providing business value.

Role Differences

There are a few key differences between the role of the project manager and the business analyst:

PMs focus on the project, timelines, and budget, while the BAs focus on the product and the customer’s needs.

PMs are responsible for the project plan. Whereas the BAs are responsible for requirements planning.

PMs are responsible for managing issues and risks. While the BAs are responsible for requirements elicitation.

PMs support and manage the project team. Meanwhile, the BAs manage the stakeholders and the requirements.

Business Analyst Mindset

To recap and summarize the findings above, a BA is:

  • focused on the customer,
  • helps the team and customer achieve their goals,
  • is always one step ahead,
  • is able to see the big picture and also drill down into details:

Let’s look a bit closer at what that means.

Customer Centric

As a BA you focus on what the customer’s real need/objective is.

You question everything to solve the real problem.

You’re constantly communicating with the customer using their vocabulary.

You uncover gaps and communicate them, rather than cover them up.

You are flexible and open to changes in the requirements. Customers will always change their minds, it’s a fact so you have to be able to adapt.

Servant Leader

As BA your role is to help others. Whether that may be the team or the customer. Here are some key points on how a BA is a servant leader:

  • Empowering the team by sharing and receiving information.
  • You are there to manage expectations both from the team and the customer.
  • Leading the change and facilitating its adoption.
  • Taking responsibility for the shared understanding of the requirements.
  • You are humble, knowledgeable, positive, and sociable.

One Step Ahead

Being one step can mean making sure you have enough work prepared in advance. But it also means that you:

  • Accept and embrace business change and different ways of solving issues.
  • Are always on the lookout for what comes next on the project.
  • Are always learning new things: about the business, the team, about business analysis.

Top Down and Bottom Up

As a BA you’re focused at the same time on the big picture to see where new requests could fit in. But you’re also able to drill down into details and identify hidden requirements.

Additional Resources

If you’re interested in finding out more about the business analyst mindset I recommend the articles below.

 

Article written by Sergiu Pocan