What Do Business Analysts Do in Software Projects?

“What do you say you do here?”

In a memorable scene from the film “Office Space”, The Bobs, two management consultants interview Tom Smykowski, a Business Analyst, asking him to explain his role in the company. The scene is a comedic representation of the corporate world, where Tom tries to explain his role in the company.

This brings me to pen my thoughts on the importance of having Business Analysts in software projects and the critical role they play.

In the current era marked by rapid layoffs and the widespread adoption of AI and chatbots, the significance of the Business Analyst (BA) role has never been more pronounced. Yet, there exists a prevalent misconception regarding the scope and value of the BA function. Project managers and developers, perhaps unaware of the multifaceted responsibilities undertaken by BAs, often question their relevance within project frameworks. More than once have I encountered the words (maybe phrased a little more formally) – What do you do around here?

The reality, however, is that Business Analysts serve as integral facilitators bridging the gap between business objectives and project outcomes. They are adept at deciphering complex requirements, engaging stakeholders, and orchestrating effective solutions that align with overarching strategic goals. Despite their proficiency in navigating dynamic landscapes of requirement changes, BAs need to recognize the diverse perspectives and expertise present within the project ecosystem.

In navigating the intricacies of modern project environments, Business Analysts must transcend their specialized domain and embrace a holistic understanding of organizational dynamics. By fostering open communication, cultivating empathy, and promoting collaboration across interdisciplinary teams, BAs can unlock the full potential of their role and drive meaningful impact within their organizations. Below, I'll elaborate on the critical importance of Business Analysts in each stage of the lifecycle, as outlined in BABOK v3.

Business Analysis Planning and Monitoring

BABOK v3 (Section 1.3) defines a Business Analyst as “play(ing) a role in aligning the designed and delivered solutions with the needs of stakeholders.” Serving as liaisons between stakeholders, they facilitate the exchange of information and advocate for user-focused design principles, thereby enhancing customer satisfaction.

During Business Analysis Planning and Monitoring, business analysts meticulously craft the business analysis approach, develop strategies for engaging stakeholders, establish governance frameworks, and devise plans for managing information. Additionally, they delve into performance improvement measures, determining whether they're operating within a waterfall methodology or utilizing use cases and user stories. Defining the formality of deliverables and establishing the rigor of the approach are also crucial tasks that must be addressed before embarking on requirement gathering and analysis.

Here are some of the critical questions that needs to be defined in the Planning and Monitoring phase which a Business Analyst can help refine.

• What is the project methodology?
• How defined are our project deliverables? Are we creating user stories or use cases?
• What are the Business Analyst activities that are going to be defined?
• Who will be conducting the Business Analysis?
• Who are our stakeholders?
• What should our stakeholder communication plan be? What is the medium of communication? Frequency?
• What are our risks?
• What lesson can be learned from previous experience?

Effective business analysis, planning, and monitoring activities are crucial for delineating the subsequent project phase. Neglecting this phase can detrimentally impact all other project stages, including elicitation and collaboration.

Elicitation and Collaboration

The requirements identified and confirmed during elicitation and collaboration serve as the foundation for the subsequent design phase. Therefore, it is crucial for Business Analysts to effectively prepare for, conduct, and validate requirement elicitation activities. Various techniques can be employed for this purpose, selected based on the stakeholders, complexity of requirements and software methodology such as Requirement Questionnaires, Focus Groups, Interface Analysis, Process Analysis, Process Modeling, Workshops, Interviews and Observation.

In this phase, business analysts function as collaborators, ensuring active stakeholder engagement by conducting elicitation sessions to gather requirements. They present a comprehensive vision to stakeholders and communicate the gathered requirements. Following this, the requirements undergo further refinement and validation with stakeholders. Once validated, a decision is made to proceed to the next phase of the project, which involves requirement analysis and definition.

Here are some of the critical questions that needs to be defined in the Elicitation and Requirements gathering phase which a Business Analyst can help refine.

• Are the elicited requirements confirmed by stakeholders?
• Are the requirements discussed in Scope of the project?
• Are all areas of the identified business function addressed or addressed enough to go into Design?
• Are the meetings focused?

Requirements Life Cycle Management

BABOK v3 (Section 5.2.1) defines this phase as retaining requirement accuracy and consistency throughout and beyond the change during the entire requirements life cycle, and to support reuse of requirements in other solutions.

In this phase, business analysts guarantee the traceability, maintenance, and prioritization of all requirements. They remain accountable for assessing any changes to the requirements. Various tools, such as Jira and Blueprint facilitate the tracing and maintenance of requirements. However, the primary objective of these tools is to ensure that requirements are traceable, well-prioritized, and consistently maintained throughout the software development lifecycle.

Here are some of the critical questions that need to be defined in the Requirements Lifecycle Management phase which a Business Analyst can help refine and provides a “value add” for the project.

• Are the requirements consistently represented?
• Is there any missing functionality or scope creep?
• Are the requirements prioritized?
• Are the requirements accessible?

Strategy Analysis

