Back to List

6 Hybrid Business Analyst Combinations

Rachael Wilterdink Rachael Wilterdink  |  
Feb 19, 2019
 
There's been a lot of talk lately (and a lot of requests from our clients) for flexible hybrid roles. Our clients are looking for flexible people who can take on a variety of work to bring a project to fruition.
 
Here, I'm going to explore some of the more common combination roles that I have seen and/or experienced. I pride myself in being exceptionally flexible for my clients, and I don't see this trend ending any time soon – especially with the rise of agile.
 

1. Business Analyst / Project Manager (BA/PM)

I have played this role in the past. I wouldn't say it's my favorite version of hybrid BA roles, but it is one of the most common. This is especially true at smaller organizations, or on smaller projects where it may not make sense to have both roles assigned to different people. If you are working in a more traditional (non-agile) environment, that is the perfect place for this role to exist.
 
Many consider that becoming a project manager is a career path for business analysts, but I take issue with that. I see these as very two distinct skillsets, and anyone doing this hybrid role will have to be very careful about when to switch hats. PMs tend to have the big-picture view, whereas BAs can usually be found down in the weeds. The combination can also create some inherent conflicts of interest; the person playing this role will need to know how to split their time between their two sets of responsibilities.
 
Context switching is also difficult for someone playing this role. Whenever you start one activity, then must stop and restart, you lose efficiency. Time-boxing PM activities from BA activities and using careful time management skills can help you be successful.
 

2. Business Analyst / Product Owner (BA/PO)

This is another role I have played in the past: acting as a Product Owner "proxy” while also playing the BA role on an agile team. This requires a more senior analyst with deep business knowledge and a very strong relationship with the true product owner. It also requires that the product owner agrees to delegate day-to-day responsibilities and decisions to the analyst. This requires a high level of partnership and trust.
 
This is a pretty good combination role. The analyst is already very intimate with the product or business, and this seems to be a natural extension of the role. It also seems that this role could evolve into stepping away from the business analysis role and stepping fully into the shoes of a Product Owner – although it would require the ability to be aware of market conditions, recognizing where value resides, and making trade-offs and decisions.
 

3. Business Analyst / Quality Analyst (BA/QA)

I have also played the hybrid Business Analyst/Quality Analyst role. This seems to be a natural extension of a business analyst's talents, too. QAs need to be very methodical and detail-oriented. I do recognize QA as a separate set of skills and competencies, though. The BA in this role will need to learn some new skills and see not just the happy path, but also all the alternate and unhappy paths.
 
One additional skill that a BA will need in this role is the ability to write and execute test cases, depending on the type of work being done. In agile, the acceptance criteria created by the BA may almost be used as a test case, with each criterion being pass/fail. Another skill that is important to the QA role is documenting bugs, the steps to reproduce them, and the ability to identify the level of criticality for bug triage.
 
While I don't suspect many BAs would want to switch to being full-time QAs, it would be a good experience for someone earlier on in their BA career – or for an analyst who wants to better understand how their work is consumed and used by the other teammates and professions.
 

4. Business Analyst / User Experience (BA/UX)

Another common combination of skills that are very complementary is that of user experience design and business analysis. If a BA is working with software requirements, then they will often become the de facto UX designer (and they may not even know it). Because of my web design background, this has never been a struggle for me, and I’ve designed countless web and mobile experiences throughout my career.
 
Some special knowledge is required if you are to be truly proficient at this skill. First, you need to have (or learn to develop) a design eye. You’ll need to learn new techniques like personas and journey maps. You will have to put yourself in the shoes of all your potential end-users and design an experience that is optimal to them in their different contexts and environments.
 
Learning about human factors and user-centered design will also enable to you develop some amazing apps. You might also need to learn some additional tools for prototyping and design, such as Balsamiq or Axure for wireframes and screen flows, and possibly even Photoshop if you’re looking for high-fidelity images.
 

5. Business Analyst / Data Analyst (BA/DA)

