business analyst Archives - RMC Learning Solutions

In project management, few roles cause as much confusion—and occasional overlap—as the Business Analyst (BA) and the Business Systems Analyst (BSA). On the surface, the titles sound interchangeable. Both are embedded in the requirements-gathering process. Both spend their days translating ideas into actionable plans. But scratch beneath that surface, and the differences are not only meaningful—they’re crucial to delivering successful projects.

Whether you’re managing a new software rollout, overseeing a transformation program, or running a lean Agile team, understanding how BAs and BSAs function (and how they differ) helps you structure your project team more strategically. Let’s dig into what sets them apart, where they overlap, and how you as a PM can make the most of their skills.

What is a Business Analyst (BA)?

The Business Analyst is your go-to person for understanding what the business needs and why. They:

Investigate business processes
Engage with stakeholders to uncover pain points
Document requirements and workflows
Define the value behind proposed changes

Think of BAs as fluent in “business speak.” They’re the bridge between business users and the technical team, constantly asking: “Does this solve the right problem?” and “Is this what the business really needs?”

BAs typically:

Conduct stakeholder interviews and workshops
Write functional requirements and user stories
Map current vs. future state processes
Support solution validation (e.g., during UAT)

Their sweet spot is strategy-meets-execution: understanding the wider business impact of projects and aligning proposed solutions to company goals.

What is a Business Systems Analyst (BSA)?

The Business Systems Analyst shares some DNA with the BA but skews more technical. They dive deeper into how solutions will work within existing systems. BSAs:

Analyze how proposed changes affect system architecture
Translate business requirements into technical specs
Collaborate closely with developers, architects, and IT teams

They often:

Document data flows and interface requirements
Write system use cases and technical requirement specs
Review API documentation and system integration needs
Assist in solution design and data modeling

If the BA asks “what do we need to solve?”, the BSA asks “how will it actually work in our tech stack?”

BSAs usually come with more technical training, sometimes having backgrounds in software development, systems engineering, or database management.

Key Differences at a Glance

Aspect	Business Analyst (BA)	Business Systems Analyst (BSA)
Focus	Business processes and stakeholder needs	System requirements and technical feasibility
Primary Stakeholders	Business users, sponsors, product owners	Developers, architects, IT teams
Deliverables	Functional specs, process models, user stories	Technical specs, system flow diagrams, data mappings
Tools & Techniques	SWOT, BPMN, wireframes, user story mapping	ER diagrams, SQL, interface specs, system modeling
Typical Background	Business, operations, product	IT, systems engineering, development

Where They Overlap

It’s not a tug-of-war between BA and BSA. In many cases, their roles complement each other beautifully. On large-scale or complex projects, you might find both on the team:

The BA leads stakeholder discovery sessions and defines high-level business needs.
The BSA translates those needs into system-level requirements and ensures they fit within technical constraints.

On smaller projects, one person may wear both hats—requiring them to be equally fluent in business analysis and systems design. As a PM, this matters. Understanding which skill set your project needs (or lacks) is key to avoiding requirement gaps or scope creep.

Relevance to Project Managers: Why You Should Care

As a project manager, your job is to coordinate, align, and deliver. Misunderstanding the BA vs. BSA dynamic can lead to:

Ambiguity in requirements: You get a beautiful user story, but no system spec to build it.
Misaligned expectations: Business thinks they’re getting X, tech delivers Y.
Missed timelines: Because no one mapped how the new feature integrates with existing systems.

The right analyst structure reduces friction across teams, increases stakeholder satisfaction, and minimizes rework.

Here’s what you can do:

Assess the complexity of the project: If it’s high on integration or backend dependencies, consider bringing in a BSA.
Clarify roles early: Don’t let BA and BSA responsibilities blur. Define handoffs.
Include both perspectives in planning sessions: Business needs + system feasibility = realistic planning.
Be their translator when needed: Encourage mutual understanding. Sometimes BAs and BSAs operate in silos.

Real-World Example

Let’s say you’re leading a CRM implementation. You have a BA gathering requirements from sales and marketing teams. They document:

We need custom lead scoring
Reports should show conversion by campaign
Integration with email platform is required

This is great. But how does it work?

Enter the BSA:

Analyzes if the CRM’s API can support real-time sync with your email platform
Designs the database schema to track campaign IDs and lead scores
Writes the system integration documentation for the dev team

Without both perspectives, you risk either:

A feature-rich solution that can’t be implemented technically
A technically sound solution that misses business needs

Titles Can Be Tricky

To complicate matters, job titles don’t always reflect these distinctions. In some organizations:

A BA does system analysis because there is no BSA role
A BSA is called a BA but spends all day writing API specs
A “Business Analyst” might actually be more of a product owner

Titles aside, what matters is the actual skill set and responsibilities. Clarify early. Use RACI matrices. Ask the right questions during kickoff. Don’t assume the word “analyst” means the same thing in every department.

Which Role is Evolving Faster?

Both roles are changing, but the BSA in particular is being reshaped by:

The rise of Agile and DevOps, where system requirements must evolve iteratively
Increasing demand for hybrid BA/tech skills (think: data-savvy analysts who can also model APIs)
Tools like low-code/no-code platforms, shifting where technical complexity lives

Meanwhile, BAs are seeing increased influence in product management, service design, and strategic transformation.

As PMs, it’s your job to see where your analysts fit into these trends and make sure your team composition supports project success.

Final Thoughts and Takeaways for PMs

