The title of "Business Analyst" is one of the fastest growing in the IT industry. In fact, the United States Department of Labor projected a 29% increase in computer systems analyst employment by 2016. There are many resources available that explain what a business analyst is, often in terms of comparing the responsibilities of an analyst to those of other team members we're more familiar with, like project managers, software testers, and systems architects. It's now generally understood, via the IIBA, that a business analyst "works as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems."
Just as important to understand, however, is what a business analyst is NOT. As organizations create positions labeled "business analyst" while struggling to keep costs down, it's tempting to use the role as a catch-all for tasks that an overextended project team just doesn't have time for. This may save time and money in the short term, but in the long term, it will only hurt your projects.
Business Analysts are not QA Engineers
Part of a BA's job is to develop clear business requirements and functional specifications. Critical parts of a good functional specification are the use cases and test scripts by which success of the end product will be measured. However, there is much more to quality assurance than test cases and use scripts. On medium to large software systems, these two elements make up only part of a complete test plan. Other elements include a documented testing methodology, equipment & resource scheduling, and configuration of any automation software. These things are best left to a qualified, dedicated QA engineer. While the QA engineer manages the testing process, the BA should be focused on addressing process issues that are discovered during testing.
Business Analysts are not Customer Service Reps
Whether you're a technology vendor or an internal IT department, your BA will be the most customer-facing team member, especially early on in a project. She will also become one of the most knowledgeable on the system itself, so it's easy to get caught up answering end-user questions. Comfort and familiarity with your BA during requirements elicitation is great, but it is critical (albeit difficult) to wean your customers onto the proper customer support personnel once the software is in production. If you don't, your BA won't be free to move on to the next project, and your customer service department won't be able to fully take ownership of ongoing support.
Business Analysts are not Developers
BA's must possess a fairly deep understanding of technical concepts, such as good data architecture, network design, and programming methodologies. Many even have a programming background and could be capable of doing development for the system they are designing. But unless your project is extremely small (four total team members or less) this is a recipe for disaster. Developers must be driven by factors like system speed, efficiency and extendibility, while BAs must be driven by factors like organizational goals, market conditions, and usability. These two areas require very different types of thinking. A person capable of doing both is rare; one capable of doing both simultaneously is near nonexistent.
Business Analysts are not Project Managers
This one may sound odd, especially coming from someone who happens to be both a project manager and a business analyst. Many of us work at organizations which use the same pool of resources to assign project managers and business analysts to various projects, because many of the skills required to do each job are the same. But to have a well-balanced project team, it's best that one person not wear both hats at the same time on the same project. The technical and business teams each are driven by different sets of often conflicting priorities. Each side needs an advocate, and when a situation arises that calls for one side to make a sacrifice, that decision falls to the project manager. The project manager is also responsible for keeping everyone else on task, tracking the budget, updating the schedule, managing risk, and so on. The BA and the PM should certainly work very closely together, but success is much more likely when there is a division of responsibilities.
Author: Niki Hammond, PMP, is a project manager and business analyst with over 13 years of web application development experience. She can be reached at [email protected].