This is another natural extension of the business analyst's skillset. We are surrounded by data, and BAs help drive out data requirements for many types of projects – especially Business Intelligence. The next step is to identify the data and then analyze it to help organizations make better business decisions.
 
The skills required for a data analyst will include the ability to ask the right questions and then figure out what data sources and targets are needed to answer the questions. It will involve the ability to write queries and create KPIs and dashboards to help drive those business decisions.
 
The Data Analyst may also take on a more technical role than the traditional BA. The DA may be more intimately involved in data modeling, learning new techniques such as entity relationship diagrams, data flow diagrams, data dictionaries, etc.
 

6. Business Analyst / Programmer Analyst (BA/PA)

Another hybrid is the Programmer or Systems Analyst/BA. This is probably the least common combination, but I have seen it before. In very small lean organizations, programmers will often act as BAs without even realizing they are doing it. I started my technology career as a front-end web programmer/designer. When I formally transitioned to becoming a business analyst, I realized I had been doing business analysis all along. From talking with stakeholders to understand their needs to documenting their requests, programming the web pages, and validating that their business needs were met – I was a BA in the making.
 
I've also seen this hybrid combination when a programmer decides they want to keep their toes in the technical water but also want to focus on understanding the business and their needs. This gives them the opportunity to build relationships with their business stakeholders and partners. Having that strong technical background will also aid the BA/PA in making better technical and architectural decisions as part of a team.
 
The only caution on this one is that the stereotypical personality traits of some programmers can sometimes hinder their ability to successfully take on the BA portion of their role. Business analysts must be excellent communicators. It also involves stepping back from their technology knowledge and being solution- and technology-agnostic. The role of a BA is to choose the best solution for the problem or opportunity at hand, not just the one that is most familiar.
 

Which BA hybrid is right for you?

So, if you're considering becoming some form of BA hybrid – either starting as a BA and tacking on other skills – or the reverse (starting as an expert in one of the other areas and adding BA skills to your toolkit), you won't be sorry. By adding new tools to your arsenal, you will make yourself more flexible, marketable, and valuable to your organization.
 
AgileBusiness Analysis

 

Love our Blogs?

Sign up to get notified of new Skyline posts.

 


Related Content


Blog Article
Top 4 Reasons to Attend WI BADD 2019
Shannon PagelsShannon Pagels  |  
Mar 21, 2019
WI BADD® (pronounced ”we bad”) is the annual Wisconsin Business Analyst Development Day held every May in Madison, Wisconsin (This year’s event will be held on May 15-16.) We are excited to again be sponsors and speakers at this event. Keep reading to learn more about the...
Blog Article
Skipping Inspection and Adaptation (Agile Transformation Pain Point #20)
Rachael WilterdinkRachael Wilterdink  |  
Jan 31, 2019
Inspecting and adapting is one of the key parts of agile and Scrum. But over time, teams start to feel bored as if every session is the same.   If it does become boring, make sure you switch it up to keep it fresh. The Fun Retrospectives website has lots of ideas. Don’t skip this...
Blog Article
Distributed Global Challenges (Agile Transformation Pain Point #19)
Rachael WilterdinkRachael Wilterdink  |  
Jan 24, 2019
So far, I've been primarily discussing co-located teams, which is ideally better. However, this is the real world, and it's a global economy – most people don't have the luxury of being co-located.   If you have a team with dispersed team members, set up your working...
Blog Article
Accruing Technical Debt (Agile Transformation Pain Point #18)
Rachael WilterdinkRachael Wilterdink  |  
Jan 17, 2019
Everyone who works in technology probably knows that you already have a big pile of technical debt. The problem is that you are going to have to eventually pay that bill, and some of it is risky.     Dig out a little every Sprint You really need to be careful about technical...
Blog Article
Focusing On Projects Rather Than Products (Agile Transformation Pain Point #17)
Rachael WilterdinkRachael Wilterdink  |  
Jan 10, 2019
This is a difficult transition for waterfall companies to wrap their heads around. It's a big mindset shift that needs to happen to be truly successful. I'm not saying that you can't have an agile Scrum team that works on projects with a distinct beginning and end. That might be a...