Author: Adriana Beal
One of the topics that appear to be on the mind of many business analysts lately is the expansion of the business analysis role. How can a BA make a difference in his/her organization, perhaps going beyond conventional analysis to become a visionary? What are the challenges a BA may need to overcome to respond to the increased expectations of companies who hire business analysts not just to manage requirements, but also to perform project management and participate on decision-making processes?
Questions like these reflect the natural desire that business analysts have to better understand their role and focus on the development of the skills that will not only support their career goals, but also generate the most value for their organization.
Obviously, there isn’t a one-size-fits-all answer, but one thing that may be helpful for BAs pondering these questions is to remember that the most value a business analyst working in the IT solution space can offer to an organization is to excel in the processes related to the discovery, analysis, negotiation, and validation of the requirements of a new or modified software system. End users, project sponsors, subject matter experts, project managers, etc., all get involved in the process of eliciting requirements, but the business analyst (regardless of the job title he or she has) “owns” the requirements processes, and is responsible for making sure that the requirements adequately and completely represent business and user needs. To be truly effective, a BA must consider the project requirements their primary concern, from the development of a product vision and scope to detailed user and software requirements specifications and the change control processes that will be used to manage requirements during the lifetime of the project.
What about blended roles, then? It’s normally hard for a single person to balance goals like getting the project done on time and budget vs. delivering the right product. In my experience as a consultant, the most successful projects typically have a business analyst and a project manager working together to accomplish project goals. Activities such as planning the work to be done, identifying and securing necessary resources, determining tasks that must be completed, assigning the tasks, delegating authority, tracking progress, etc., are the responsibility of the project manager, while the business analyst remains in charge of producing consistent, complete, feasible, truly needed, accurate, traceable and verifiable requirements.
I see the “expansion of the business analyst role” as a double-edged sword. The consequences can be favorable if the intention is, for example, to involve business analysts in enterprise-level activities related to identifying gaps in organizational capabilities, developing models to describe the desired future state of the organization, or performing other tasks that allow BAs to deepen their knowledge of business goals and contribute to the formulation of business transformation projects. If, however, instead of aiming to get more from their analysts’ skills and capabilities by extending their involvement across the enterprise, the organization is simply trying to cut costs by having the business analyst simultaneously act as project manager, tech lead, or QA tester, there’s a substantial risk that the change will result in loss of value and quality of the output provided by the analyst, which in turn may result in extensive and expensive rework, or contribute to the already high statistics of IT project failure.
While discussing the BA role in their organizations, business analysts must be ready to fight unwarranted assumptions, needless compromises, and wild guesses about the responsibilities they have and the contributions they make as part of a solution team. An experienced business analyst is typically busy throughout a software development project, bridging the gap between the business and the technology teams, determining changes in processes and operations that need to take place as a consequence of the new system, investigating and advising on the project’s impact on other systems and initiatives across the enterprise, and so on. While BAs working for smaller organizations (or dedicated to smaller projects) may be able to successfully wear multiple hats, the acceptance of additional responsibilities, particularly when in conflict with business analysis core responsibilities, can have devastating consequences for both the organization and the analysts–a few of whom may even find themselves victims of the infamous Peter Principle.
To borrow the words of Laura Brandenburg,
I do think we need to balance our desire to help with an understanding of what it takes (in terms of time, effort, and focus) to be the best at what our core responsibilities are. It can be tricky… but sometimes it is better to “just say no”.