What Do Business Analysts Actually Do for Software Implementation Projects?

Everyone knows who the business analysts are in their organization, but not everyone knows what they actually do and what they are responsible for during software implementation projects.

Generally speaking, most business analysts "own the requirements processes," where they work with key line-of-business executives and users on just what it is they want from a new application, says Carey Schwaber, a senior analyst of application development at Forrester Research.
"If you believe that software projects succeed or fail based on the quality of the requirements," Schwaber says, "then you believe that software projects succeed or fail on the basis of business analysts, too."
Beyond gathering requirements, however, the other important duties inherent to the business analyst role (besides being a good communicator) are still not well-known today. In fact, according to Schwaber and fellow Forrester analyst Rob Karel, not many people, including business analysts themselves, have determined a standard definition (complete with typical skill sets, proper training methods and set career paths) for the business analyst position. Business analysts, for instance, are also known as: business systems analysts, business technology analysts, system analysts or requirements analysts.
"Everyone agrees on the importance of the business analyst role," Schwaber and Karel write in a recent report, "but few know exactly what it is that business analysts do."

Eight Business Analyst Responsibilities

Scott Ambler, the practice leader of agile development for the IBM Methods Group and author of several books on software project management and agile development, says that first and foremost, business analysts (or as he terms it, business systems analysts, or BSAs) are responsible for communication and collaboration between the business and IT.
"The most important responsibilities of a BSA are to act as a communication conduit between the stakeholders and the team," Ambler says, "to represent the stakeholder community to the development team if the developers themselves don't have direct access, and to translate the business needs for the team.
Ambler developed a list of eight activities that business systems analysts will usually perform on a traditional software development project:
1. Scope the system. At the outset of a project, business analysts may be the only "software development staff" assigned to the project, Ambler writes. And at this point, they work with key project stakeholders and business people to formulate and communicate the business vision for the project, map out initial requirements and the scope of the project.
"Their fundamental goal is to get the project focused early by translating the initial high-level vision into something realistic," Ambler writes.
2. Interpret business needs. A critical responsibility of business analysts is "to work with project stakeholders to translate their requirements into something that developers can understand as well as to translate the resulting questions that the developers have into something the stakeholders can understand," Ambler writes. A key skill needed in this part of the process is the business analyst's ability to distill the differing messages and needs of project stakeholders into a single, consistent vision.
"This task often includes significant negotiation and political maneuvering," Ambler writes. Business analysts will "often find themselves spending significant time in meetings, thereby saving the rest of the development team from this inefficient use of their time."
3. Translate technical issues. Business analysts also have the arduous task of breaking down technical and architectural complexities so that project stakeholders can easily understand any issues that crop up, such as "why your HTML-based application can't have as slick of a user interface as a Visual Basic application," Ambler writes. "BSAs often explain what the developers are doing and why they need to do it, including explanations of the basis of schedules and estimates."

4. Spell out the project details and requirements. "BSAs will often work with project stakeholders to identify, model and then document their requirements and business domain details," Ambler notes.
5. Put development team in touch with the right people. "BSAs typically have very good connections within the business community," he writes, "and therefore are in a position to help development teams find the right people to work with."
6. Political guide. "BSAs often help project teams through the political minefields within their organizations, particularly when the BSA has worked within the same organization for several years," Ambler notes.
7. Test and validation. Business analysts work with project stakeholders to "validate their requirements and analysis models via techniques such as reviews, walkthroughs and play acting," he writes. "BSAs will often aid in writing user acceptance test (UAT) cases and will be a liaison between project stakeholders and your testing organization during UAT."
8. Represent project stakeholders throughout the process. If project teams don't have direct access to their project stakeholders, which is never a good situation, business analysts have to act as "stakeholder surrogates," Ambler suggests. "Typically developers will treat a BSA as the 'customer' from which requirements, domain information and business priorities are provided. The BSA, in turn, will work with the stakeholders to obtain information and to verify decisions."

The Most Important Business Analyst Duties

So where do business analysts concentrate most of their efforts and what are the most important tasks that apply to all business analysts? According to research from Requirements Solutions Group (RSG), a consultancy that helps train business analysts, the business analyst has a wide range of responsibilities. (RSG's research is based on data from 1,700 IT professionals who consider themselves IT business/system analysts that was gathered by RSG and from other sources.)
At the top of their responsibilities are: identify and model process requirements (80 percent of respondents said this was part of their job); identify and model data requirements (75 percent); identify business rules requirements (75 percent); and test requirements (75 percent), which includes many levels of testing.
Next in the ranking of responsibilities are: manage requirements (70 percent); facilitate requirements sessions, or what's also called joint application development (65 percent); help scope the project (60 percent); write use cases (55 percent); improve business processes (50 percent); design screens (or prototypes) (40 percent); and write system (or technical) specifications (40 percent).
Last in the RSG data are these two responsibilities: determine benefit/cost (30 percent) and lead or manage projects (25 percent).
In light of just how much pressure and responsibility fall to today's business analysts, Forrester's Schwaber notes how underappreciated they are, especially as much of the kudos for software project success (when it does happen) goes to either self-congratulatory executive sponsorship or the herculean efforts of the developers.
"[Business analysts] don't get the glamour, and they don't get the glory," Schwaber says. "For some reason, we always think that should go just to the people who write the code, even though they wouldn't know what code to write in the first place if it weren't for the business analysts."

Ref: http://www.cio.com/article/2436638/project-management/what-do-business-analysts-actually-do-for-software-implementation-projects-.html