In today’s fast-paced environments, the difference between a Business Analyst and a Business Systems Analyst isn’t just a matter of semantics—it’s a structural decision that impacts project outcomes. Understanding who does what helps project managers:

Define clearer roles
Identify skill gaps
Avoid downstream technical misfires

Key takeaways:

BAs focus on business needs and stakeholder alignment
BSAs bridge the business-to-technical gap with deep system knowledge
Both are crucial, but their contributions differ
Clear role definition upfront saves time, money, and rework
As a PM, empower each role to work in tandem, not in parallel silos

A well-deployed BA and BSA can mean the difference between building the right thing—and building the thing right.

Know the difference. Use it to your advantage. Deliver better projects.

Business woman in thought resting chin on hand

The first time you became aware of the number of business analysis techniques, what was your reaction? Was it shock and awe, or a feeling that you would never be able to master all of them? Or were you familiar with many of the techniques, but not sure if you were using the most suitable ones in your business analysis work?

Establish and Add to Your Analysis Toolkit

Business analysts need a toolkit with a range of options that will enable them to perform tasks effectively and consistently. Challenges both inside and outside of project work—including figuring out how you can best elicit, document, manage, and communicate requirements—require robust and flexible techniques.

The business analysis techniques outlined in the Guide to the Business Analysis Body of Knowledge^® (BABOK^® Guide) is widely used across industries, and provides solutions to meet these challenges. But it can be difficult to find hard data about which techniques work best, in part because these techniques are being used across a wide range of industries and projects.

In addition, when choosing a technique, you need to consider numerous factors like time, cost, usage potential, business analysis competency, stakeholder preference, user knowledge, level of documentation, project environment, and company culture, to name a few!

8 Tips for Selecting BA Techniques

Let’s look at some tips that can help you get started to pick the most appropriate techniques for your project or initiative.

1. Categorize the Business Analysis Techniques You Currently Use

Just as we categorize requirements to make them more digestible, useful, and focused, we can do so with business analysis techniques. The categories you decide on will depend on your work and industry. You can categorize by business analysis knowledge areas, or by the business analysis tasks you plan to perform to create results and outputs.

For example, you may want to create a category for eliciting requirements. You can also create categories for types of interactions you have with stakeholder groups or based on your stakeholders’ preferences. There may be techniques you use that work best with developers or clients, for example. You may want to have a category for visual diagrams and another for text-based techniques. Categorization can also be based on other constraints, such as number of stakeholders, project complexity, time, or cost.

2. Add a Few Techniques from the BABOK^® Guide to Your List

Now that you have the categories for your existing techniques, look at the techniques from the BABOK^® Guide and other sources and place the ones that interest you in these categories. This may require you to read up on some of them.

3. Talk to Other Business Analysts in Your Company

Find out what techniques they use and update your list. Also look for examples and templates that exist at your company. Now that you have created your own quick reference chart, let’s talk about how you can choose the most appropriate business analysis techniques for your project or initiative.

4. Target a Project and Try a New Technique

Considering your current projects, think about where you have issues such as unclear or incomplete requirements and other challenges. The techniques you are using may not be providing you with the best results. Ask yourself if the root cause of the problem could be the techniques themselves. Talk to your stakeholders; ask for their thoughts and gauge their willingness to try something new. For example: Your requirements have not been clearly defined, and you have been eliciting requirements through interviews only. You may want to try interface analysis, observations, bench marking, or a requirements workshop.

5. Try a New Technique that will Challenge You

Look at your list of new techniques and pick one that you feel would be a challenge. It could be something you have never done before. Maybe process modeling is new to you. In fact, maybe you’ve never created a diagram before. Take an existing process that has already been mapped or modeled. Try to create your own model and compare it to the existing model, you may gain a better understanding of the process. Then look for an opportunity to create a process model for an existing process that has not been modeled. You’ll be learning and adding value at the same time.

6. Ask Your Stakeholders What Techniques They Prefer to Use. Try on a New Project

This can help you if you are having issues with stakeholder engagement or communication. The technique doesn’t have to replace an existing one; it could instead be used in conjunction with what you are doing now.

7. Consider the Risks of Using the Techniques

The BABOK^® Guide has a great section at the end of each technique description that outlines usage considerations. Before proceeding with any new technique, consider the disadvantages and weigh the risks. Each technique has at least one disadvantage that imposes limitations and can create associated risk.

Selecting the most suitable technique for business analysis tasks involves a trade-off between advantages and disadvantages. For example, bench marking can identify opportunities for improvement, but it can be time-consuming, requires expertise in analysis, and does not typically result in innovative solutions. Business analysts can improve their understanding of the techniques by determining which disadvantages could become critical issues.

8. Use Decision Analysis

Select your techniques in the same way you would choose a vendor or assess a solution. You could create a decision analysis flowchart to select the techniques or score each technique using evaluation criteria.

Need More BA Techniques? RMC is Here to Help

In their search for suitable techniques, business analysts often find it difficult to obtain hard data on which techniques work best in which applications. As a result, many business analysts rely on what they know and what has been used in their organizations. But this means they may be missing out on techniques that can add value to projects and initiatives.

Having a basic knowledge of the techniques, as well as creating a personal categorization of the techniques, can help you objectively choose the most suitable technique for a specific project or initiative. Engaging stakeholders when you try out new techniques may provide additional unanticipated rewards as you grow your skill set as a business analyst.

Tag: business analyst

BA or BSA: What’s the Difference?