BABOK v3 (Chapter 6) “defines the most effective way to apply the capabilities of an enterprise to reach a desired set of goals and objectives. Strategies may exist for the entire enterprise, for a division, department, or region, and for a product, project, or iteration”.

In this phase, business analysts scrutinize the current state, articulate the future state, and evaluate strategic constraints. They offer a critical evaluation of the business environment and operations, utilizing methodologies like SWOT Analysis and PESTLE to delineate future capabilities, change strategies, and conduct cultural assessments. During this stage, they identify the challenges faced by the existing business operations and aid project managers in decision-making processes.

In my experience working with diverse private organizations, we conduct market assessments to understand the current landscape and evaluate potential vendors. Additionally, we compile an inventory of successful projects to aid in selecting the most suitable solution. Moreover, we develop change plans to facilitate smooth transitions. Creating roles, matrices, and organizational charts also provides valuable insights for our analysis.

A successful outcome of this phase is that it sets the groundwork for requirement gathering and ensures the alignment of these requirements with the overarching business objectives. It helps align with the business goals, stakeholder expectation and solution requirements. Without proper strategic analysis and structure, there's a risk of veering off course.

Here are some of the critical questions that need to be defined in the Strategy Analysis which a Business Analyst can help refine and provides a “value add” for the project.

• Are the Future State boundaries of the proposed, new, removed, or modified components defined?
• Do we have a risk assessment or a risk register?
• Do we have a change strategy?
• Are the metrics that will be used to evaluate the effectiveness of the change strategy defined?

Requirement Analysis and Definition

BABOK v3 (Section 7) defines the Requirement Analysis and Design Definition areas as one which “structures and organizes requirements discovered during elicitation activities, specify and model requirements and designs, validate and verify information, identify solution options that meet business needs, and estimate the potential value that could be realized for each solution option.”

The preceding phase, Requirement Elicitation, and Collaboration, confirmed the elicitation requirements, and in this phase, the focus is on analyzing and defining the output from the previous phase. I consider this to be one of the most critical stages, where we endeavor to model requirements using various tools such as matrices, diagrams (like activity flow diagrams, capability models, and UML diagrams), data dictionaries, Non-Functional requirements, and business rules. and decomposition of functionality. We then seek informal sign-off from stakeholders to validate our assumptions and close any knowledge gaps.

In my experience, modeling requirements is an indispensable tool that not only helps confirm our knowledge but also conveys information and identifies any information gaps. The primary objective of this phase is to provide detailed input for solution design.

Utilizing pictorial representations, in my experience, to present requirements is essential, given the diverse learning styles among stakeholders, including developers and IT personnel. This method accommodates visual learners and ensures effective communication of the requirements such as developers and other stakeholders who are either visual learners or have different learning methods.

We also try to verify requirements to ensure that requirements and design specifications and models meet quality standards and are usable for the purpose they serve. Depending on the complexity of the project, we can refer to either federal and state regulations or organizational guidelines to consult the acceptance criteria. This ensures that our requirements are SMART (Specific, Measurable, Achievable, Relevant, Time-bound), testable, clear, and atomic. In my experience, federally funded projects, particularly programs like SNAP, must adhere to SIRT regulations.

Additionally, in this phase, we validate requirements to ensure their definition, necessity, correctness, lack of ambiguity, and consistency. We also outline the solution approach, pinpoint opportunities for enhancing the business, distribute requirements among solution components, and illustrate design alternatives that attain the envisioned future state.

Here are some of the critical questions that need to be defined in the Requirement Analysis and Definition phase which a Business Analyst can help refine.

• Are the requirements testable?
• Are the requirements verified?
• Are the requirements validated?

Solution Evaluation

According to BABOK, Chapter 8, “The Solution Evaluation knowledge area describes the tasks that business analysts perform to assess the performance and value delivered by a solution in use by the enterprise, and to recommend removal of barriers or constraints that prevent the full realization of the value.” Some of the most effective techniques for solution evaluation include proof of concepts, pilot or beta releases, and operational releases. These phases provide a comprehensive understanding of the solution's performance and the value delivered to stakeholders. Ironically, it's during this phase that we can thoroughly evaluate what went wrong in the project.

Proof of concepts and prototypes are invaluable for offering a functional yet limited version of the solution to clients, immediately showcasing its value. I have firsthand experience using prototypes and proof of concepts to garner stakeholder support and input.

Pilot and beta releases are also crucial, but they must deliver tangible value before the full solution is released. This aspect highlights the strength of an agile approach. Operational releases, especially for complex functionalities, should be iterated out rather than delivered all at once in an ad hoc manner.

Here are some of the critical questions that need to be defined in the Solution and Evaluation phase which a Business Analyst can help refine and provides a “value add” for the project.

• What are the performance gaps for the Solution which exists?
• What is the “value add” of the solution?
• What is the perception of the value of the solution?
• Are the KPIs aligned with goals and objects of a project?

In summary, business analysts contribute value across every facet of a project. While this may seem evident, their significance extends beyond mere oversight. Business analysts play a crucial role in averting cost overruns, scope creep, and other common project pitfalls. The presence of a proficient business analyst throughout all project phases guarantees project success.