Business analysts help ensure that software developers build applications that meet user needs, whether the developers are building an application from scratch or customizing an off-the-shelf solution. To do that, they bridge the enterprise IT department and the business units.
The International Institute of Business Analysis (IIBA), a nonprofit professional association, considers the business analyst “an agent of change,” writing that business analysis “is a disciplined approach for introducing and managing change to organizations, whether they are for-profit businesses, governments, or non-profits.”
[ Don't get caught in a dead end. Read The working dead: IT jobs bound for extension. | Check out the hottest jobs in IT and the most valuable IT certs today. | Get the latest insights by signing up for our CIO newsletter. ]
The IIBA says the BA role can also have a number of other titles, including business systems analyst, systems analyst, requirements engineer, process analyst and enterprise analyst.
Core responsibilities
Identifying and then prioritizing technical and functional requirements tops the business analyst's list of responsibilities, says Bob Gregory, a professor at Bellevue University and the academic program director for the business analysis and management degree program at the Bellevue, Neb., university.
“Elicitation of requirements and using those requirements to get IT onboard and understand what the client really wants, that’s one of the biggest responsibilities for BAs. They have to work as a product owner, even though the business is the product owner,” Gregory says.
BAs engage with business leaders and software users to understand the business process that the software will enable and how the software should operate to improve efficiencies in that process and to add value. They must articulate those ideas but also balance them against what’s technologically feasible as well as financially and functionally reasonable.
“[They need to ask:] What do the systems need to do, how do they do it, who do we need to get input from, and how do we get everyone to agree on what we need to do before we go and do it? The BA’s life revolves around defining requirements and prioritizing requirements and getting feedback and approval on requirements,” says Jeffrey Hammond, vice president and principal analyst with the advisory and research firm Forrester Research.
BAs also identify integration and compliance points, explains Kelly Emo,director of product and solutions marketing for application lifecycle and quality at HPE Software.
Effective BAs are skilled communicators who are also able to foster collaboration.
“You’re often going to find folks who want different things, so BAs have to bring them to some sort of consensus so you don’t have something that looks like a Swiss Army knife. They have to get everyone moving in the same direction,” Hammond says.
He adds: “And I find a little out of the box thinking is required. It’s really hard to get everyone on the same page, and it requires creativity to come up with a solution that’s not the obvious one.”
Evolving role, responsibilities
The responsibilities of the business analyst are changing, as the role evolves to meet the increased speed that business needs from its software development efforts. Enterprise IT departments are moving more of their development from a classic waterfall methodology, where BAs gather user requirements upfront and then hand them off to developers, to development processes that are more iterative and continuous, following agile and DevOps methodologies.
These changes have prompted some organizations to expand the responsibilities of their BAs so that they’re accountable for successfully gathering and presenting user requirements and serving as liaisons between business units and IT as well as the successful adoption of new software applications.
To that end, many organizations measure their BAs not on the number of requirements they identified but rather on how well those requirements meet the users’ needs, whether the new software meets business needs, how well the software is being used, and the users’ satisfaction with the application, Hammond says.
“Those are the things you measure a product manager on, so we do see organizations adopt the product manager title,” Hammond adds, noting that it tends to happen more frequently when a BA-type position sits within a digital business unit instead of within the IT department.
In his April 2016 report Develop Customer-Centric Applications Like The Pros Do, Hammond recommends replacing business analysts with product managers, writing “product managers are also ultimately responsible for getting functionality right and meeting customer demands for convenience, so there’s a stronger sense of accountability for functional decision-making.”
He explains in an interview: “It’s less the title and more the makeup of the person that’s important there. You can’t just take BAs and say you’re product manager; you have to have people willing to accept that level of responsibility.”
New tools, timing
Emo says BAs working in such a manner use new tools for identifying needs. They’re increasingly using real-time user data and analytics programs to identify user trends, successful functions and potential user adoption problems with the applications.
“One of the key values in the concept of the BA moving into being a product owner, as the whole line between IT and digital and software development and business shifts, is that this role has become more and more exciting,” Emo adds.
Given the expanding list of responsibilities put on the position, some organizations also have created product managers who work with BAs or who have teams of BAs reporting to them, Hammond says.
Similarly, the expansion and the faster, more iterative pace of software development has changed the timing of the BA’s involvement with a given development project.
A BA working in a classic waterfall development environment is still more heavily involved at the front end, when he or she will gather, analyze and prioritize user requirements before handing those off to developers and then moving on to another software development project, experts say. Meanwhile, BAs working on a more agile project generally stay with the project through implementation and even through multiple releases.
Organizations often assign BAs to several projects at a time if the projects are small enough, or they may assign a BA to a single project if it’s complex. Hammond notes that organizations also assign multiple BAs to very large software development projects.
However, some IT departments today are not involving their business analysts in all in-house application development projects, Emo says.
She says organizations are less likely to assign BAs to development work on the new class of applications such as mobile marketing apps and apps for temporary sales promotions “because they’re operating very lean or doing DevOps.”
“It’s all happening very rapidly in continuous delivery mode, and it’s data driven and not [driven by] lengthy requirement documents. What I see today, especially in the digital first applications, like digital e-commerce, it’s not the traditional business analyst involved.”
On the other hand, BAs are almost universally used for the development of back-office applications and core business software products, where identifying and documenting requirements is particularly critical, Emo says.
“A lot of those applications are under a lot of regulations, so [organizations] need that BA interface to document and ensure compliance,” she says.
Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.